I just read this paper and found it to be very interesting as this could 
perhaps be implemented in POV:

http://www.cs.utah.edu/~bes/papers/height/

I also found some other papers anout this topic but they described 
either something like isosurfaces or required things that are surely not 
going to be implemented in POV like memory coherent raytracing.

Post a reply to this message

In article <3ea07feb@news.povray.org>,
 Simon Adameit <sim### [at] gaussschule-bsde> wrote:

> I just read this paper and found it to be very interesting as this could 
> perhaps be implemented in POV:
> 
> http://www.cs.utah.edu/~bes/papers/height/
> 
> I also found some other papers anout this topic but they described 
> either something like isosurfaces or required things that are surely not 
> going to be implemented in POV like memory coherent raytracing.

Neat...I was talking about something similar to this in a thread on 
scanline vs. raytracing renderers, about generating grass on the fly, 
creating the blades when testing them against a ray...I didn't think it 
was practical, but maybe it is after all. Render-time subdivision of 
meshes is something that I've been interested in for a while, though 
this is more sophisticated than any ideas I've come up with.

I'm not too sure of the usefulness though. I mean, memory is really 
cheap, especially compared to CPU power, and there has to be some render 
speed penalty for this. On the other hand, this technique could be 
adapted to make grass and other plantlife that could stretch even todays 
memory capacity, even with tricks like duplicating patches. And it has 
the advantage of only generating the triangles that are really tested 
against rays, which could actually make it faster overall.

-- 
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

Christopher James Huff wrote:

> I'm not too sure of the usefulness though. I mean, memory is really
> cheap, 
>
Well...
Ever tried to render a several-million-triangle mesh with POVRay?
If you want to trace topography data you run out of memory much faster 
than you think. 

Staying at that example, a 1-million-triangle topography of a planet looks 
not very well unless you add some "artificial" complexity like 
subdivision surfaces. Or, maybe, something these people described 
"addition of large amounts of geometric complexity into models". 

Wolfgang

Post a reply to this message

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

> Ever tried to render a several-million-triangle mesh with POVRay?
> If you want to trace topography data you run out of memory much faster
> than you think.

Well, then you better get system with a 64 bit processor, or use a
heightfield.  If a desktop level system with a 32 bit processor can't handle
the amounts of data, that is hardly a problem of POV-Ray...

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

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

> Ever tried to render a several-million-triangle mesh with POVRay?

No, but it shouldn't be a huge problem given enough RAM. A few million 
should stay well within the capabilities of 32 bit systems. If memory 
space is restricted, this algorithm could be very useful.


> If you want to trace topography data you run out of memory much faster 
> than you think. 

Why? What makes topography data inherently more memory consuming than 
other meshes?


> Staying at that example, a 1-million-triangle topography of a planet looks 
> not very well unless you add some "artificial" complexity like 
> subdivision surfaces. Or, maybe, something these people described 
> "addition of large amounts of geometric complexity into models". 

This doesn't require doing it at render time, at the expense of CPU time 
that could be used for actual rendering.
Besides, why would you use a 1 million triangle mesh of an entire planet 
when you are close enough to see geometry that can't be represented with 
that mesh?

-- 
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

Thorsten Froehlich wrote:

> In article <3ea6d1e3@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>
> wrote:
> 
>> Ever tried to render a several-million-triangle mesh with POVRay?
>> If you want to trace topography data you run out of memory much faster
>> than you think.
> 
> Well, then you better get system with a 64 bit processor, 
>
Oh, have one for me?

> or use a heightfield. 
>
Correct.
But what I need is actually a height-SPHERE, so I'm back to plain mesh. 

> If a desktop level system with a 32 bit processor can't
> handle the amounts of data, that is hardly a problem of POV-Ray...
>
Well, in some way it IS. Because one could imagine an algorithm which 
uses less memory (at the expense of CPU time), but only for the 
specialized problem of a height sphere. 

But, I agree: The fact that a genuine mesh does not fit into RAM is 
not a POVRay bug because I see little chance to significantly reduce 
genuine mesh RAM consumption (after looking at the POV code). 
 
Wolfgang

Post a reply to this message

>> Ever tried to render a several-million-triangle mesh with POVRay?
> 
> No, but it shouldn't be a huge problem given enough RAM. A few million
> should stay well within the capabilities of 32 bit systems. If memory
> space is restricted, this algorithm could be very useful.
> 
The amount of consumed memory _IS_ the problem. 
Each triangle consumes quite a lot of memory. 
(Rendering 1 million triangles consumes 180 MB RAM, at least that is 
what I just measured.)

