View Full Version : Anyone used VTF to do terrain rendering?

01-30-2009, 11:37 PM
I am thinking about switching to VTF to do my terrain rendering, but would like to know if anyone else here has tried this method and if they gained any speed from doing it this way? I know water rendering VTF is a great way to go from what I have read, but terrain...

02-01-2009, 03:13 AM
I have not the ability to use VTF for now with my current hardware but IMO it is not very interesting for terrain rendering assuming that your terrain surface is not as dynamic as water surface is. I think it is better to precompute terrain surface if you only have to modify it not every frame... This is just my opinion but I don't think VTF would have a performance impact if you use it for static terrain rendering.

02-01-2009, 02:32 PM
So in your opinion it would be better for deformable terrain rendering... I was hoping to see if anyone has done testing on this to see FPS differences so I don't waste my time... :)

02-01-2009, 07:00 PM
Not yet... But I will have HW capable of that in a couple of weeks.

I certainly have some things I want to try on this front, and I think you and I are working on similar things.. Planets, right?

I'll post back here with my findings as and when I have some.

02-02-2009, 01:20 AM
imho not supported by many ATI cards and wont be much of use atm, depends how much hardware needs to be supported. tried doing water animation with texture fetch which wasn't working on any ATI card (year ago). dont know about the FPS difference but locking/changing vertex buffers is probably costly.

02-02-2009, 05:00 AM
Whouuuu I so believe in VTF for terrain rendering!

But it's depend on your hardware and how scalable your engine is suposed to be. On GeForce 6/7, VTF is just soooo slow.

VTF is available and fast on Radeon X19** (Since may 2008) and GeForce 8 (since it realize)

VTF for terrain rendering allow significant memory bandwise reduction for a very higher resolution CLOD we no poping because of filtering.

So for my point of view it's not just about faster rendering it's also about higher quality.

Terrain rendering based on VTF should be since as and per bloc rendering and the memory reduction doesn't actually come much for the memory storage than from the actual rendering method.

One idea is to load a flat static mesh that fit in the frustum and to move this mesh according the camera position and orientation to process the vertex texture fetch.

The frustum mesh must be generated so that the resolution is higher close to the camera position just to take advantage of a good CLOD.

It's ease to make this terrain rendering technique scalable according the efficiency of the hardware, just generate lower or higher resolution terrain mesh.

02-02-2009, 11:16 AM
So, how are you doing CLOD with the VTF? You allowing mipmapping to do this of the texture in the vertex shader?

02-04-2009, 03:55 AM
I build a 2D flat mesh I attach to the camera position and one rotation axis. This mesh is static but provide higher resolution close to the camera origin and progressively reduce is resolution.

The terrain geometry is define in the camera space ...

Rosario Leonardi
02-04-2009, 08:39 AM
An example of this technique is explained in the GPU gem 2

An if you use float texture you can do VTF even in geforce 7 / ATI 1X00.

02-05-2009, 01:39 AM
i used it for geoclipmaps. Good performance on g80 cards - in fact it's *almost* as cheap to sample in vertex shader as it is in fragment shader. But if you have very high resolution meshes, you start to pay a price when multi-passing (drawing into shadow maps etc.). So, I switched to offloading displacement to one of the core's I have lying idle.

02-05-2009, 02:18 AM
I figured this would better for multi-pass rendering, since you could reduce the calls to the the Normals, Tangents ect... and just calculate them on the GPU.

02-06-2009, 08:24 AM
When I was implementing water projected grid, I first used R2VB via PBO. Then, on G80 cards, I switched to VTF path and it gave some FPS for me (of about 10%).
For terrain - can't say anything, not even tried yet.

02-06-2009, 10:04 AM
I once considered using VTF for terrain but changed my mind.
I simply consider heightmap terrain to be a set of static meshes that get updated ocasionally so I based my choice on theory that 1*update + 10*render is faster than 10*VTF render.

02-06-2009, 12:41 PM
The clipmap stuff is great, but frankly I'm getting really bored with the all the flatness. Been tinkering with some swiss cheese terrains, but LOD among other things is a real challenge (some sort of volumetric chunking might work here but haven't really tried anything yet).

On the whole, VTF has been very good to me.

02-06-2009, 03:17 PM
What about voxel tech? Can you use 3D textures in the VS?

02-07-2009, 07:38 AM
Like this (http://http.developer.nvidia.com/GPUGems3/gpugems3_ch01.html)?

Though as much as I love the procedural stuff, I was thinking more in terms of persistent, artist generated content, say using volumetric techniques as a base and allowing the artist to tweak the mesh to some degree, possibly even to define a simplified collision mesh, pathfinding nodes, what have you... But I digress.

Yes, it seems sensible to be able to access data en masse from a buffer of some sort from within a shader of some kind - be it a texture, texture buffer, uniform buffer, whatever is best suited to the task at hand. But by and large I would think 3D textures a bit overkill for the sparsely populated regions of your typical volume terrain.

02-09-2009, 02:46 PM
You can consider transform feedback buffer to reduce the number of VTF. 1 per frame instead of 1 per pass.

Nicolai de Haan
02-09-2009, 02:59 PM
Well, as I see it, wouldn't transform feedback sort of defeat one of advantages of using VTF - that of reducing bandwidth requirements?!
Instead of multipass for simple SM, what are the reasons why one could one not render with VTF to a FBO with a depth attachment in frame (n) and do a depth comparison with the map from frame (n - 1)? Is is technically possible and would it produce serious artefacts?</s>

I should have just read the whole thread from the start and not throw out retarded ideas :)

