Anyone used VTF to do terrain rendering?

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.

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. :stuck_out_tongue: The method I used derives LOD from making farther terrain patches cover increasingly larger areas of terrain with the same amount of triangles.

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:-
http://tinyurl.com/dyrpxa
:slight_smile:
(don’t take that too personally, I’ve been dying to use it for ages…even if this occasion isn’t that appropriate)

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?

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.

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.