>> If you want to trace topography data you run out of memory much faster
>> than you think.
> 
> Why? What makes topography data inherently more memory consuming than
> other meshes?
> 
The problem is that in order to get a nice image of topography data 
it needs to have a very fine grid. Which requires either
- a huge amount of triangles
- an algorithm which adds subdivision surfaces or something similar 
  producing a decent image (the fine details won't be actual totpgraphy 
  but _look_ nice) -- but I repeat myself
- some other trick?

>> Staying at that example, a 1-million-triangle topography of a planet
>> looks not very well unless you add some "artificial" complexity like
>> subdivision surfaces. Or, maybe, something these people described
>> "addition of large amounts of geometric complexity into models".
> 
> This doesn't require doing it at render time, at the expense of CPU time
> that could be used for actual rendering.
>
?! You mean I should buy 256 GigaB RAM?
Furthermore, adding the complexity at render-time will effectively be 
faster because we save such a lot of parse time: 

One million triangles topography data showing the visible half of 
a planet traced at 800x600 full quality, two light sources, no 
anti-aliasing: 

Time For Parse:    0 hours  4 minutes  36.0 seconds (276 seconds)
Time For Trace:    0 hours  0 minutes   9.0 seconds (9 seconds)

That's a ratio 30 : 1 (!)

> Besides, why would you use a 1 million triangle mesh of an entire planet
> when you are close enough to see geometry that can't be represented with
> that mesh?
> 
First of all, there may be reasons: It is hard to know which triangles 
are needed for reflection. (I mean: Ever saw the hollow (culled) back-face 
of a planet on a reflective surface of a space craft?)

And then, maybe you are not aware about how many triangles you need 
for a decent landscape...
Of course, one could use meshes with different grid size for different 
image camera distances which brings other problems (wholes in surface, 
lots of meshes for camera flights). 

The easiest solution for the mentioned problem would be to implement a 
height sphere for POVRay using only 2 bytes per triangle (storing the 
data as 16 bit spherically-mapped height field). 

But the more general solution would be some support for auto-generated 
"artificial" complexity in meshes (added at render time). 

Or, maybe, support for "mesh textures" for primitive objects (i.e. 
height fields on top of sphere, cylinder/cone, torus)

Wolfgang

Post a reply to this message

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

> The amount of consumed memory _IS_ the problem. 
> Each triangle consumes quite a lot of memory. 
> (Rendering 1 million triangles consumes 180 MB RAM, at least that is 
> what I just measured.)

And I've seen 256MB modules for less than $30, 1GB is well within the 
reach of a serious hobbyist. A 1GB system could handle several million 
triangles, more or less depending on how efficiently the mesh can be 
stored.


> > that could be used for actual rendering.
> >
> ?! You mean I should buy 256 GigaB RAM?

No...just enough to hold what you need to render, and use some 
intelligence in setting up the scene. A high resolution mesh of an 
entire planet is ridiculous when you are viewing it from orbit. If you 
are close enough to see details, you don't need anything close to the 
entire planet.


> Furthermore, adding the complexity at render-time will effectively be 
> faster because we save such a lot of parse time: 

You assume there is no way to increase loading speed. In your planet 
example, a low-res planet mesh would take little time to parse, and a 
high-res landscape height field would be much faster loading than an 
equivalent mesh, because it involves opening a binary image file instead 
of parsing a scene description. A binary mesh format would make loading 
high-res meshes faster.


> First of all, there may be reasons: It is hard to know which triangles 
> are needed for reflection. (I mean: Ever saw the hollow (culled) back-face 
> of a planet on a reflective surface of a space craft?)

It's not going to matter. You aren't going to be able to tell the 
difference between a high-res and low-res planet mesh when seen 
directly, certainly not when you are viewing a reflection of it on a 
ship.


> And then, maybe you are not aware about how many triangles you need 
> for a decent landscape...

Quite a few. Not enough to be a problem. I have mentioned the example of 
grass and other plants though, which could probably benefit from it.


> The easiest solution for the mentioned problem would be to implement a 
> height sphere for POVRay using only 2 bytes per triangle (storing the 
> data as 16 bit spherically-mapped height field). 

It's unnecessary, and not the easiest solution, but it is possible. It 
might be possible to add some additional optimizations to improve speed.


> But the more general solution would be some support for auto-generated 
> "artificial" complexity in meshes (added at render time). 

Auto-generated mesh complexity is not a bad idea, but doing it at render 
time involves inefficiencies that could make it slower than just doing 
it on the mesh and storing the higher resolution version. On the other 
hand, it only does it to the parts of the mesh where it is needed...so 
in some cases, it could be faster.


> Or, maybe, support for "mesh textures" for primitive objects (i.e. 
> height fields on top of sphere, cylinder/cone, torus)

There's macros that make spherical and cylinderical height fields. Not 
toroidal or cubical though.

-- 
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

Christopher James Huff wrote:

