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