Archived

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

simon_brown75

Triangle fan question

Recommended Posts

simon_brown75    123
Just a quick question about the correct usage of triangle fans. I've read the section in the DX8 SDK and it seems pretty straight forward, first three vertices = 1 triangle, after that just specify 1 new vertex per triangle. So how do I end a fan and start a new one within the same vertex buffer? My fans are going to be quite small in general (<10 tirs), so I can't afford multiple DrawPrimitive calls, or to use a seperate VB per fan. Presumably there must be a way of ending the fan and starting a new one in a different position? (ie having no vertices in common with the previous fan) Thanks in advance, Simon. additional - also will I need to use indexed vertices to achieve this? Edited by - simon_brown75 on July 28, 2001 8:50:48 PM

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
Each fan = DrawPrimitive command. That''s the big prob with fans.

Be seeing you...

lemming

Share this post


Link to post
Share on other sites
NotTaxes    122
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

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
You can render seperate fans using the same vertex buffer.

pd3dDevice->DrawPrimitive(D3DPT_TRIANGLEFAN, TheVertexToStartAtInTheVertexBuffer, NumberOfTrianglesToRender);

Share this post


Link to post
Share on other sites
NotTaxes    122
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

Share this post


Link to post
Share on other sites
NotTaxes    122
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

Share this post


Link to post
Share on other sites
simon_brown75    123
Thanks for the replies lads

I would probably have around five thousand fans with anything from 2 to 8 triangles in each. I've currently got it working with triangle lists, but it would have simplified the code, and made it easier for me to extend the program further if everything was done with fans. The program is a quadtree based terrain engine with LOD.

I don't think fans are an option in my position though, 5,000 DrawPrimitive calls is gonna kill my frame rates. Looks like I have to stick with triangle lists.

Thanks for clearing that up.
Simon.

Edited by - simon_brown75 on July 29, 2001 8:32:00 PM

Share this post


Link to post
Share on other sites
Zaei    122
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.

Share this post


Link to post
Share on other sites
simon_brown75    123
350 triangles! You must have an extremely smooth height field. There''s no way the height field I''m using could be approximated with 350 polygons. Even with 30,000 triangles, the approximation still isn''t satisfactory.

I''d love to see your demo and your height field to see how 350 polys can be enough. If you don''t want me to see your demo, maybe you could show me a screenshot, or if that''s asking too much maybe just the height field?

I am going to try switching to fans to see how much speed it costs.
TIA,
Simon.

Share this post


Link to post
Share on other sites
NotTaxes    122
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

Share this post


Link to post
Share on other sites
Boki    124
quote:
Original post by NotTaxes
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.



Did you try to use a dynamic vb instead of many small ones? vb switches are performance killers and because of the small number of vertices per node the vb fill won''t cost much.

Bjørn.

Share this post


Link to post
Share on other sites
Boki    124
quote:
Original post by NotTaxes
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.



Did you try to use a dynamic vb instead of many small ones? vb switches are performance killers and because of the small number of vertices per node the vb fill won''t cost much.

Bjørn.

Share this post


Link to post
Share on other sites
simon_brown75    123
But to cope with a very rough 1025*1025 height field, you need to implement some form of LOD, so that rougher and closer (to the viewer) terrain is generated at a higher polygon density (even with frustum culling, which I am doing).

Also, the effect the roughness of your height field image has on the polygon count is really huge. Having said that I don''t understand how Zaei can be representing a 1025*1025 height field using only 350 polys, unless the height field is extremely smooth.

You can see from looking at this wireframe shot that 350 or 900 polys couldn''t really represent the kind of terrain I''m trying to make with any accuracy-

http://www.sbdev.pwp.blueyonder.co.uk/wireframe3.jpg (200k)

Share this post


Link to post
Share on other sites
Zaei    122
Yes, my Height Field is much smoother than that, and I have a low desired detail level set (my graphics card sucks). Other then that, my screen shot would look pretty much like yours, except that along with a few cracks, there are holes in certain situations. Luckily, i know why, and how to fix it =). What algorithm are you using?

Z.

Share this post


Link to post
Share on other sites
simon_brown75    123
I have cracks too at the moment I haven''t fixed that yet either.

I''m using the top-down method, so I start with a 64*64 patch of nodes (total map = 1025*1025) and progressively subdivide it, so there''s 6 levels of detail at the moment. I have a pre-calculated implicit variance tree. The variance I measure is, like in most of these methods, the height difference between the mid-point of an edge and the node under that midpoint. I calculate the 6 variances per quadrant, and store the highest value.

Then the actual algorithm is-

if ( variance * threshold ) > distance ) -> subdivide quadrant

where distance is from the viewers position to the centre of the quadrant, and a quadrant is one quarter of the current patch. And the threshold value controls the desired global polygon density.

I''m current considering switching to the bottom-up method, since I think it must be more accurate.

Share this post


Link to post
Share on other sites
simon_brown75    123
I just experimented, still using triangle lists, but instead of sending 20,000 triangles per DrawPrimitive call, only sending a handful, and hence having an extremely large number of DrawPrimitive calls.

The good news is that as long as there is around at least 3 triangles per DrawPrimitive call the frame rate drop is only about 1 fps (a pleasant surprise). I may even get this back with the vertex cache when using triangle fans (if I used indexed vertices) since they''re more effecient.

Basically there is no reason not to use triangle fans now, which will make coding a gap-free landscape considerably easier

p.s. does anyone have any good sources for colour-based height field data?

Share this post


Link to post
Share on other sites