>> > that could be used for actual rendering.
>> >
>> ?! You mean I should buy 256 GigaB RAM?
> 
> 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?

> 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...)

> If you are close enough to see details, you don't need anything close 
> to the entire planet.
> 
Correct. Did I doubt that?

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

>> But the more general solution would be some support for auto-generated
>> "artificial" complexity in meshes (added at render time).
> 
> Auto-generated mesh complexity is not a bad idea, but doing it at render
> time involves inefficiencies that could make it slower than just doing
> it on the mesh and storing the higher resolution version. 
>
There are 3 major advantages: 
- may be faster than mesh2 because we save parse time. 
- uses less memory while not requiring the user to do complicated 
  viewport and grid size calculations. 
  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. 
- And, as you mentioned: 
> it only does it to the parts of the mesh where it is needed...
 
>> Or, maybe, support for "mesh textures" for primitive objects (i.e.
>> height fields on top of sphere, cylinder/cone, torus)
> 
> 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. 

Wolfgang

Post a reply to this message

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

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

>> Well, then you better get system with a 64 bit processor,
>>
> Oh, have one for me?

Sure, it costs only about 400 Euros more than an Aldi PC ;-)
<http://store.sun.com/catalog/doc/BrowsePage.jhtml?cid=85825&parentId=48612>

> But, I agree: The fact that a genuine mesh does not fit into RAM is
> not a POVRay bug because I see little chance to significantly reduce
> genuine mesh RAM consumption (after looking at the POV code).

Indeed, there is little that can be done about it.  And it already uses
"only" 32-bit floats...

    Thorsten

Post a reply to this message

Christopher James Huff wrote:
> In article <3eaadd08@news.povray.org>, Wolfgang Wieser <wwi### [at] gmxde> 
> wrote:
> 
> 
> 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 has to be a reason why the reyes algorithm is still used ;-)
The problem is that if you hit a memory limit there often is not much 
you can do about it besides buying more memory, with time/CPU you can at 
least wait. And it's not only the geometry that has big memory 
requirements but also radiosity, photon mapping, etc..

Post a reply to this message

Thorsten Froehlich wrote:

> In article <3eaa7ff7@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>
> wrote:
> 
>>> Well, then you better get system with a 64 bit processor,
>>>
>> Oh, have one for me?
> 
> Sure, it costs only about 400 Euros more than an Aldi PC ;-)
><http://store.sun.com/catalog/doc/BrowsePage.jhtml?cid=85825&parentId=48612>
>
:) Nice, but...

>The Sun Blade[tm] 150 workstation is an affordable, full-featured, 64-bit
>workstation with a 550/650-MHz UltraSPARC[R] IIi processor, up to 2 GB of
>memory
>
Oh, just up to 2 GB of RAM?
The issue was to be able to use more than 4 GB...

Wolfgang

Post a reply to this message

Christopher James Huff wrote:

>> 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.
> 
The alternative is to use 100 million triangles. 
95% will be useless but the foreground needs needs the fine grid. 

Either smart "intelligent" mixed-resolution meshes with (at least 
primitive) viewport culling or a very fine mesh is required. 
OR, subdivision at render time. 
Anything else?

>> > 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.
> 
When rendering films, file size gets interesting, especially if you 
need a separate mesh for each frame. And when rendering the film in 
a distributed environment the issue is transferring the meshes. 

But that's not the major issue we're talking about here. 

>>   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.
> 
Which results in a 100 million triangle mesh.
Or requires some "intelligent" mixed-resolution mesh and triangle culling. 
AND it requires knowledge of the camera position which means that a 
separate mesh is needed for each frame. 

Oh dear... we're back at the beginning. 

I don't know if you never tried to put up a POV camera in a topography 
mesh valley and looked at all the ugly triangles in the foreground. 
Only solution (without patching POVRay) I see is doing some really 
non-trivial calculations on the input topography data extracting a 
mesh with fine grid in foreground and larger grid in the background. 

Wolfgang

Post a reply to this message

In article <3eaafb9d@news.povray.org>,
 Simon Adameit <sim### [at] gaussschule-bsde> wrote:

> There has to be a reason why the reyes algorithm is still used ;-)

Not with raytracing. As far as I know, Reyes is limited to scanline only.

-- 
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

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

> Oh, just up to 2 GB of RAM?
> The issue was to be able to use more than 4 GB...

Since when is a system limited by the amount of physical memory? - It has a
40 GB harddisk in the standard configuration, so you can use 39 GB as swap
space!  Or do you expect they allow you to put 4000 Euros worth of RAM into
a entry level system? ;-)

If you want more RAM and have the necessary pocket money to spend, I would
recommend one of these systems:

