New demo

Humus

Crazy coder
Veteran
Here's a new demo quite similar to my old Infinite Terrain demo, except now the terrain is generated on the GPU in a pixel shader and rendered using R2VB.

infiniteterrainii.jpg


Download at the usual place:
http://www.humus.ca/
 
  • Like
Reactions: Geo
This demo doesn't seem to work... I'm not sure what I'm missing..
This is the error message I get:
"Couldn't Create Vertex Declaration"

Running a Radeon 9800 Pro with CATALYST 6.3...
 
On a slightly off topic vein : I'm not too familiar with vertex texturing, and therefore less so with render to vertex buffer. But I had always been interested in the potential of higher order surfaces and do not understand why render to vertex buffer can't work with something like n-patches. Explanations about this are greatly appreciated. Sorry for the OT! :)
 
Dang, sorry I forgot. R300 doesn't support half floats in vertex declarations. R420 and up does. Anyway, it was quick to fix. I've uploaded a new version that uses floats if halfs are not supported.
 
Ghost of D3D said:
On a slightly off topic vein : I'm not too familiar with vertex texturing, and therefore less so with render to vertex buffer. But I had always been interested in the potential of higher order surfaces and do not understand why render to vertex buffer can't work with something like n-patches. Explanations about this are greatly appreciated. Sorry for the OT! :)

Well, I don't see any particular reason why n-patches couldn't work with R2VB, though it's understandable that since it's not supported in hardware on anything above 8500, there's little interest in expanding the R2VB support to the software path.
 
Have you considered changing the texture based upon height and perhaps normals as well?

E.g. add snow if above a certain height and the slope is not too steep.

Just a though.
CC
 
Any evidence any ISV is working on picking this technique up? Or been any requests to driver-enable it to make it more transparent? It has been five months now since X1K release --I'm just wondering if there's been any developments on this front.

Edit: And, yes, a new Humus demo does tend to make me wonder in that direction. :)
 
question

Interesting demo. With a randomly generated terrain in the GPU, my question is how a possible game can calculate terrain physics for let's say vehicles running around.
 
vale said:
Interesting demo. With a randomly generated terrain in the GPU, my question is how a possible game can calculate terrain physics for let's say vehicles running around.
Yes of course it could, but it would slow it down more.
 
Captain Chickenpants said:
Have you considered changing the texture based upon height and perhaps normals as well?

E.g. add snow if above a certain height and the slope is not too steep.

Just a though.
CC

Well, I thought of it initially, but kind of forgot it. Maybe something for the traditional "couple-of-days-later-revision". :)
 
ants said:
Is there a way to use R2VB through OpenGL? New extension, FBO, VBO?

Thanks

There would have to be an extension. It was on the ARB's table for consideration for FBOs, but it has obviously not been prioritized. Interestingly enough, ATI had R2VB support in the OpenGL drivers a couple of years ago, in the expermental support for superbuffers. Unfortunately, after having been dragged through the ARB for long it was ultimately killed in favor of FBOs, which doesn't have this ability.
 
geo said:
Any evidence any ISV is working on picking this technique up? Or been any requests to driver-enable it to make it more transparent? It has been five months now since X1K release --I'm just wondering if there's been any developments on this front.

Edit: And, yes, a new Humus demo does tend to make me wonder in that direction. :)

What do you mean with "driver-enable"? You mean as a direct replacement for VTF? Personally I don't think it's going to happen, coding against R2VB is simple enough and will likely be faster than any attempt by the driver to implement VTF with multipass, which would also be a significant amount of work.
 
vale said:
Interesting demo. With a randomly generated terrain in the GPU, my question is how a possible game can calculate terrain physics for let's say vehicles running around.

Shouldn't be too hard. Just implement the same noise function in software and compute your physics there. You don't need to compute the entire terrain, just sample the function around objects that needs to be collision detected against the terrain.

Then there's also the possibility to do the physics on the GPU.
 
Humus said:
What do you mean with "driver-enable"? You mean as a direct replacement for VTF? Personally I don't think it's going to happen, coding against R2VB is simple enough and will likely be faster than any attempt by the driver to implement VTF with multipass, which would also be a significant amount of work.

Yes, that's what I meant. I recall some discussion along those lines originally is why I asked.
 
Out of pure curiosity I implemented VTF too, which was pretty straightforward. So it should run on GeForce 6 and up too now. Performance nowhere close to R2VB though. The 6600 got 27fps, compared to 272fps on an X850XT.
 
Humus , can i compare the fps between this and your old infinite terrain demo to see the performance differences between GPU and CPU or are they too different to make a legit comparison?
 
tEd said:
Humus , can i compare the fps between this and your old infinite terrain demo to see the performance differences between GPU and CPU or are they too different to make a legit comparison?

Well, it would be hard to compare anyway, since in the majority of the frames the geometry is not updated. If you press F5 you'll see the number of times it has updated the geometry, which changes maybe once every other second if you fly around. I guess you could compare triangle rates, but it's probably not very interesting.
 
Back
Top