Jump to content
  • Advertisement

Archived

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

Bobboau

fillrate vs poly count

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

If you intended to correct an error in the post then please contact us.

Recommended Posts

currently I am makeing a decal system, and I'm just about done, but I've run into a problem witch might be fundemental to the way I have it set up, I am using texture clamping and simply copying verts from the parent models, then useing the distance from the planes that define my decal volume to generate UV coords. polys on the parent model that have a closest point within the decal volume are added, and triangulated, and each triangle is UV tested to see if it falls out of the range, the textures are alpha blended to the parent model, and generaly there is only 1 or 2 polys for each decal, the problem is it's usualy a freaking huge poly on the larger models it can be more than 100 times the size it needs to be filling nearly half the screen, and being re-rendered a thosand times, this has caused a slow down that I hadn't expected, as I was sacraficeing fillrate for tri count (tricount would probly be twice what it is, also the clamping method allows for decals to be generated with virtualy no overhead). so am I going to have to redesign my decal system to clip against the six planes of my decal cube(not a problem but if this isn't the cause I'd rather not waist my time), or is something else afoot? I am useing non-indexed vertex buffers for the decals becase it's more expensive to generate index buffers than simple vertex buffers, I tryed useing index buffers and saw no improvement. also I recently made changes to alow dynamic FVF types in my vertex buffers (includeing index buffers, I run a high level abstraction, vertex and index buffers are treated the same by the high level stuff) so would changeing FVF cause a huge massive slow down? Bobboau, bringing you products that work... in theory [edited by - Bobboau on June 8, 2004 11:58:01 AM]

Share this post


Link to post
Share on other sites
Advertisement
Changing FVF can be time-consuming, if you''re doing it for every decal. If you have a ''decal phase'' in your rendering arch, and just change the FVF once at the beginning, that''d amortize the change almost entirely.

Have you looked at a few other options:
1. Generate vertices for the decal. If you''re already retriangulating existing vertices, this can''t take much longer, and will reduce the fill problems on small decals.

2. Look into alpha testing as well as alpha blending. This is an early-out test based on a reference alpha value. If generating vertices isn''t an option, this might help a bit for large decals.


My spoon is too big.

Share this post


Link to post
Share on other sites
the FVF is, I beleve, exactly the same for the models as it is for the decals. I think the only thing that uses a diferent FVF in the entier sceen is the backgrounds wich we removed the normals from to save bandwidth (as the backgrounds are unlit). in a test mission prior to shooting anything I get a frame rate of 120 fps (a hard coded limit) cut to 12, yes 12, after one of the objects gets it''s fill of decals (250 IIRC). if I comment out the draw primitive call for the decals the frame rate goes back up to 120 (but the decals are gone obviusly). the vertex bufer size can get to be about 1000 (~1.25 polys per decal) on large objects and this is suposed to be the optimum size for a vertex buffer.

I''m fairly sure that were useing alpha testing, as it was added to alow textures with transparent sections that wouldn''t need to be front/back sorted.

well I guess I''ll try more smaller polys.

Bobboau, bringing you products that work... in theory

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!