Would you store normals on file or calculate it from the vertex?
Author
I''m not very experienced with normals so I don''t know exactly if it takes too long to do, but is calculating normals too expensive to calculate them for all the models in a game? I''m talking about a game like... Zelda OOT for example. With all those models, do you think that the loading times are going to be very high? Asume that the computer has a 1GHz processor...
Also the part of getting them from a file would increase the file size for about 1/4 or 1/3 and I think I''m probably exagerating...
Anyways.. you opinion, okie? :D
---------------------->
Nothing in the world is the way it should be; that''s why we, the champions, exist and live for: HOPE.
Precalculate the normals and store them in your vertex structures. If you''re worried about size you can compress them to 16bits per component or even 8 bits per component. You can decompress on file load or even in a vertex shader (so you can leave them compressed all the time). At any rate, generating correct normals often entails splitting vertices (for hard edges) which you don''t want to do in your game.
If your models are static I think you should pre-calculate normals, it would be a waste of time to re-calculate the same normals every frame. I don''t know what sort of modlling tool you are using, but 3dsMAX can export all normals for you.
On the other hand, if your models are animated, the normals will need to be re-calculated every frame so lighting calculations will work.
If you are keyframing, you might be able to interpolate between normals like you would with vertices, I''ve never done it and that''s just an idea off the top of my head, I''m not sure if that''s the how pros do it or not! any other ideas people?
"When I''m in command, every mission''s a suicide mission" - Zapp Branigan
On the other hand, if your models are animated, the normals will need to be re-calculated every frame so lighting calculations will work.
If you are keyframing, you might be able to interpolate between normals like you would with vertices, I''ve never done it and that''s just an idea off the top of my head, I''m not sure if that''s the how pros do it or not! any other ideas people?
"When I''m in command, every mission''s a suicide mission" - Zapp Branigan
Generally, for keyframing, normals are pre-calculated for each frame and you interpolate between them (renormalizing of course). This can even be done in a vertex shader (so your animated mesh is "static" as far as the hardware is concerned). Or you can use skeletal animation, in which case your vertex normals are transformed by your bones (and weighted) just like your positions. Remember if you can avoid CPU vertex manipulation then the vertex buffers can be in hardware and you can avoid bus traffic. The exception is when the calculation cannot be done on the GPU for some reason (dynamic water for example).
blue_knight> 8 bits per component, and it''s not necessary to have 3 components... a normal represented as two values of latitude/longitude works perfectly, and that brings the size down to 16 bytes per normal... (what md3 format uses, and surely lots of other formats...)
Latitude/longitude is actually a bad system if you want good space efficiency. If you look at a standard 3d sphere, you can see that the majority of the polygons are near the poles. You can see that most of your precision with a latitude/longitude system is at the top and bottom. The precision is not equally distributed.
It isn''t normally (no pun intended) a problem, but it is useful to know if you are concerned about space or bandwidth.
It isn''t normally (no pun intended) a problem, but it is useful to know if you are concerned about space or bandwidth.
No I would precalculate them right after load time. I think it's ez to prove that given modern CPUs it's faster to compute them once than to load nearly twice bigger files, specially for big meshes. I don't think the smooth angle stuff is a real problem. Some data ordering preprocess can make it nearly costless.
(profiling digits corrected)
Creating normals is of linear complexity compared to the size of the mesh. I would say 40 or 60 clock cycles or so per vertex, try to beat that with file loading .... ;p. Taking a 4GHz PC for instance, would anyone load a mesh of 100,000,000 triangles thus roughly 3GigaBytes in less than one second ? Wow that's a super hard disk. What a bandwidth !
Anyway you need some kind of dynamic routine for deformable meshes. So that's not a redudant work.
[edited by - Charles B on July 12, 2003 6:16:49 AM]
(profiling digits corrected)
Creating normals is of linear complexity compared to the size of the mesh. I would say 40 or 60 clock cycles or so per vertex, try to beat that with file loading .... ;p. Taking a 4GHz PC for instance, would anyone load a mesh of 100,000,000 triangles thus roughly 3GigaBytes in less than one second ? Wow that's a super hard disk. What a bandwidth !
Anyway you need some kind of dynamic routine for deformable meshes. So that's not a redudant work.
[edited by - Charles B on July 12, 2003 6:16:49 AM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
