Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[John Hampson]

First of all, great work.  This is truely an awe-inspiring project.

I had a few questions I was hoping you wouldn't mind answering.  I was also working on a planet renderer a few years back with which I ran into a few problems, and by all accounts (watching your videos) you seem to have solved all of them.

The biggest issue I had was procedurally generating the terrain diffuse maps and normal maps at anything near a fast enough rate.  I was torn at one stage between generating actual diffuse and normal maps (textures) for each node in a generation phase, then sampling them in a shader, or passing vertex information about height and slope of each vertex along the vertex stream and generating a colour, per-pixel (and forgeting the normal mapping).

Both seemed to have pros and cons, the first method, generating the diffuse and normal maps, provided better visuals but was very slow when the patches subdivided (x4 nodes, x2 map generations would stall the GPU for a few 10's milliseconds) and was also quite heavy on the video memory.

The second method, sending height and slope information in the vertex stream and using a look up texture for the index to a ground material looked quite good on the ground, but because of the differences in terrain nodes LOD (after a subdivide), the popping was really bad.

In all your videos I cannot make out any vertices, which suggests a really high-resolution / fine tesselation and also, the lighting looks great.  

And are you still using O'Neils scattering paper for the atmosphere, which again looks superb!

thanks a lot,

-John

[cameni]

Hi John.
We are basically using the first approach, generating the diffuse maps. Or, actually, it's got about 5 different modes of operation depending on the level of detail. Yes, it's heavy on video memory so there's a lot of optimizations (like compression) and a crucial module is limiter that keeps the data under the required size.

But what was taking you a few tens of ms there? Not that it is the fastest thing under the sun, but it runs much much faster here. Perhaps it's crucial to optimize that part first.

We are not using O'Neils scattering anymore, but a derived version of Bruneton's atmospheric scattering. Optimized for performance for the price of some features.

[John Hampson]

Thanks for your reply Cameni,

I guess you are right about lack of optimisation being the key factor in the poor performance. But I also found that often when one node is subdivided then so are its neighbours, cascading down the depths making more splits and requiring many texture generation calls to be made.  So while it is only x4 new nodes per split, there was actually 5 or 13 ... node splits in total.

I'm also really impressed how the textures look on the ground in all your shots and videos.  Are you generating 512x512 at highest (orbit) level and 256x256 at lower quadtree levels?  And for each node a heightmap, normal map and diffuse map?

I ask this because again your texturing looks awesome, I can only guess you set the quadtree nodes to split at a relatively far distance so you get the maximum effect of the textures (i.e. they appear hi-res).  For me because I was subdividing the nodes quite close to the camera, the size of the nodes on screen meant even 512x512 textures where stretched and grainy, appearing low resolution.

Anyway, great work, and thanks for the reply.  I might actually dig up the project and see if I can't get to run better (now I have something to focus on).

[cameni]

To give you some numbers, we are getting slightly less than 200 tile generator tasks executed per second, for a total of 200ms spent on it. Meaning it takes roughly 1ms on GPU co create the textures for one quadtree node.

The tiles are generated in 256x256 consistently everywhere, although we may later switch to 512 for a better performance on newer cards. Heightmap is temporary, unless it's needed elsewhere too (physics). Other textures may be stored, compressed, depending on quadtree node class.

There's a quality metrics that forces the splitting, that is +- based on the on-screen stretching of the tile. With 256x256 tiles it means a quad gets split whenever it's stretched more than 256 pixels on screen, times some quality coefficient. This keeps the quality consistent with what you actually see.

[John Hampson]

Thanks a lot Cameni,

The information you provided is really helpful, not least because it means that the direction I took is plausible for getting good results.  Outerra really is an inspiration when it comes to planet and just general graphics rendering.

Thanks for taking the time,

-John