<http://www-132.ibm.com/content/home/store_IBMPublicUSA/en_US/eServer/pSerie
s/pSeries.html>
<http://store.sun.com/catalog/doc/BrowsePage.jhtml?cid=48620&parentId=26829>

;-)

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

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

> Either smart "intelligent" mixed-resolution meshes with (at least
> primitive) viewport culling or a very fine mesh is required.
> OR, subdivision at render time.
> Anything else?

Culling is of little use for ray-tracing, it is a typical scanline render
acceleration technique.

However, I recall a paper (in ACM TOG iirc) about an optimized level of
detail algorithm for terrain modeling that was suitable for ray-tracing.
And I am sure somebody has already invented a method for fitting huge meshes
such that they can be used by ray-tracing - RAM to store meshes of whole
planets has _not_ been affordable or available for a long time after all.
And the need to store those meshes has existed for a much longer time!

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

> Culling is of little use for ray-tracing, it is a typical scanline render
> acceleration technique.
> 
I was talking about culling as a technique to keep the mesh include file 
small. Because if you have a 100 million triangle mesh of a planet but 
only see 5% of them, you can try and do viewport culling -- otherwise 
the mesh will not fit into memory. 

>And I am sure somebody has already invented a method for fitting huge
>meshes such that they can be used by ray-tracing 
>
What about 1 byte per triangle? 

It only works for planets with 2 byte height info with the height 
info being the height difference to a sphere surface. 

If I have time, maybe I'll implement that. 

The general problem is that each vertex uses up at least 3*4 bytes. 
The only way I could imagine saving space is a better triangle-to-vertex 
mapping. 

Or, in-memory compression...

Yes, one could do in-memory compression when using a hierarchy. 
It will probably even be faster than using swap memory for the mesh. 

Wolfgang

Post a reply to this message

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

> > Culling is of little use for ray-tracing, it is a typical scanline render
> > acceleration technique.
> > 
> I was talking about culling as a technique to keep the mesh include file 
> small. Because if you have a 100 million triangle mesh of a planet but 
> only see 5% of them, you can try and do viewport culling -- otherwise 
> the mesh will not fit into memory. 

That's still holding 5 million triangles, and breaking things like 
reflections. You don't seem to get it...that is an example of setting up 
the scene wrong. You are using a much higher resolution mesh than you 
need.

-- 
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

Christopher James Huff wrote:

>> I was talking about culling as a technique to keep the mesh include file
>> small. Because if you have a 100 million triangle mesh of a planet but
>> only see 5% of them, you can try and do viewport culling -- otherwise
>> the mesh will not fit into memory.
> 
> That's still holding 5 million triangles, and breaking things like
> reflections. You don't seem to get it...that is an example of setting up
> the scene wrong. You are using a much higher resolution mesh than you
> need.
> 
Okay, then please give me your advice: How should I set up the scene 
correctly? I'll do just that and we'll see if it looks nice. 

I want to animate a space ship which flies to a planet, along a valley 
in the topography and back up into space. 

Wolfgang

Post a reply to this message

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

> Okay, then please give me your advice: How should I set up the scene 
> correctly? I'll do just that and we'll see if it looks nice. 
> 
> I want to animate a space ship which flies to a planet, along a valley 
> in the topography and back up into space. 

A sphere primitive for the planet. As you get closer, a mesh of the area 
visible from the ship...a few hundred thousand triangles, maybe a 
million. Once you get close to the canyon, switch to a high level of 
detail mesh, the detail will probably require a million or so. Then back 
through a medium LOD mesh (maybe the same as the one on incoming, maybe 
different) and then switch to the sphere again. 2 or 3 meshes, none 
having anything near 100 million triangles. You could set things up so 
you have one bigger mesh with variable amounts of detail, highest in the 
canyon...simpler but less efficient, but nowhere near as bad as your 
idea of using a full-resolution mesh of an entire freaking planet. 
*That* is just wasteful on current systems, even if you have the RAM for 
it.

-- 
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

Wolfgang Wieser wrote:
> 
> [...]
> Okay, then please give me your advice: How should I set up the scene
> correctly? I'll do just that and we'll see if it looks nice.
> 
> I want to animate a space ship which flies to a planet, along a valley
> in the topography and back up into space.

I recently showed some samples of high detail rendering of the earth with
variable level of detail.  See:

Subject: rendering the earth (71k+68k)
Date: Tue, 01 Apr 2003 22:57:55 +0200
From: Christoph Hormann <chr### [at] gmxde>
Newsgroups: povray.binaries.images

The data the renders are based on would result in ~3.5 billion triangles
when rendered as a whole with a mesh.  

You can apply the same method (i.e. rendering a planetary body with an
isosurface defined by image maps, using higher resolution data for the
foreground part and blending with the lower resolution basis using
functions) to any other planet.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 28 Feb. 2003 _____./\/^>_*_<^\/\.______

