# [osg-users] Computing Normals for Drawables

yann le paih lepaih.yann at gmail.com
Fri Nov 6 23:46:47 PST 2009

```Hi,

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.guay at 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
>>
>
> 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.guay at cm-labs.com
>                               http://www.cm-labs.com/
>                        http://whitestar02.webhop.org/
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>

--
Yann Le Paih
Keraudrono
56150 BAUD
Portable: +33(0)610524356
lepaih.yann at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20091107/e8bbcc24/attachment.htm>
```