Ogre Forums

Hi all.

These screenshots are from my (not so good) version of procedural terrain with marching cubes as as written about in GPU GEMS 3 ch 1. I tried to follow their code as much as possible, but using cg rather than HLSL and not having the gp4vp profile on me 8800GT caused me so much trouble; The biggest problem tho is that the ambo has to be calculated in geometry shader which makes it oh so slow, vp40 didn't have enough instructions for the density function which is needed for the long range ambo. I did do a faster method2 sort of version which just does short range ambo it created blocks in a more reasonable time frame about 1 every 0.1 of a second but looked ugly.

Hey, that's interesting. I am doing almost exactly the same thing on the CPU (without ao, although I am thinking of adding it), and had some thoughts about migrating to the GPU. I didn't try yet bc of physics and some performance concerns (ok, mostly because I am lazy).

What is the size of your volume?

0.1 second is a bit much for doing it in-between frames, did you try to split up the work over several frames?

For now each volumes is 32^3 voxels and in those shots theres 4^3 blocks, I'm sort of scrolling the blocks as the camera moves, I did write a lod system where there are multiple BlockScrolls as I call them but my shaders are too slow for it... you could break it up into multiple steps and call render on the RenderToVertexBuffer at different frames, in the book their 3rd method has about 6 steps don't know if their doing them cross frames but you could, but then again its probably so much faster they don't need to worry about it. I think the chapter said there method 2 was 22 times fast than method 1 and method 3 was another 5 times faster.

Very cool. Some of the terrain in that GPU Gems article was really neat looking. Your terrain is just missing a texture and it'll be right there. AO issues aside, you look like you're getting pretty good frame rate on short range stuff.

I have no idea how you'd do physics for this kind of terrain. Now that the current trend is that physics is migrating to the GPU, maybe this will be a more easily solvable problem in the near future.

Is this the same technique as used in this nvidia demo?
http://www.nzone.com/object/nzone_cascades_videos.html

In my opinion, terrain was always a very good application for geometry shaders, because often there is no interaction with it at the CPU side, apart from collisions which you could handle differently (using the heightmap or whatever).

Cool!

Greetz,
JeDi

That's an impressive framerate you get with it, very interesting and also very stimulating for me to finally look into shaders. Good work

Excellent work! I read that GPU gems article with great interest, and have been pondering about the possibility of porting some of my project to the GPU. I didn't know whether Ogre had the necessary functionality yet, but it looks like it does

You might also want to check out the NVidia Cascades demo that JeDi mentioned, you can get some useful tips on texturing.

Once again, good work!

those pics are looking sweet, love the AO

Nice effort!

you know, i cant help it, but those marching cubes terrains always make me think that with a little bit of ambient occlusion, perlin noise and subsurface scattering they would make incredible cloud systems.

Nice work, I love terrains like that.

mr. iknoweverything wrote:you know, i cant help it, but those marching cubes terrains always make me think that with a little bit of ambient occlusion, perlin noise and subsurface scattering they would make incredible cloud systems.

You might want to look into this paper: http://evasion.inrialpes.fr/Publications/2008/BNMBC08/
They use Perlin Noise to add cloud details.

Every time I look at those screen shots it gets better and better.
Very glacial looking.

@JeDi Its not the same technique they used in cascades its the first of three they gave, the simplest and slowest. I tried to go further but couldn't because of vp40 limit of 2048 instructions.

I spent both yesterday and the day before playing around with noise and making it somewhat dependent on things like surface normal to world up, midday sun angle, exposure, altitude, truly a black art ... but speaking of glacial.



The above noise applied with 2 triplanar textures.



I've found that using 2 textures looks good, 3 is ok if you have to and 4 oh dear god no.

So what I want is to come up with some notion of regions where the textures vary but the number sampled is limited to no more than 3, no idea how to do that though

Lately I've been trying to manipulate the "density function" so that I could carve tunnels and create paths, and other game type things. But more importantly I wanted to put three ogre heads into the side of a cliff.



Done by rendering all meshes on a certain render queue into the slices of a 3D render volume and moving the orthographic cameras near clipping plane for each slice, the density is then just attenuated by the texture. Unfortunately it will mess up long range ambo where the mesh is relatively big and it does mean render sections of the scene an awful many times... still I'm happy.

I've just noticed I've posted the wrong image and I no long have the right one
•sniffle•

Edit: This one shows it better

Sweet! Mount Ogremore.
Thats 4 all you pun aficionados out there

awesome work man!

Totally loving mount Ogre

Great .
What's profile can do this?
Is vs3.0,ps3.0 enough?