> 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