Post a reply to this message

Christopher James Huff wrote:

> none having anything near 100 million triangles. You could set things up so
> you have one bigger mesh with variable amounts of detail, highest in the
> canyon...simpler but less efficient, but nowhere near as bad as your
> idea of using a full-resolution mesh of an entire freaking planet.
> *That* is just wasteful on current systems, even if you have the RAM for
> it.

I'm rendering a scene right now that has over 130 million triangles and
the parse time for just the mesh include files is about 8 minutes on my
1 ghz machine. Add in texture computations, radiosity, area lighting,
the trace function and few other things, the total parse time is around
12 min. I would hate to do that for every frame of an animation...!

-- 
Ken Tyler

Post a reply to this message

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

> What about 1 byte per triangle?
>
> It only works for planets with 2 byte height info with the height
> info being the height difference to a sphere surface.

Why do you use a mesh if you want a height field???  You can already do what
you suggest easily with POV-Ray 3.5 using an isosurface and an image map
pattern!

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Wolfgang Wieser <wwi### [at] gmxde> wrote:
> I was talking about culling as a technique to keep the mesh include file 
> small. Because if you have a 100 million triangle mesh of a planet but 
> only see 5% of them, you can try and do viewport culling -- otherwise 
> the mesh will not fit into memory. 

  There's no way of knowing which parts of the mesh will not be visible
in the final image other than raytracing the image.
  Raytracing is more versatile than scanline-rendering: In scanline rendering
when a triangle is facing away or if it's located outside the viewing port,
you know that it will not be visible. However, raytracing is not that simple.
A triangle can be far behind the camera, yet be visible in the final image.


-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Ken wrote:

> I'm rendering a scene right now that has over 130 million triangles and
> the parse time for just the mesh include files is about 8 minutes on my
> 1 ghz machine. 
>
I cannot imagine that. 
I have to wait >4 minutes to get 1 million triangles parsed 
on a 1.4 GHz box. 

Furthermore, you must have more than 4Gb of virtual memory. 

Wolfgang

Post a reply to this message

> I recently showed some samples of high detail rendering of the earth with
> variable level of detail.  See:
> 
> Subject: rendering the earth (71k+68k)
> Date: Tue, 01 Apr 2003 22:57:55 +0200
> From: Christoph Hormann <chr### [at] gmxde>
> Newsgroups: povray.binaries.images
> 
Looks pretty cool!

Did you "request" the data?
("Files denoted by double asterisks (**) are available upon request. 
Please send an email to...")

> You can apply the same method (i.e. rendering a planetary body with an
> isosurface defined by image maps, 
>
Thanks, the isosurface image map sounds promising. 2 bytes per sample 
is just great. Hope it does not take ages...

> using higher resolution data for the foreground part 
>
okay...

> and blending with the lower resolution basis using
> functions) to any other planet.
> 
"blending using functions"... What do you mean by that?

Wolfgang

Post a reply to this message

Wolfgang Wieser wrote:
> 
> Ken wrote:
> 
> > I'm rendering a scene right now that has over 130 million triangles and
> > the parse time for just the mesh include files is about 8 minutes on my
> > 1 ghz machine.
> >
> I cannot imagine that.
> I have to wait >4 minutes to get 1 million triangles parsed
> on a 1.4 GHz box.

Guess I should have put a decimal place in there :) 1.30 million.
What's really going to blow you away is that I have 2000 copies
of those 1.3 million triangles in my scene. You do the math....
 
> Furthermore, you must have more than 4Gb of virtual memory.

I have 1 gig of physical memory installed and a seperate partition I use
for the swap file that is 1.5 gigs in size. The current scene is using
a bit under 300 megs.

-- 
Ken Tyler

Post a reply to this message

Wolfgang Wieser wrote:
> 
> [...]
> 
> Did you "request" the data?
> ("Files denoted by double asterisks (**) are available upon request.
> Please send an email to...")

No, they are available on the ftp server mentioned on that site:

ftp://gloria2-f.gsfc.nasa.gov/pub/stockli/

> > and blending with the lower resolution basis using
> > functions) to any other planet.
> >
> "blending using functions"... What do you mean by that?
> 

Well, you need a function to select whether the low or the high resolution
map is used at a certain position.  To avoid problems with the root finder
you will need to  create a smooth transit between the regions.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 28 Feb. 2003 _____./\/^>_*_<^\/\.______

Post a reply to this message

> Guess I should have put a decimal place in there :) 1.30 million.
>
Ah, allright. 

> What's really going to blow you away is that I have 2000 copies
> of those 1.3 million triangles in my scene. You do the math....
>  
The meshes internally use refernece counting. 
There is little overhead copying a mesh because they share the data. 

Wolfgang

Post a reply to this message

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

