Archived

This topic is now archived and is closed to further replies.

Yet Another BSP Quest.

This topic is 5522 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

Also See My Next Reply, i dont wanna start new forum for a single question and getting a single reply.. I have made a Node-Based BSP engine that atleast solves the polygon sorting problem. Each Node contains a Plane whereas a Plane could be shared among a lot of co-planar polygons. First Problem The Polygons are of arbitrary edges so i use glVertexPointer() in which fully managed vertex information is saved, sometimes repeated vertices, because glDrawArray() needs consequent bunch of anti-clockwise (or clockwise) vertex order, so i must save these vertices in order, compromising the repeatition. So its clear that i can't use glVertex() commands. Is there any chance of optimism so the vertex count become lower. Second Problem (Important) When i come to render the scene, i follow standard back to front traversal, sub-problems 1) Should i use front-to-back with Z-Buffer on, Why (if yes)? 2) I have to render every polygon attached to the visible plane whether it is visible or not, so what king of frustum culling logic i should embed.. either i check each poly's vertex in the frustumand render that poly as soon as i get any of its vertex in the frustum or i should attach a sphere with each poly and check it as against the vertices? TALAL BIN GHIZAL [edited by - maktal on August 12, 2003 10:06:01 AM]

Share on other sites
1) Front to back can make your rendering faster, since a pixel will never be drawn behind another one (Sort-of overdraw reduction). Back to front is often used for transparent polygons because this gives the correct transparency.

I don''t know the BSP algorithm (well, I have a vague understanding), but I would guess a Z-buffered front to back would be faster since graphics cards are optimised for using Z. But it will depend on the amount of overdraw you get. If it''s not too much trouble you may want to try both and see which is fastest.

2) I''m not sure, but graphics cards themselves aren''t too bad at frustum culling. Unless you''re being limited by the AGP bus, manually frustum culling might not make much difference.
If you stored the co-planar polygon groups in something like a vertex array on the graphics card, you will probably draw much faster without explicit frustum culling than you would drawing from system memory with explicit frustum culling.

Share on other sites
Ok, i got some really considerable frame rate by not doing explicit Frustum Culing (my mind was blown when i thinked about those old tutorials that say Frustum culling could speedup rendering where they slowd down things), Anyhow i m not doing any polygon level frustum culling.

Now i have a bunch of BSPs and i transforms their positions at load time as per written in the map file, i think its clear but let me explain more.

1) I have a list of CBSP Objects
2) I load into each slot of that list
3) The information written in map file is used to position each CBSP object in the world.
4) The normals are pre-calculated in the Modeller (Software) space , u may say Object Space.
5) So whenever the CBSP position changes from 0,0,0 to something else, thats mean i m transformaing that CBSP Model from Object Space to World Space, all the Rendering craches and unwanted popping of geometry starts.
6) I know, it is happening because normals should be calculated in the world space after loading CBSP object.
7) Am I Right?
8) If yes than suggest something, should i recalculate the normals or is there any chance to reuse these precalculated normals?

TALAL BIN GHIZAL

1. 1
2. 2
3. 3
Rutin
18
4. 4
JoeJ
14
5. 5

• 14
• 10
• 23
• 9
• 42
• Forum Statistics

• Total Topics
632635
• Total Posts
3007559
• Who's Online (See full list)

There are no registered users currently online

×