The way I see it is:
GL_TRIANGLE_LIST -> CPU overhead since more draw calls required.
GL_TRIANGLES -> (CPU/AGP?) overhead due to more indices being sent.
GL_TRIANGLE_LIST + NV_PRIMITIVE_RESTART -> Almost no overhead
Degenerate triangles are a possible alternative, are there any issues with this method? If not why did NVidia create this extension?
Originally posted by Adrian:
GL_TRIANGLES -> Vertex transform overhead
Why that? Use indices, problem solved. That’s what post-transform vertex caches are for …
Originally posted by zeckensack:
[quote]Originally posted by Adrian:
GL_TRIANGLES -> Vertex transform overhead
Why that? Use indices, problem solved. That’s what post-transform vertex caches are for …[/QUOTE]Yeah I corrected my post
There’s a hack for triangle primitives if you want to jump triangles. Say you had:
123 324 789 985
you could string those together by doing the following:
1234477895
which would expand to:
123 324 447 477 789 985
Many (most… at least on DX) graphics cards will recognize this and automatically not render the degenerates… True it doesn’t work for fans, but who uses those anyways (hooray for fan users you have a useful extension) 
. It does require a few more indices, but over all would still be just as fast as the restart one (one fewer) and only slightly less generic. Given that option, seems like a problem that doesn’t really need to be solved (1 fewer indices… come on…).
I’m all for reducing state change overhead though, that seems to be a big rough point for even some of the most optimized engines.
1: Function call overhead on glDraw*. In our case, we have plenty of CPU time, so this is negligable.
2: Driver marshalling of GPU commands. The boneheaded way of implementing glDraw* is to immediately put the commands into the GPU’s FIFO, which could require a switch to Ring0 on the CPU (a slow operation). Few GL drivers do it this way. Drivers marshal GPU commands pretty efficiently these days.
Well, I don’t have plenty of CPU time. As for 2, if I have a boneheaded implementation, I’d be better off buying a new card, as any extension supposedly designed to increase performance would likely be useless anyway. I didn’t quite understand the point in 3.
I would dearly love to fan my terrain, but I can’t due to the performance impact.
Why the fans?
True it doesn’t work for fans, but who uses those anyways
I use them. It’s a common method for rendering n-sided polygons. With this extension, I can render a multitude of polygons (strips or fans), all sorted by shader, in one call. Moreover, I can do this quickly and easily on the fly, as it only requires inserting an single index when you build your final list, making it painfully easy to jump around my database. In any case, this will still enable you to batch polygons more efficiently.
Even if only marginally better, worst case, it’s still better. As I said earlier, I enjoy using this for the convenience, any performance boost is icing on the cake.
As for 2, if I have a boneheaded implementation, I’d be better off buying a new card, as any extension supposedly designed to increase performance would likely be useless anyway.
Driver updates do more than just add extensions. The bonehead implementation can be fixed, for example. And, for OpenGL, I wouldn’t worry too much about, since both ATi and nVidia seem to be pretty much on the ball with their triangle rendering code.
Why the fans?
Why would I want to fan terrain? Because heightmaped, hex-based terrain is naturally fan-like. Terrain looks better as a sequence of fans rather than a sequence of tri-strips. It tends to per-vertex light better too.
It’s a common method for rendering n-sided polygons.
How often do you have an n-sided polygon? Or, perhaps more specifically, why are your artists creating environments that are not inhierently strip-worthy? They are the ones responsible for the state of your terrain, after all.
Driver updates do more than just add extensions. The bonehead implementation can be fixed, for example. And, for OpenGL, I wouldn’t worry too much about, since both ATi and nVidia seem to be pretty much on the ball with their triangle rendering code.
The point is that I shouldn’t have to worry about something I have no control over anyway. How the driver deals with things internally is its business. I have to trust it to do a good job; if it doesn’t, there’s nothing I can do about it. If, on the other hand, the vender exposes an extension, presumably for the express purpose of making things faster and/or more convenient, then I have to assume it’s a good thing, as the vender knows infinitely more about the implementation details than I do.
Because heightmaped, hex-based terrain is naturally fan-like. Terrain looks better as a sequence of fans rather than a sequence of tri-strips. It tends to per-vertex light better too.
Ah, I both see, and agree. Curious, do you mean to say that you use a hexogonal grid? The reason I ask is that some LOD algoritms produce fan like strippings, just by virtue of the winding order. I know, for example, ROAM flavors use fans heavily, while some of the newer SOAR implementations rely on strips exclusively, and end up with very nice fan-like windings.
How often do you have an n-sided polygon? Or, perhaps more specifically, why are your artists creating environments that are not inhierently strip-worthy?
I have a fairly substantial BSP model in addition to the terrain. The editor’s setup to allow an artist to ham-fistedly add brushes to the world, and apply an arbitrary shader to any side. During preprocessing, I can do quite a bit to optimize; but I can’t strip across different shaders, as much as I’d like to.
Yes, fanning would be nice for rendering convex polygons. That could help for accelerated 2d rendering… How often do you use this different brush technique on terrain? If it is used completely overboard then yes, I can see why this would be really helpful. However, if you do have a bunch of edge coherancy between the same shaders it would probably still be more optimial to get an ideal triangulation of the polygons and do some surface analysis, use stripping and or just indexed triangles (get better vertex caching and the like).
Now for the editor I could see it working better with fans, but in an actual game engine… Is that what you’re using it for? What type of preprocessing are you doing?
Plus with height maps, you can still use fan shaped triangulations and strip it, right? (or even just use normal indexed triangles…)
Ok, I see it’s often somewhat faster.
I will let it out for now, it does not look particularly promising unless it gets widespread (and wisdom on that reaches an agreement). I have no time to put it in now just to get a minor speedup that only some people could get (it doesn’t change even if it’s +40%).
Thank you.
Adruab, Imagine placing a Quake level on top of the terrain, or underneath it (interior only, like in Morrowind). I briefly considered a BSP terrain, but couldn’t get the scale and detail I wanted.
