chris wrote:Chuft-Captain wrote: Are you thinking along the lines of "virtual DEM's"? -- (analogous to virtual textures with the same sort of folder structure ( level0, level1, ... etc )
Yes, something like that.
A good idea as we'll be able to start with a high-res DEM and process it down into levels using Fridgers tools. (When you first spoke of a hierarchical arrangement, I thought you were intending some sort of proprietary hierarchical internal file-format.)
chris wrote:A cylinder is an ellipsoid with two equal, finite axes and one infinite one. Yet in practical terms, extra effort is still necessary to support adaptive tessellation of a cylindrical terrain map. My point is that given very limited time, I'm not likely to invest it in writing special code that has no purpose beyond rendering objects that don't actually exist. This is not meant to discourage you or anyone else creating speculative add-ons, which I do think are interesting. But, you should try and find methods of showing rendering these objects that use the existing features of Celestia. My focus is on implementing and debugging the more general features of Celestia, not ones that are specific to a particular add-on.
I'm not asking you to write "special" code for any particular addon...the O'Neills is just an example of an addon that uses a number of alternate geometries.
In fact I'm just trying to encourage a generic open-ended architecture...rather than designing for a specific geometry (eg. ellipses), however it seems from what you're saying that either each geometry requires it's own specialized code, or the act of coding in a more generic way will add too much extra code complexity that you don't want to have deal with for the specialized case of ellipses which is your priority.
It's clear that your priority is the rendering of standard convex bodies (planets, moons, etc). I'm just encouraging you to keep an eye out for opportunities to generalize your code when you start getting into it.
chris wrote: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.
I suspect that there are bottlenecks other than GPU geometry processing that are at fault--maybe inefficiencies in Celestia, or maybe your add-on.
Yes, I agree it's probably not to do with GPU. I think it's might be a bit of both of the last two. I have some observations from experiments which I'll email to you.
chris wrote: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)
You should write some tools to do this. Or search for some existing tools--I wouldn't be surprised if applications like Anim8or can apply a displacement map to a cylinder.
I'm not aware of any way to do this in Anim8tor. (If there is a way, it's not straightforward). I'm sure that the professional tools like 3DSMax (which I don't own
) will do this easily.
CC
