Archived

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

Indices of static geometry

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

Is it of any significant advantage to put indices of static geometry within NVidia vertex array range? I am already using it for vertex data. Any other tips on optimal use of NVidia vertex arrays?

Share this post


Link to post
Share on other sites
quote:

Is it of any significant advantage to put indices of static geometry within NVidia vertex array range?


No. In fact, it will tremendeously slow down your program. On nVidia hardware, indices are always streamed by the CPU (although that might change with the GF-5). So the CPU would read them from AGP or VRAM (very slow), process them a little and stream them back to the 3D card. Very inefficient.

Just put all vertex data into the VAR (coordinates, colours, texcoords, normals, your own user attributes if you use vertex shaders, etc). The indices should stay in normal system RAM.

Things are different on ATI Radeon hardware. It ssupports hardware index arrays, and this functionality is exposed in the VAO extension.

/ Yann

Share this post


Link to post
Share on other sites
You mean wglAllocateMemoryNV() ?

What parameters do you use for the call (the 3 floating point ones) ? It shouldn't be a problem to get VRAM on a GF2MX. Do you have the latest drivers ?

Oh: how much are you trying to allocate, and how much VRAM does your MX have ? Keep in mind that VRAM is used for the framebuffer, the textures, display lists, etc. So there might not be enough left to satisfy your allocation request.

/ Yann

[edited by - Yann L on August 26, 2002 6:29:37 PM]

Share this post


Link to post
Share on other sites
Hmm, 1MB of VRAM should not be a problem. That''s weird, I''m not aware of any VAR related problems on the GF2MX.

Calling it with (1000000, 0, 0, 0.5f) for AGP memory works ?

Also, be sure to put the allocator call at the very beginning of your app, just after getting a valid OGL context. Although the command itself does not need a valid context, it will be required to allocate VRAM on the 3D card. But alloc your VRAM before loading any textures, that''s important. You don''t need to directly define the VAR, just get the memory.

/ Yann

Share this post


Link to post
Share on other sites
Thanks for the help so far . I got the VRAM allocation working by loading textures after allocating VRAM. Fps gain isnt trumendous though (atleast on my system). But then fill rate is probably my problem. any advice will be appreciated. Do you think texture compression is a good idea?

SporadicFire.

Share this post


Link to post
Share on other sites
I you aren''t geometry limited, then the performance gain won''t be very high (esp. on < GF3 cards).

quote:

But then fill rate is probably my problem. any advice will be appreciated. Do you think texture compression is a good idea?


Yep, it is. The smaller the memory footprint of the textures, the faster the access, and the higher the fillrate. An easy way to try it out, is to set the internal format to one of the s3tc/dxtc formats. You should get a speedup from that.

If you are fillrate limited, you should also try to avoid overdraw. Perhaps look into occlusion culling techniques.

/ Yann

Share this post


Link to post
Share on other sites
quote:

Already looking into occlusion culling techniques.. any good techniques that you know for outdoor environments?


I was about to link to that outdoor occlusion thread, when I realised that it was you who posted it... doh...

What I do in our engine is very simple, yet pretty effective. It''s not so easy to explain. So you have your terrain (mine is not a heightmap, but that''s not important. It will also work with heightmaps). You have small and large features on that terrain, from small little rocks to large mountain-like formations. The small ones don''t create very much occlusion, and we can ignore them. The large ones create lots of occlusion.

What I simply do, is use a heuristic that first recognizes those large features, and isolates their geometry (in your case, that would be the part of the heightmap they occupy). It then creates a volumetric representation of that feature using boxes, that are positioned under the terrain. In such a way, that no box will ever intersect the terrain at any point, but will still fill the maximum possible volume under the large terrain feature.

Those box constructs are then labeled as occulsion geometry. They are static (if your terrain doesn''t change), and can be rendered very efficiently. Before rendering a frame of the game, I render those boxes into an offscreen buffer (no texture or lighting required). I also render the occlusion geometry of other objects (ie. the outlines of large features in a 3D town, eg. walls, large houses, etc). Since it''s an image space method, it will automatically take care of occluder fusion.

Last step is to perform an occlusion test on each part of the terrain before you render it (using it''s bounding box). That can be done in software, or hardware on GF3+.

/ Yann

Share this post


Link to post
Share on other sites
Ok, i think i got it...correct me if im wrong:

First you render volumes that are inside the objects (such as under the terrain) to an offscreen depth buffer, keeping the nearest points. Then for each bounding box of geometry (border volumes of a solid object) that needs to be rendered, you test against this buffer to see if the bounding box is completely occluded. and if no part of the bounding box is eligible to be rendered, then you dont render the geometry and move on to the next one. hmm...similar to an algorithm i read...but it uses a buffer instead of manually performing occluder fusion.

how does one do the last step in software... i know there is an occlusion test extension by NVidia that does it in hardware..

Share this post


Link to post
Share on other sites
In our engine at work i used a software-based occlusion culling technic, since it has to run on any graphic card.

In a preprocessing step, i generate a list of "potentially" good occluders. This step is done by merging neighboor triangles together to form a big occluder, while trying to stick to a convex polygon. Then, i reject occluders that are too small. This results in a small number of occluder polygons for a complete scene (don't remember the numbers exactly, but it's around 1000 occluders for a 250000 triangle scene).

At run-time, i allocate a fixed amount of time (2 milliseconds) to do occlusion culling. I sort the occluders by effectiveness (based on the distance and the occluder area), and then i only process as much occluders as i can in the allocated time. For each occluder, i generate a shadow volume which is tested against the scene octree like in a standard frustum culling method (it's basically the same code). It works because the shadow volume is convex.

On a PIII-500, i was able to test around 50 occluders in these 2 milliseconds, which is enough since it's the 50 "best" occluders for the given frame.

Y.


[edited by - Ysaneya on August 28, 2002 3:33:31 PM]

Share this post


Link to post
Share on other sites