> I cannot imagine that.
> I have to wait >4 minutes to get 1 million triangles parsed
> on a 1.4 GHz box.
>
> Furthermore, you must have more than 4Gb of virtual memory.

No, that just implies there is something wrong with the data you have.
Could you show a few pieces of the data here?

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <3EAC58E7.7AE6A1B5@gmx.de>,
 Christoph Hormann <chr### [at] gmxde> wrote:

> Well, you need a function to select whether the low or the high resolution
> map is used at a certain position.  To avoid problems with the root finder
> you will need to  create a smooth transit between the regions.

One idea I've had for this is some kind of prioritized object list. 
Basically, it would be an ordered list of objects which POV would go 
through until it found an intersection or ran out of objects. In this 
case, higher resolution landscape models would be higher priority, while 
larger area, lower detail models would have lower priority. Close to the 
camera, the high res one would be hit, and the others ignored. Further 
from the camera, the high res one would be missed, but a lower res 
version would be there.
There might be some unexpected shadows at the transition point, but they 
should be minimal.

-- 
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

In article <3EA### [at] pacbellnet>, Ken <tyl### [at] pacbellnet> 
wrote:

> I'm rendering a scene right now that has over 130 million triangles and
> the parse time for just the mesh include files is about 8 minutes on my
> 1 ghz machine. Add in texture computations, radiosity, area lighting,
> the trace function and few other things, the total parse time is around
> 12 min. I would hate to do that for every frame of an animation...!

I wonder how much faster a binary format could load...also, you didn't 
mention what kind of mesh: mesh2, or original mesh? Anyway, it would be 
nice if there was a way to put these objects in persistent variables so 
they wouldn't have to be reloaded or recalculated for every frame.

-- 
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

Christopher James Huff wrote:
> 
> > Well, you need a function to select whether the low or the high resolution
> > map is used at a certain position.  To avoid problems with the root finder
> > you will need to  create a smooth transit between the regions.
> 
> One idea I've had for this is some kind of prioritized object list.
> Basically, it would be an ordered list of objects which POV would go
> through until it found an intersection or ran out of objects. In this
> case, higher resolution landscape models would be higher priority, while
> larger area, lower detail models would have lower priority. Close to the
> camera, the high res one would be hit, and the others ignored. Further
> from the camera, the high res one would be missed, but a lower res
> version would be there.
> There might be some unexpected shadows at the transition point, but they
> should be minimal.

I doubt the speed advantage would be significant.  In the whole low
resolution area you would have to test against both objects.  You could
try to make the container of the high resolution part as small as
possible.  Still it would take additional time.  Any you will have to take
additional care with the shadow rays.  The selection function is rather
fast on the other hand.    

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 28 Feb. 2003 _____./\/^>_*_<^\/\.______

Post a reply to this message

> I wonder how much faster a binary format could load...

	For my patch that renders some specialized mesh data, I did several
comparison tests between povray 3.1g (mesh), megapov (mesh2) and the binary
format I'm using. Each triangle had a 3-colors texture. Here are some benchs
(parse time only) for about 100.000 triangles on an old PIII/500 MHz:

mesh : 6' 57" (using a macro in the input file, lots of seeking)
mesh2: 43"
patch: 6"

	I could not compare for an object of ~800.000 triangles since mesh
and mesh2 were requiring more than 256/512 MB. Rendering times were equivalent.

> Anyway, it would be 
> nice if there was a way to put these objects in persistent variables so 
> they wouldn't have to be reloaded or recalculated for every frame.

	I also did it for meshs only in my patch. Works fine. Saves a huge
amount of time of course...

	For those interested in details:
	http://pov4grasp.free.fr/features/grasp_surface.php

	- NC

Post a reply to this message

In article <3EAEEE06.FB1E5431@gmx.de>,
 Christoph Hormann <chr### [at] gmxde> wrote:

> I doubt the speed advantage would be significant.  In the whole low
> resolution area you would have to test against both objects.  You could
> try to make the container of the high resolution part as small as
> possible.  Still it would take additional time.  Any you will have to take
> additional care with the shadow rays.  The selection function is rather
> fast on the other hand.    

You missed the point...any speed gain is a side effect, the purpose of 
this shape is to make it easier to combine the meshes without having to 
make the edges line up perfectly and cut out part of the low-res mesh 
for the high-res mesh to replace. In this case, the high detail mesh 
would always appear in front of the low detail mesh, even if it is 
actually behind it.

I'm not sure how your selection function works, but it sounds like it is 
used to combine multiple meshes into one variable-detail mesh? That 
would be faster overall, and wouldn't have the seam problems, but is 
rather difficult to implement.

-- 
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

