In article <3eaadd08@news.povray.org>, Wolfgang Wieser <wwi### [at] gmxde> 
wrote:

> > No...just enough to hold what you need to render, and use some
> > intelligence in setting up the scene. 
> >
> Just tell my why I should use "intelligence" doing complicated 
> viewport and culling calculations (think of animations) which require 
> a separate mesh include file for each frame if the problem could be 
> delt with in an easier and (as I think) more elegant way?

I never mentioned viewport calculations or culling. It doesn't require 
huge amounts of work...just don't use high resolution meshes where low 
res meshes are adequate.


> > A high resolution mesh of an
> > entire planet is ridiculous when you are viewing it from orbit. 
> (You need 1 million triangles for the visible half of a planet from orbit 
> (height is scaled by some factor to make it look more interesting) when 
> you look at it at diameter = screen height. Medium-sized, I guess...)


> > A binary mesh format would make loading
> > high-res meshes faster.
> ...and smaller on HD. 

Really, who cares about file size? It is only an issue when transferring 
files. I view it as simply a side effect of using a format more 
convenient for fast loading.


> There are 3 major advantages: 
> - may be faster than mesh2 because we save parse time. 

But if the goal is faster parsing, there are much simpler and more 
effective ways to accomplish it.


> - uses less memory while not requiring the user to do complicated 
>   viewport and grid size calculations. 

I've never suggested the user should have to do that.


>   This means, if you use a very deep scene (fly along a valley), 
>   it would produce nice scenery from a low/med-resolution mesh 
>   with constant grid size. 

Which could be done just as well before rendering.


> - And, as you mentioned: 
> > it only does it to the parts of the mesh where it is needed...

This seems to be the main advantage. Subdividing and displacing a big 
mesh could take a lot of CPU time, and limiting it to the needed areas 
would not be easy, so you would store more triangles than necessary. My 
main point is that memory use seems to be more of a side benefit, if it 
really can give a speed benefit. (time/CPU is much more costly than 
memory or storage)


> > There's macros that make spherical and cylinderical height fields. Not
> > toroidal or cubical though.
> > 
> IIRC these macros are just creating a mesh from the data. 
> And a cube is not needed. One can use 6 height fields instead. 

I'm not really sure what a cube would be defined as, but it wouldn't be 
very useful if it was simply 6 planar height fields. Maybe something 
more like the spherical height field, just using a cube as the base 
shape. I actually can't think of any use for it...it would probably be 
better to just implement subdivision/displacement for meshes.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message