Outerra forum
Outerra Engine => Technology => Topic started by: giucam on March 15, 2014, 12:08:14 pm
-
Hi Cameni,
I'm working on a planetary renderer myself in the spare time, and I'd want to ask you a couple of questions. I currently can render the planet, using the warped cube method, with one quad tree per face using a modified CDLOD (http://vertexasylum.com/2010/07/11/oh-no-another-terrain-rendering-paper/) terrain rendering algorithm (btw, CDLOD morphs nicely between LOD levels so I have no popping like in Outerra :P).
I am now looking at rendering (rail)roads and I am a bit lost. I found this (http://hal.archives-ouvertes.fr/inria-00207679) paper by Eric Bruneton, and I suspect you're using a similar approach, right? That article is really interesting but it doesn't go much into the details of how it is implemented. I wonder if you could share some details of how that works in Outerra, that would be really helpful. I think I more or less understood how the rendering works, but how is the data organized? When a new road is created do you store the bezier curves in the quadtree leaf? How does that data go then up in the tree when you move the camera away? And do you keep all the vector data in memory?
-
I'm bad at reading papers quickly so I can't be sure, but that description seems to be quite detailed, though quite sophisticated as usual for Bruneton. Btw isn't this included in the sources that he had released?
From what I got from the description, it's different to what we are doing. Our vector data are anchored to the coarsest terrain level when they should appear, and applied to the descendant tiles as post-process in the generator stage, that modifies the terrain and materials.
Terrain popping ... something I haven't bothered to implement yet, trivial things have a tendency to get pushed away :)
There are some potential complications when it has to play nicely with the terrain cache and the quality metrics, but a simple version should be easy to add.
-
I'm bad at reading papers quickly so I can't be sure, but that description seems to be quite detailed, though quite sophisticated as usual for Bruneton. Btw isn't this included in the sources that he had released?
I guess it is in Proland but reading and understanding its code would take me more time than doing trial and error with my piece of code.
From what I got from the description, it's different to what we are doing. Our vector data are anchored to the coarsest terrain level when they should appear, and applied to the descendant tiles as post-process in the generator stage, that modifies the terrain and materials.
That makes sense. Much more scalable than keeping everything in the root node like in the paper. Do you then render the splines onto one or more textures per node and use those when rendering the terrain?
Terrain popping ... something I haven't bothered to implement yet, trivial things have a tendency to get pushed away :)
There are some potential complications when it has to play nicely with the terrain cache and the quality metrics, but a simple version should be easy to add.
Sure, i was joking ;)
-
Do you then render the splines onto one or more textures per node and use those when rendering the terrain?
Yes, basically. An auxiliary texture that's used to alter the terrain parameters.