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…
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.
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… 
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.
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.
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.
So, how are you doing CLOD with the VTF? You allowing mipmapping to do this of the texture in the vertex shader?
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 …
An example of this technique is explained in the GPU gem 2
http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter02.html
An if you use float texture you can do VTF even in geforce 7 / ATI 1X00.
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.
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.
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.
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 1update + 10render is faster than 10*VTF render.
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.
What about voxel tech? Can you use 3D textures in the VS?
Like this?
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.
You can consider transform feedback buffer to reduce the number of VTF. 1 per frame instead of 1 per pass.
Well, as I see it, wouldn’t transform feedback sort of defeat one of advantages of using VTF - that of reducing bandwidth requirements?!
<s>
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
?
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.
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. 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.