02-09-2009, 05:01 PM
i meant multi-pass as in having to draw with VTF from light pov, then draw with VTF from viewer pov (more times if using pssm). No way around it, both passes need to be done.
Terrain = outdoors = huge area to cover with a shadow map, so pssm needed.

02-14-2009, 04:06 PM
Erm, I haven't read the entire topic, but here's my (hopefully) relvant 2 cents. :)

VTFed terrain got my attention when reading Game Programming Gems 6 (there's a DX sample included) and I've implemented it in my OGL engine. I wrote a post on it on my blog (http://iqdev.blogspot.com/2008/11/gpu-terrain-rendering-in-opengl-part-1.html). It's a bit messy, but should be understandable. ;)

And actually, if you have the video memory to spare and go for float textures (as opposed to the 16-bit solution I proposed in the blog post), then all you need for this is SM3.0-capable hardware (meaning GeForce 6+ and Radeon X1000 series). That's 4-years-old technology now. :) So, unless you need more than reasonable backwards compatibility, I think it's a feasible solution.

02-15-2009, 02:45 PM
No, it's incredibly slow on geforce 6 class hardware. It's certainly not practical on those cards, when compared to other techniques. For geoclipmapping on those cards your only real option is render-to-vertex-buffer. Unless you don't care about framerates, of course.

02-15-2009, 03:02 PM
Well, from the screenshots of the DX demo in the book and the information provided in the text, I gather that it ran at 70-something FPS on a mobile (i.e. laptop) GF6600. Whether that's slow or not depends on your application, I suppose. And bad VTF performance on non-unified shader GPUs results mainly from linear filtering. It usually runs OK with nearest.

I have no idea what geoclipmapping is. :P The method I used derives LOD from making farther terrain patches cover increasingly larger areas of terrain with the same amount of triangles.

02-15-2009, 04:18 PM
well, VTF linear filtering isn't supported on older cards like the gf6 - you have to do it yourself by additional samples. Only one sample is necessary anyway in geoclipmapping if you pack fine and coarse heights into the same texture.
And slow is slow, regardless of your application. Compare VTF to just updating vertex buffers (especially if you're using a patch system anyway!). Using a standard vertex buffer update, staggered over many frames, you'll be able to draw many more triangles (higher detail) than if you were using VTF. If you're not bothered about the extra detail and you have nothing on your terrain (!) then just try adding decent quality shadows and watch your fps drop.
BTW, to say 70fps is completely meaningless. 70fps drawing how many triangles? Compared to a standard approach, what is the added cost of VTF on the same dataset? These are the questions you should be asking.

As for not knowing what geoclipmapping is:-
(don't take that too personally, I've been dying to use it for ages...even if this occasion isn't that appropriate)

Dark Photon
02-24-2009, 07:20 AM
I build a 2D flat mesh I attach to the camera position and one rotation axis. This mesh is static but provide higher resolution close to the camera origin and progressively reduce is resolution.

The terrain geometry is define in the camera space ...

Ok, so for mountains in the distance there'd be no attempt to focus more verts/tris in that area (or areas of higher curvature) like pre-computed TIN methods or view-dependent LOD would, correct?

Also just curious, do you support real-time time-variant terrain shadows?

Dark Photon
02-24-2009, 07:54 AM
i used it for geoclipmaps. Good performance on g80 cards - in fact it's *almost* as cheap to sample in vertex shader as it is in fragment shader. But if you have very high resolution meshes, you start to pay a price when multi-passing (drawing into shadow maps etc.). So, I switched to offloading displacement to one of the core's I have lying idle.

Yeah, besides that (multipass) one thing that gets me about geometry clipmaps is there is no attempt to focus your tri budget on areas of higher curvature. So it works for Kansas. Think the Rockies (or Alps in Europe) in the distance. Seems that you end up wasting boatload of tris (hits upload and render budgets) to get the curvature quality you want at say 80-270 miles. Lots more interesting things for the user to do with frame time. Precomputed TIN hacks this without the headache. Also makes laying line and area features on the terrain simpler, and simplifies texturing. Plus the whole "eye-centered paging/rendering" scheme demands a whole different approach when you consider aircraft sensors. Some of these bad boys have whole field-of-views that are mere fractions of a degree!

Haven't implemented geoclipmaps though. Am I way off base?

P.S. Plus it's patented. That just irks me. I don't trust MS based on their record.

Nicolai de Haan
02-24-2009, 08:35 AM
Not way off because the Geometry Clipmap algorithm is not sensitive to local features, it's both its strength and weakness - depending on how you look at it. However if generate your geometry differently (avoid rectangular rings centered at the viewer), you can still benefit from the advantages of the general Clipmap technique while allowing for some degree of local adaptivity (one example is the approach I sketched out in http://www.gamedev.net/community/forums/topic.asp?topic_id=504549). The Geometry Clipmap algorithm is designed to render very large datasets, with minimal memory footprint, with minimal CPU intervention, with reasonable image quality, with a high framerate. It succeeds in doing exactly that - but Geometry Clipmaps is obviously *not the right algorithm for everything*. If you wanted to design an algorithm that supported better local adaptivity, you would probably want to use a different mesh. If you thought the idea of modifying the terrain at runtime is fun, then maybe you would not spend too much CPU/GPU resources on compression. If you do not need to render very large datasets, you can do away with the whole out-of-core aspect of clipmaps. If you don't care about CPU usage then a TIN remains an attractive option because it gives you the best image quality for a given triangle budget. And so on... There's just no algorithm that is best in all cases, and all we can do is to pick ideas and features from here and there, and try combine them into something that's best for our particular use.