I have created scene with more than 16000 instances of sphere_sweep
(catmul_rom, 9 spheres for each). I have tested this image with cones - it
took no more then 3 minutes to render on PII 233. I have started sphere_sweep
version on P4 1GHz (2 proc). Parsing/bounding/vista/light initialization was
no longer then 5 minutes. No other long tasks on this computer. Sphere sweeps
are evenly distributed over whole image so I suppose each line should take the
same amount of time. But after first day I found at beginig of output stream:

  -:--:-- Rendering line    0 of  600 supersampled 38 times.       
  9:40:17 Rendering line    1 of  600 supersampled 64 times.       
 10:29:44 Rendering line    2 of  600 supersampled 41 times.       
 11:11:45 Rendering line    3 of  600 supersampled 15 times.       
 11:46:41 Rendering line    4 of  600 supersampled 13 times.       
 12:21:07 Rendering line    5 of  600 supersampled 8 times.       
 12:54:12 Rendering line    6 of  600 supersampled 7 times.       
 13:15:59 Rendering line    7 of  600 supersampled 9 times.       
 13:32:42 Rendering line    8 of  600 supersampled 17 times.       
 13:50:26 Rendering line    9 of  600 supersampled 15 times.       
 14:07:57 Rendering line   10 of  600 supersampled 8 times.       
...

Any idea why first line took so much time ? Is there so much to initialize ?
I know it is hard to say without sources but it is possible I use it for
shortest code contest. I wait with publication and want ask first if it is
known problem (of course I know sphere sweeps are slow in nature).

ABX

Post a reply to this message

> (of course I know sphere sweeps are slow in nature).

I wonder why spheresweeps exsist in POV at all.. I may sound negative, but
these shapes can be achieved with cones and render much quicker! I know that
extra memory is required, but then .... wouldn't it be possible to code an
internal "repeating-cones" algoritm in POV ... actually a function that just
repeats any shape, following a user defined path / formula, *without*
storing all points in memory first. This would be useful in many cases.


Hugo

Post a reply to this message

Hugo wrote:
> 
> > (of course I know sphere sweeps are slow in nature).
> 
> I wonder why spheresweeps exsist in POV at all.. I may sound negative, but
> these shapes can be achieved with cones and render much quicker! 

This is not true for any splines other than linear.

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 21 Feb. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

On Sat, 23 Feb 2002 13:26:55 +0100, "Hugo" <hua### [at] post3teledk> wrote:
> > (of course I know sphere sweeps are slow in nature).
>
> I wonder why spheresweeps exsist in POV at all..

For me they are usefull. Idea is good. Perhaps implementation needs
improvements. At this moment they use less memory than cones and are more
accurate in any zoom.

For example my case - I started scene on server of my company - memory is
important issuse. There is more then 16.000 instances. It use (looking at task
manager from NT4) about 80 MB of RAM. Each instance has 9 entries so let's
imagine - I need to replace each sphere_sweep with at least 80 cones - so this
means I need 1.280.000 cones (and the same amount of spheres). I can't use so
much memory on this server (even if it has 1GB of RAM) no talking about my own
machine with 128 MB of RAM. So as I said: idea is good but perhaps some fix in
sources could speed it up - we have to wait for 3.5 sources probably.

> I may sound negative, but
> these shapes can be achieved with cones and render much quicker!

But with sphere_sweep you can still do it. Just don't look at sphere_sweeps
:-)

> wouldn't it be possible to code an
> internal "repeating-cones" algoritm in POV ...

You mean repeating cones with constant radius ? It is basic macro usage.
Or you mean repeating cones along spline with float radius? That is what
linear sphere_sweep does.

ABX

Post a reply to this message

Hugo wrote:

>> (of course I know sphere sweeps are slow in nature).
> 
> I wonder why spheresweeps exsist in POV at all.. I may sound negative, but
> these shapes can be achieved with cones and render much quicker! I know

  Hmmm... try to use several copies of the object, and you will see it is 
not really quicker. Something as smooth as a sphere_sweep will take a lot 
of cones and spheres, wich declared and repeated a lot of times can be a 
real pain. Sphere_sweeps can be repeated with lower cost in rendering 
times, at least from my recent experience with 3.5.

-- 
Jaime Vives Piqueres

La Persistencia de la Ignorancia
http://www.ignorancia.org

Post a reply to this message

In article <3c7788f5@news.povray.org>, "Hugo" <hua### [at] post3teledk> 
wrote:

> > (of course I know sphere sweeps are slow in nature).
> 
> I wonder why spheresweeps exsist in POV at all.. I may sound negative, but
> these shapes can be achieved with cones and render much quicker! I know that
> extra memory is required, but then .... wouldn't it be possible to code an
> internal "repeating-cones" algoritm in POV ... actually a function that just
> repeats any shape, following a user defined path / formula, *without*
> storing all points in memory first. This would be useful in many cases.

As others have mentioned: memory. Take a curved sweep using enough 
spheres and cones to be smooth, and now make a few copies...
I do think other rendering methods would be useful. Some kind of 
adaptive subdivision into cones, tesselation, isosurface-type methods, 
etc...
I think a lot of the problem is just bad bounding though. A sphere sweep 
has a lot of empty space, a box doesn't work that well...some additional 
way of rejecting rays that can't intersect would probably help. Maybe a 
bounding sweep composed of cylinders or cones...

Followups to povray.programming.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

ABX wrote:
>> wouldn't it be possible to code an
>> internal "repeating-cones" algoritm in POV ...
> You mean repeating cones with constant radius ? It is basic macro usage.

Yes it's a simple macro, but I didn't mean this should be done in SDL.. My
idea is that Povray could use a bunch of cylinders - to replace the
sphere_sweeps - but without storing all the objects in memory first, as it
would be necessary via SDL.. Instead the cylinders should render on-the-fly,
following the specified spline_path.. Bounding would be as perfect as with
ordinary cylinders, and memory usage would be low.. It might require a new
way of thinking to make Povray render something without having all objects
declared first ... I don't know with vista buffers etc .. but it might be
possible?  It would also be useful for making grass that renders quick and
doesn't repeat itself.. Multiple copies of an object are rendered on the
fly - following a "function" specified in SDL.


Hugo

Post a reply to this message

In article <3c77bbd9$1@news.povray.org>, "Hugo" <hua### [at] post3teledk> 
wrote:

> It might require a new way of thinking to make Povray render 
> something without having all objects declared first ... I don't know 
> with vista buffers etc .. but it might be possible?

It is much easier than that. POV only cares about the extents of the 
shape (which are already calculated), and where it intersects along a 
ray...how the shape comes up with those values is the shape's business. 
You don't have to create a bunch of cylinder/cone objects, all you have 
to do is change the intersection code. The hard part is coming up with 
an algorithm to determine the intersection...the existing sphere sweep 
code might be the fastest way to do that short of generating a mesh.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message