Christopher James Huff wrote:
> 
> [...]
> 
> I'm not sure how your selection function works, but it sounds like it is
> used to combine multiple meshes into one variable-detail mesh? That
> would be faster overall, and wouldn't have the seam problems, but is
> rather difficult to implement.

Now you missed my point :-) I was not talking about meshes at all -
isosurfaces have the strong advantage of much lower memory use (only 16
bit per data point - this is quite unbeatable in comparison to a mesh) and
really renders quite fast in this case.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 28 Feb. 2003 _____./\/^>_*_<^\/\.______

Post a reply to this message

In article <3EAEFE17.CED34C9A@gmx.de>,
 Christoph Hormann <chr### [at] gmxde> wrote:

> Now you missed my point :-) I was not talking about meshes at all -
> isosurfaces have the strong advantage of much lower memory use (only 16
> bit per data point - this is quite unbeatable in comparison to a mesh) and
> really renders quite fast in this case.

How? You can't base an isosurface on a mesh (right now, at least), and 
what do you mean by "data point"? Are you talking about isosurface 
height fields? Height fields have their own disadvantages compared to 
mesh landscapes...no overhangs, etc. And there is a built-in primitive 
which will render much faster. Isosurfaces can avoid the overhang 
problem, but you have to add a procedural component which means the 
height information will only give general shape. The speed gains of a 
mesh or height field could be very significant.

-- 
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

Christopher James Huff wrote:
> 
> > Now you missed my point :-) I was not talking about meshes at all -
> > isosurfaces have the strong advantage of much lower memory use (only 16
> > bit per data point - this is quite unbeatable in comparison to a mesh) and
> > really renders quite fast in this case.
> 
> How? You can't base an isosurface on a mesh (right now, at least), and
> what do you mean by "data point"? Are you talking about isosurface
> height fields? [...]

Take a look at the cited posting in p.b.i.  Image map based isosurfaces
are much more powerful than heightfields.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 28 Feb. 2003 _____./\/^>_*_<^\/\.______

Post a reply to this message

In article <3EAF9B1A.A6D05BB3@gmx.de>,
 Christoph Hormann <chr### [at] gmxde> wrote:

> Take a look at the cited posting in p.b.i.  Image map based isosurfaces
> are much more powerful than heightfields.

I don't do much in p.b.i from here...though this connection is higher 
bandwidth, for some reason it is slower at accessing the newsgroups than 
a dialup connection. I'll check it out though.

-- 
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

In article <3EA### [at] freefr>,
 Nicolas Calimet <pov### [at] freefr> wrote:

> > Anyway, it would be 
> > nice if there was a way to put these objects in persistent variables so 
> > they wouldn't have to be reloaded or recalculated for every frame.
> 
> 	I also did it for meshs only in my patch. Works fine. Saves a huge
> amount of time of course...

Sorry, but that looks like a very bad design. True persistent variables 
would be much cleaner and more useful.

-- 
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

> Sorry, but that looks like a very bad design. True persistent variables 
> would be much cleaner and more useful.

	Do you mean this by looking at the code or just by the fact I did
so on an object basis ? In my patch I only wanted to have something that
works for the particular object I'm using, since in general it did not
work in MegaPOV. In my case it's not meant to be of general use, but of
simple use like a single keyword to add in the object definition.
	My feeling is that essentially only mesh-based objects really
need some persistent feature, since they are usually the largest object
(am I wrong ?) to parse. But I'd be glad if some general solution would
be inplemented in official/unofficial POV. Again the persistent things
in MegaPOV 0.7 were quite buggy, unfortunately.

	And my patch is _definitely_ not of general use, anyway  ;o)

Post a reply to this message

In article <3EB### [at] freefr>,
 Nicolas Calimet <pov### [at] freefr> wrote:

> > Sorry, but that looks like a very bad design. True persistent variables 
> > would be much cleaner and more useful.
> 
> 	Do you mean this by looking at the code or just by the fact I did
> so on an object basis ?

Neither, I am talking about the syntax. Something like:
#persistent Name = Value;
would be better.


> In my patch I only wanted to have something that
> works for the particular object I'm using, since in general it did not
> work in MegaPOV. In my case it's not meant to be of general use, but of
> simple use like a single keyword to add in the object definition.
> 	My feeling is that essentially only mesh-based objects really
> need some persistent feature, since they are usually the largest object
> (am I wrong ?) to parse. But I'd be glad if some general solution would
> be inplemented in official/unofficial POV. Again the persistent things
> in MegaPOV 0.7 were quite buggy, unfortunately.

If it's going to be implemented, it might as well be done right the 
first time. Having it be a feature of one type of object is limiting, 
inconsistent, and annoying. And your assumption that people will only 
want meshes to persist is just wrong...tree generators, particle or 
physics simulations, etc.

-- 
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

