Triangle strips and culling - problems on the horizon?


I’m about to reengineer the model-drawing part of my engine from rudimentary and unoptimized “just get it on the screen” to implementing octrees for frustum culling and collision checking. Sooner or later I’m planning to use some form of tri-stripper, too. Now, thinking about how to best organize the vertex data I see this problem coming up:
If I correctly understand how strippers work, they organize your vertex data into triangle strips, the longest ones being the best of course. So, how I see it, if I want to use frustum culling, I will break up those optimized strips again as soon as the model is only partially in the frustum. Furthermore, since my data is reorganized into strips whose ‘orientation’ on the model surface is arbitrary, could I run into problems (like degenerate strips, or even vertex data not suitable for strip interpretation ->i.e. data that will lead to a different shape than the one intended) by ‘cutting’ out a part of a strip via culling? (The worst case I can imagine: every second triangle(its center) of a strip lies in the neighbouring cube of the octree, getting culled away, if I culled per cube-volumes).
So could anyone share their knowledge with me and tell me if my perception of the problem(s) is correct?
Is there any golden rule for organizing your model data?


your post was difficult to read, so i skipped it ^^

i did it like this :

  1. built up a lot of quads out of a heightmap
  2. let my octree-algorithm split it up into small pieces
  3. strip those maximum-size-100-parts with my bruteforce-stripper

first octree, THEN stripping

[This message has been edited by HamsterofDeath (edited 02-10-2003).]

>your post was difficult to read, so i >skipped it ^^

Sorry for that… I’ll try to keep it shorter next time.

OK, I thought about something like this… I only hope this will get me strips with good efficiency…


You pretty much want to consider that each strip is unmodifiable; in other words, you always draw or dont draw the strip in its entirety. You can do this by making sure that no strips cross boundaries between visibility groups (octree nodes in your case), or by allowing a single strip to be in multiple visibility groups.

Yeah, sounds reasonable.
Only, I’m not quite sure how to handle it really, since for collision testing, it would be useful if triangles werde contained in each node if they extend over several nodes, whereas in culling I’d have to decide in which node they belong best.
Also, for collision checking, it would be desirable to have a higher reolution (less faces/node) than for efficient strip drawing…
I need to think about this…
Maybe I’ll use my previous approach, which culled each of the model’s sub meshes via bounding spheres against the frusutm. Only, this would be a waste of space, since the submeshes won’t necessarily be within node boundaries and I’d have to store information about them too…