Outerra forum

Outerra Engine => Technology => Topic started by: Anastomosis on November 13, 2011, 07:29:09 am

Title: CPU vs GPU
Post by: Anastomosis on November 13, 2011, 07:29:09 am
Hi, I'm very impressed by this engine, as most of us are. I had some questions about some of your techniques, if you don't mind. I have been dabbling in LOD terrains and have been curious about a couple things in Outerra.

1. You use Earth data with 76m resolution. You then interpolate between the points using a bicubic technique. For the interpolation, are you using the CPU or are these extra vertices created on the GPU? If they are GPU vertices, how then do you do accurate collision detection - do you have to read back the data from the GPU?

2. Regardless of where it happens, when you say "bicubic" are you basically using Catmull-Clark? Or Bertram's surface wavelets or something else?

3. A similar question to #1 - I really love the physics of the trucks on the dirt road, but here also you say the roads are entirely created on the GPU. Again, the collision detection here is amazing, is that all done GPU side as well? (I apologize as my knowledge of physics engines is limited but I do know that they are all pretty much CPU/software based). Is the data read back to the CPU for this collision purpose?

4. What resources do you suggest for someone learning how to use advanced fractal techniques on the GPU like you demonstrate? What math did you know beforehand, and what basic math do you use when writing these shaders?

Thanks a lot!
Title: Re: CPU vs GPU
Post by: cameni on November 13, 2011, 08:31:37 am
Hi,
1. The interpolation is being done on the GPU, and yes, we have to read back some of the generated data for collision purposes.

2. Since the grid is regular, it's a simple bicubic interpolation (http://en.wikipedia.org/wiki/Bicubic) scheme, with modulated noise being added to the refinement process on top. I'm sure the more general techniques reduce to this on the grid. One can also use other wavelet basis functions, in fact bicubic has some weak spots - it overshoots on steep cliffs, which becomes more of a problem with the use of better base resolution.

3. The roads are defined as vector data, and they are applied on the terrain on GPU using a blending shader that merges it with the existing terrain, to seamlessly blend it in there. Regardless of whether the road is or isn't there, the collision data are asynchronously read back to CPU and the collision computations are done there. Some parts of it could be executed on the GPU, but not all (effectively).

4. Well, I'm mostly self-taught in these regards, I even studied Automation at the university instead of Computer Science. As it went, in Automation we drilled theory of control and automation, and the computers were used as a tool, in much more practical ways than the CS guys did ... so I ended up inventing and reinventing lots of things, and enjoying the process 8)
You see, I can really only give recommendations to myself, which would be mainly to tinker with the stuff a lot and google around for papers on techniques that could be of use or inspiration. The math is nothing special indeed, just your usual common techie university basics. And some skills to read academic papers.
And lots of time and passion :)
Title: Re: CPU vs GPU
Post by: Anastomosis on November 15, 2011, 04:16:52 pm
Thanks for the quick reply. It was very helpful. I've been playing around with sending data from my GPU asynchronously since your post.

So the fundamental thing you are doing, it seems - underlying all of your engine, is creating vertices on the GPU. This is probably a no-brainer to a lot of people, but the majority of my experience is with D3D9 still, which is all pre-geometric shaders as you probably know. I would like to start with OpenGL and/or D3D10-11, but that means I have to leave XNA. Oh well. Had to happen sometime.

What is the minimum version of OpenGL that will let you create vertices on the GPU? And which are you using?

Thanks again.
Title: Re: CPU vs GPU
Post by: cameni on November 15, 2011, 05:33:57 pm
We are using OpenGL 3.3, but the core of the terrain generation algo worked even on the lower versions, initially we even used version 1.2. You don't need geometry shaders for it, in fact they are usually too slow anyway, except for some special cases.

We are extensively using techniques like render to texture and render to VBO, which allow you to use shaders to generate vertex buffers and textures. That's all you need. Higher API versions mainly bring you more combinations and target types you can use, but the essential techniques are pretty old ... and underused. Most people don't even know about r2vbo.