Hi, Interresting links about compact normal and more :
http://aras-p.info/blog/2009/08/04/compact-normal-storage-for-small-g-buffers/ http://aras-p.info/texts/CompactNormalStorage.html and http://c0de517e.blogspot.com/2008/10/normals-without-normals.html yann On Fri, Nov 6, 2009 at 10:51 PM, Jean-Sébastien Guay < jean-sebastien.g...@cm-labs.com> wrote: > Hi Simon, > > > Ah I didn't know that, ty. Seems like an odd limitation though. >> > > Well, the video cards are implemented to take in only certain types of > data. Vertices, normals and colors are in general aggregates of 32-bit > floats (which is why no vertex type is ever a vector of 3 doubles). > > > How does the angles thing work? Not sure I follow you. >> > > Your intuition is right that normals around a vertex will always be in a > sphere. The thing is that you can encode that as spherical coordinates ( > http://en.wikipedia.org/wiki/Spherical_coordinates), where r = 1 (since a > normal is always unit-length). So the direction could be encoded as two > angles, theta and phi, inclination and azimuth (see the Wikipedia article). > > Now, you already save one float that way over storing a 3-component vector. > If you want to save more, since the angles are small numbers, you can store > both of them into the lower and upper parts of a single 32-bit float (two 16 > bit numbers) and re-extract them from the float in the shader. > > Another way is you could store only 2 of the 3 components of the normal - > since a normal is unit-length you can calculate the third component easily. > Those numbers will also be small (less than or equal to 1) so you could do > the same transformation into two 16-bit values and store them into a single > float. The spherical coordinates just came to mind first as I've used it > before, but the result would be the same. > > > If you did the normal lookup, wouldn't you save a whole load >> of shader processing time, or is memory bandwidth a bigger limitation with >> shaders? >> > > You'd save a little bit of processing time per vertex, but compared to a > texture lookup to get the right normal from the lookup table, I don't know > what would win. Seriously, what I've described above is child's play for a > GPU, and very easily parallelizable, which is what GPUs do best. > > It's not really a matter of bandwidth since your lookup table would be > pretty small too. I expect you'd get similar performance in both cases, for > me it's just inconvenient to drag around an extra table when I don't have to > - the angles / quantized vector method above would all fit nicely in the > object itself without needing any extra data. > > > J-S > -- > ______________________________________________________ > Jean-Sebastien Guay jean-sebastien.g...@cm-labs.com > http://www.cm-labs.com/ > http://whitestar02.webhop.org/ > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > -- Yann Le Paih Keraudrono 56150 BAUD Portable: +33(0)610524356 lepaih.y...@gmail.com
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
