Sunset Lake Software - Comments for "Enhancing Molecules using OpenGL ES 2.0"

Hello, the simplified

Hello,

the simplified versions of the sphere shaders were of a great use to me, I learned a lot from them. Do you have non-optimized shaders for the bonds (cylinders) as well?

Cheers

Great work. I will pass this

Great work. I will pass this along to a few bio-chem types I know.

I am particularly intrigued by the performance on my 4S and the IPAD2. How are the molecule spatial relationships and stciks defined? Is it possible to create an object, coordiante and relationship matrix to feed Open GL?

I would love this for representing a 3D relationship between conceptual objects in systems engineering.

ANy possibility of associating the each sphere or objects with information that can be summoned by touch within the view?

OpenGL ES 2.0 can be used to

OpenGL ES 2.0 can be used to display pretty much anything, with the right code. It's a very flexible rendering API.

If you're asking whether the code used for this application could be used to render arbitrary 3-D models, no it can't. As I describe above, I use some tricks to fool the eye when rendering spheres and cylinders so that they appear to be perfectly smooth shapes. These are the only classes of objects that this can draw. More generic model loading functionality will require a completely different approach.

I am by no means a

I am by no means a programmer, but am intrigued by your using of OpenGL2. Do you think it could be applied to displaying 3D solid models of tooling?

All code that I used for this

All code that I used for this application is available on the main Molecules page. This page has the latest version of the application, which includes the OpenGL ES 2.0 rendering engine as used by the version on the App Store.

Do you intend to open source

Do you intend to open source the OpenGL 2.0 code as well?

This was how I initially

This was how I initially attempted to encode color, but it presents a problem. For my depth buffer, I will have certain fragments that will be covered by multiple objects. Each of these objects will render a color to that fragment, and the order in which they render is not guaranteed. Therefore, an object closer to the viewer could render before one further away, and the far object would overwrite the depth color from the near one.

I use a minimum value blending mode for the depth buffer, which only stores the minimum value for each color component (red, green, blue). I then use this sort of "bucket-based" color encoding, where one color is filled up first, then the next, then the next. This guarantees that when I get the minimum (closer to the viewer) for each individual color component, the total value will always be the correct minimum.

For one of the higher-precision encoding methods, simply taking the minimum for each color component breaks down in certain cases (think of a per-digit comparison of 110 vs. 085). I couldn't think of an easy way to support multiple writes to the same fragment, yet preserve the higher precision of the other encodings.

You should be able to get

You should be able to get much better than 768 levels of depth for pretty much the same cost using the technique in Aras's other article http://aras-p.info/blog/2008/06/20/encoding-floats-to-rgba-again/

Using some significant

Using some significant optimizations, I have now been able to get the new rendering engine running almost as smoothly as the old one did on the iPad 1. Version 2.02, which is now live on the App Store should hopefully address the complaints that people have had about the application's rendering speed.

As promised, 2.0 was the slowest the application will ever be.

Thanks for the confirmation -

Thanks for the confirmation - those figures by Marco are pretty conclusive. I'd better get going with shaders then!