Uhhh yeah. Like he said. If the fans are close together, you could join them up with a couple of *really* thin tris and no-one''ll know the difference. So... if you have Fan1 and Fan2, you draw a little triangle between Fan1 and Fan2 that has no verticle component (your tri''s 2nd point is on the same plane as the other two). I did this and it works pretty well... but then again, each situation is unique and you may end up having problems with visual artifacts popping their ugly heads into your scenes.

''Doing the impossible is kind of fun'' - Walt Disney

Yeah, but you''re still using multiple draw statements, which slows the thing down. The way I understood it, Simon wants to have 100 (for example) fans all stored in the same VB and all at different, non-adjacent locations, and then render them in a single call. The problem being that the 2nd, 3rd, 4th... 100th fans will always be drawn as part of the preceding one.

You could use TrangleLists instead of fans. This allows you to put the whole lot into a single VB and render with one call, but it''s a trade-off situation. On the one hand, using multiple drawprim lines with a trifan is slow, and on the other hand using one drawprim with a trilist is also slow. It all depends on how many fans you''re doing. As a thumbsuck I''d say, fewer than 100 fans it''d be faster to use TriList (coz bulk of data is still faster than multiple drawprim lines), but more than that and multiple drawprims is faster.

Of course, I could just be talking through my hat. Try it both ways and see which is faster.

''Doing the impossible is kind of fun'' - Walt Disney

Ummm... sorry, I used fans and tri-lists in the same sentence, probably in a confusing way. What I mean is... if you have 100 *polygons* you want drawn, probably faster as a Trilist. If you want more than 100 polgyons, then probably faster as multiple draw statements with TriFan.

It may not be 100. It may be 1000, or even 2000. Try it both ways and see what works.

Firstway = 1000 trilist polygons.

Second way = 100 DrawPrim statements all pointing to different parts of the Trifan VB (so first one Does 0-10 trifans, second one does 11-20 trifans, etc. all from the same VB)

''Doing the impossible is kind of fun'' - Walt Disney

If you are working on a Terrain LOD dealie, you won''t be using 5000 DrawPrimitive Calls. I am also working on something along those lines, and I am only drawing, at max, 350 Polys (on a 1025x1025 height grid). Use Fans. They will make your life easy =).

Z.

Uh, I recently converted from Trilists to TriStrips and only got about 2 fps better. Also doing a height-mapped thingy, drawing around 900 polys.

What I do is:

For every 9 heights (3x3 points on the grid) I create a Vertex buffer storing the nine vertices + texture info. Then, the rendering program checks for visibility of each VB in a 30x30 rect around the camera and if it''s in my view-cone I draw it.

I figured that this was a nice compromise between using a huge VB for the entire map, and being able to cull stuff quickly. I tried using different densities on the VB (2x2, 10x10, 4x4, ect.) and the 3x3 gives me best performance. Currently rendering at around 80 fps running VB debug mode (+100 in compiled mode). This is not too bad for a little Celeron 450 pc :-) When I add in the 100 or so terrain objects (Trees, rocks, buildings, etc... mesh files with an average polycount of around 350) my fps drops to 35 or so, which isn''t ideal but still almost certainly playable.

It''s been said before, but the fastest polygon is the one you don''t draw. The performance benefit of lists vs fans vs strips seems to be as naught compared to the culling technique.

''Doing the impossible is kind of fun'' - Walt Disney