> Neither, I am talking about the syntax. Something like:
> #persistent Name = Value;
> would be better.

	Agreed.

> If it's going to be implemented, it might as well be done right the 
> first time.

	Sure, but you probably know quite well that making something
right the very first time, in software development I mean, is either
a piece of luck, or some good time spent to think of it before (and
nobody can think of everything before actually implementing). Maybe
it's even only utopia  :o)

> Having it be a feature of one type of object is limiting, 
> inconsistent, and annoying.

	Yeah. Again I did it for a very specific task. I don't mind
if my patch is not used by anybody but me. I did release it only
because it worked for me, and some (few) found it useful as well.
	In general I perfectly agree with you: to make things as
general as possible, as good as possible. But sometimes it's worth
making some specialized stuff, as a quick working answer to a very
particular situation. I don't intend my little mods to come up into
the official POV anyway...

> And your assumption that people will only 
> want meshes to persist is just wrong...tree generators, particle or 
> physics simulations, etc.

	Okay, I only have a very narrow usage of POV, that's why I
did not think of what you point out -- who said I'm narrow-minded ?  ;-)

	Sounds like those persistent things will require a completely
new POV4 engine ?

	- NC

Post a reply to this message

Thorsten Froehlich wrote:

> In article <3eac5446@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>
> wrote:
> 
>> I cannot imagine that.
>> I have to wait >4 minutes to get 1 million triangles parsed
>> on a 1.4 GHz box.
>>
>> Furthermore, you must have more than 4Gb of virtual memory.
> 
> No, that just implies there is something wrong with the data you have.
> Could you show a few pieces of the data here?
> 
No Problem.

It's a simple mesh (not mesh2 which eliminates the need for hash lookups 
and thus parses faster). 

triangle { <0.0145291,-0.00082502,3.33516>,
<0.0145319,-0.000761583,3.33501>, <0,-0,3.33654> }
triangle { <0.0145319,-0.000761583,3.33501>, <0,-0,3.33654>, <0,-0,3.33663>
}
triangle { <0.0145319,-0.000761583,3.33501>,
<0.0145352,-0.000698175,3.33504>, <0,-0,3.33663> }
triangle { <0.0145352,-0.000698175,3.33504>, <0,-0,3.33663>, <0,-0,3.3369> }
triangle { <0.0145352,-0.000698175,3.33504>,
<0.0145391,-0.000634792,3.33528>, <0,-0,3.3369> }
triangle { <0.0145391,-0.000634792,3.33528>, <0,-0,3.3369>, <0,-0,3.33684> }
triangle { <0.0145391,-0.000634792,3.33528>,
<0.0145406,-0.000571301,3.33501>, <0,-0,3.33684> }
triangle { <0.0145406,-0.000571301,3.33501>, <0,-0,3.33684>, <0,-0,3.33669>
}
triangle { <0.0145406,-0.000571301,3.33501>,
<0.0145429,-0.000507851,3.33501>, <0,-0,3.33669> }
triangle { <0.0145429,-0.000507851,3.33501>, <0,-0,3.33669>, <0,-0,3.33666>
}
triangle { <0.0145429,-0.000507851,3.33501>,
<0.0145449,-0.000444387,3.33498>, <0,-0,3.33666> }
triangle { <0.0145449,-0.000444387,3.33498>, <0,-0,3.33666>, <0,-0,3.33687>
}

Anything wrong with the data? :)

Parse time could be increased by using mesh2 but mem usage?

Wolfgang

Post a reply to this message

Christopher James Huff wrote:

> A sphere primitive for the planet. As you get closer, a mesh of the area
> visible from the ship...
>
The switch between these two may be ugly. Mountains pop up suddenly. 
But using a 200k mesh may be fine. 

> a few hundred thousand triangles, maybe a million. 
>
Yes, one million is enough if you see the whole planet. 
A few hundret thousand is okay for 320x240 only. 

> Once you get close to the canyon, switch to a high level of
> detail mesh, the detail will probably require a million or so. 
>
That was what I actually expected to read... However:

One million for the canyon is far too few. The problem is that 
in mid-ragne and in far background, it is okay but the foreground 
looks real ugly. 
(Solution: mixed-grid mesh per frame, but we're here because we wanted 
to avoid it, right? Other solutions? (beyond isosurface))

Here is the actual problem. 

> You could set things up so
> you have one bigger mesh with variable amounts of detail, highest in the
> canyon...simpler 
>
Well, would be feasible if 1e6 triangles were enough for the canyon. 

> but less efficient, but nowhere near as bad as your
> idea of using a full-resolution mesh of an entire freaking planet.
> That is just wasteful on current systems, even if you have the RAM for
> it.
> 
The only feasible alternative I've seen is Christoph's proposal using an 
isosurface image map. 

Wolfgang

Post a reply to this message