Quad tree and vertex array...
Author
What''s the best way rendering a vertex array of tri strips in a quad tree? I plan on traversing the quad tree and dynamically construct a vertex buffer from the data in the leaf nodes. Would this be feasible? Is there a better way? How would I go about implementing something like this. Thanks.
What about using GL_TRIANGLES or GL_QUADS? I know they would take more memory than tri stripes, but slower also?
Yeah that sounds like a good plan.
I think I would make a vertex buffer of a certain size (use a #define so you can adjust it easily), and fill it while traversing.
When you go to add more polys to the buffer and you don''t have room, draw the polys that are in it already, and mark the buffer as empty.
This way you can batch up your polys in card-friendly amounts, and you can adjust the batch size to find the best one for your card.
I wouldn''t use GL_QUADs, as I don''t think cards really support them natively. I would presume that GL_TRIANGLE_STRIPs are the way to go, but for a start, you should probably just use GL_TRIANGLES for simplicity.
I''m probably going to implement something similar soon myself - keep me informed on how it goes!
- Pete
I think I would make a vertex buffer of a certain size (use a #define so you can adjust it easily), and fill it while traversing.
When you go to add more polys to the buffer and you don''t have room, draw the polys that are in it already, and mark the buffer as empty.
This way you can batch up your polys in card-friendly amounts, and you can adjust the batch size to find the best one for your card.
I wouldn''t use GL_QUADs, as I don''t think cards really support them natively. I would presume that GL_TRIANGLE_STRIPs are the way to go, but for a start, you should probably just use GL_TRIANGLES for simplicity.
I''m probably going to implement something similar soon myself - keep me informed on how it goes!
- Pete
The way I''ve been doing it is to use 9 point quads (center, topleft, left, bottomleft...) and make a GL_TRIANGLE_FAN for each one starting at the center and working counter clockwise. They''re also easy to do some LOD on, continuous or initial.
- Mike
- Mike
Author
Yeah that''s what I had in mind. But the tri fan sounds kinda cool. I''m not implementing LOD yet, I going to do it later and test both LOD and straight up rendering (with culling of course) to see which one is faster. I really want to save CPU cycles for other things. Shouldn''t need LOD at all, I''m making a isometric perspective engine, you not going to see much polygons in the first place.
what i do is first find out everything thats visable in the scene
(ie i dont fill a buffer draw it fill it again + draw it etc)
once everythings founds its drawn first by state (presorted) and then by distance to the camera.
creating batches of tris (not possible with strips) could be good (i havent checked on a hardware t+l card, its not good on a non hardware t+l card unless u do your own bf culling) but remember everthing in the batch has to share the same states
http://uk.geocities.com/sloppyturds/gotterdammerung.html
(ie i dont fill a buffer draw it fill it again + draw it etc)
once everythings founds its drawn first by state (presorted) and then by distance to the camera.
creating batches of tris (not possible with strips) could be good (i havent checked on a hardware t+l card, its not good on a non hardware t+l card unless u do your own bf culling) but remember everthing in the batch has to share the same states
http://uk.geocities.com/sloppyturds/gotterdammerung.html
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
