chris wrote:Some sort of hierarchical arrangement is necessary if you want to use large sets of topographic data. You only want to load the sections of the file that are in view and have the appropriate level of detail (i.e. if you're in low Earth orbit, you don't need 1m height data.) Preprocessing raw DEM files (or PNGs, or some other format) can dramatically improve performance for interactive terrain rendering. I'm just getting started with this, and at the moment I'm focusing on adaptive subdivision of smooth spheres and improving virtual texture performance. I'll certainly be doing more research and asking for input on how best to support terrain maps.
Are you thinking along the lines of "virtual DEM's"? -- (analogous to virtual textures with the same sort of folder structure ( level0, level1, ... etc )
chris wrote:... The tricky part of all of this isn't displacing vertices, it's the adaptive tessellation of the surface. For that, you need to be able to calculate two things: 1) the distance from the viewer to the surface, and 2) a bounding volume for a surface patch.
My thoughts on this would be that the actual distance from the viewer is not the key issue, but rather the relation between polygon size and distance (ie. apparent polygon size) -- The decision as to whether to further sub-divide or not depends on the angle subtended by the polygon from the observer's viewpoint.
EDIT: I expect that a 200m sized feature observed from 1km distance would receive the same level of detail as a 20km sized feature observed from 100km (assuming the same FOV). Would you agree?
eg....some more pseudo-code...
Code: Select all
for p in all-polygons-in-FOV
{
if angle-subtended-by-polygon( p, observer ) > some-threshold-theta
{
subdivide( p )
}
}This means that the amount of tessellation/subdivision would also increase if you used the ',' key to zoom in to an object, without actually changing the distance.
(Just one other thought...It might be quite a good idea to allow the degree and/or threshold of tessellation to be configurable in celestia.cfg)
chris wrote:For spheres, this isn't difficult; for ellipsoids, it's a bit harder, but still manageable. The other interesting surface type would be a triangle mesh, but adaptive tessellation of an arbitrary mesh would require much more complex code than the restricted case of ellipsoids. Applying a height map to other parameterized surfaces like torii and cylinders is only useful in very specific cases. The extra effort required to support them doesn't seem justified to me.
Sorry, perhaps a misunderstanding. I wasn't trying to suggest doing this for complex
irregular meshes, but rather a limited set of "simply defined mathematical curves". ie. A way of telling the "convolve" function where the center of the base geometry is, which way to orient the normals, which direction(s) to "bend" the terrain, and by how much (ie. what's the radius of the curve).
In this sense, putting the terrain on the inside of a concave sphere is just the reverse of putting it on the outside of a convex one (the simple planetary case), and IMHO is
EDIT: only slightly more complex as it's just a matter of performing the vector transformations in a different direction and recognizing that the mesh normals are reversed.
A cylindrical curve is just a simplified version of the spherical curve, with curvature in 1 dimension, and flat in the other direction.
I hadn't considered a torus, which I agree would be somewhat more complex, requiring 2 different radii of curvature. (although you could argue it's just the same as the sphere but with a smaller radius of curvature in one of the 2 dimensions.
)
I'm not suggesting you create a whole lot of complex code to handle all these geometries in the first iteration, just that you take the possibilities into consideration in the
design of your code so that it's easily extensible.
Thinking of base geometries in terms of how they are defined as origins and curves in mathematical/spatial terms rather than specific shapes or meshes, and incorporating this principle into your design, will I think facilitate this.
chris wrote:If you want to have a terrain map inside an O'Neill cylinder, why not just do this in your modeling software? Is adaptive tessellation and level of detail essential for your models?
I think the number of polys in the current design of the O'Neills is already pushing the performance of 88 series cards, so I think in the long-term that it will become impossible to add any level of detailed terrain without some form of adaptive sub-division.
To be honest, in this context, I would be happy in the short/medium term, with an easy way to conform a DEM or DEMs to the underlying geometry, even without adaptive tessellation. (Some compromises in the # of vertices would just have be made)
However, once the observer gets down into the terrain at ground level and starts travelling through it, I think this is when it becomes necessary in the long-term to have some form of adaptive tessellation as well, because the number of vertices you'd need to make the terrain appear realistic at close range, would make it un-usable in terms of frame-rate because ALL those poly's would have to be rendered, even if 20 km away in the distance.
Have a look at Eric Bruneton's RAMA video
HERE to see what I'm on about. (It's well worth the 88MB download
)
CC
