Jump to content
  • Advertisement
Sign in to follow this  
Shai

NVTriStrip woes [UPDATED QUESTION INSIDE... see my last post]

This topic is 4220 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

Hey guys, I am loading .OBJ models and I would like to optimize the models using NVTriStrip. However, the OBJ data is structured by face, and indexes separately into the arrays of vertices, normals and texcoords. To make matters worse one vertex can have multiple normals (the normal used depends on the triangle being drawn). So I was wondering if anyone could help me out. The .OBJ models that I'm using are the omnipresent Stanford bunny and Venus de Milo models. I'd be really grateful if someone could point me to a site that has optimized versions of these models. Or if someone could perhaps advise me on how I can work aroud the problem of there being more normals than vertices. [Edited by - Shai on March 27, 2007 12:25:50 PM]

Share this post


Link to post
Share on other sites
Advertisement
You have to expand them into a single set of vertices. That is, if there's a position that has two different normals and two different texture coordinates, you'll have to split it up into more than one vertex.

It's not that hard to do, just expand all of your individual arrays of elements into complete vertices, then go through and remove all the duplicates. Then fixup your index buffer to point to the correct locations inside your new "unique vertex list" and you're all set.

Then you'll start running into the real NVTriStrip woes... where it doesn't generate very nice tristrips, and (iirc) leaks memory. Maybe they've fixed these things since then, I haven't used NVTristrip in a while.

Share this post


Link to post
Share on other sites
alright, it works now :)

Another question then, well, two questions actually.

When I set "SetListsOnly(true)" I'm telling NVTriStrip to rearrange my indices in such a way that I can draw the model using GL_TRIANGLES. Whereas when I set "SetListsOnly(false)" I'm telling it to rearrange indices so I can draw the model with GL_TRIANGLE_STRIPS. Right?
Now when I draw using GL_TRIANGLES I got around 15k indices, but when I draw using GL_TRIANGLE_STRIPS I only got around 8k indices. Why is it then that the framerate stays the same in both cases? I mean, you'd expect the framerate to be higher when using GL_TRIANGLE_STRIPS, since less indices need to be passed to the GPU.

My second question concerns the RemapIndices() function which will output an array of indices which in turn you can use to rearrange your vertex array so as to maximize spatial locality. I'm pretty sure I got this working correctly (I output the rearranged index list to a .txt file and indeed, the indices are much closer together now), but I'm not seeing any further framerate improvement. Is there any reason why this could be?

Share this post


Link to post
Share on other sites
As I understand it, you are right about SetListsOnly.

The reason you don't see any difference with this is that you are not transfer bound. If there's lot's of free time per frame for transfer, then taking less time to do it won't make any difference. Remember it's a pipeline - calculations are going on on the GPU while the transfer is taking place. If those calculatons take longer than the transfer, they will be the bottleneck, not the transfer.

Increasing spatial locality is meant to increase potential use of the post-transform vertex cache. If vert transformation isn't your bottleneck, you won't see any difference.

I'd guess your app is fillrate bound, most are.

Share this post


Link to post
Share on other sites
you're right

I was testing my program on a 3 year old laptop, but when I moved to a more recent system with a GeForce 7900 GTO it became clear that using SetListsOnly(false) and RemapIndices() is indeed faster than everything else.

if only I could rate you up some more

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • 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!