Thanks,

> Splitting the blob components into several objects will usually not
> speed up the render but slow it down.

The blobs are meant to simulate snow. They are traced randomly to cover an
object. I thought that maybe automatic bounding wasn't very efficient when
so many blob components have random positions. This is only speculation -
but I thought, splitting them into a grid of 8*8 sections that does not
overlap each other, could help to eleminate tests for blobs that are far
away. Even if this doesn't speed up rendering, would it slow things down?

Regards,
Hugo

Post a reply to this message

hua### [at] post3teledk news:3fca23f7@news.povray.org

> hours to render in 800x600 and STILL need a few days??  I am completely
> 

Hmm this is quite long,

1) hierarchy is ofcourse *on* as default ?

2) bouning boxes do work? maybe set bounding_threshold to 1 to enforce 
using them


Btw, I do have few ideas about speeding up renderings of most POV 
objects... I hope I'll have time to implement them and they will prove 
usefull :)

One of simplest of thoes ideas - triangulize Your object (trace lots of 
points, then connect them into smooth mesh). It would be nice if POV could
a) done this automaticly
b) ...with calculating normals
c) ...with handling non-continous objects (with holes in them, or with 
totaly not-connected to each other parts)



-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M

Post a reply to this message

> 1) hierarchy is ofcourse *on* as default ?

I've checked: yes.

> 2) bouning boxes do work? maybe set
> bounding_threshold to 1 to enforce using them

I needed the docs to explain this keyword but yes, my scene contains 87
frame-level objects so bounding_threshold is on. There are no particular
.ini settings used and also, the sturmian rootsolver is not used.

You have good ideas.

Regards,
Hugo

Post a reply to this message

"Rafal 'Raf256' Maj" <spa### [at] raf256com> wrote in message
news:Xns### [at] 204213191226...
| hua### [at] post3teledk news:3fca23f7@news.povray.org
|
| One of simplest of thoes ideas - triangulize Your object (trace lots
of
| points, then connect them into smooth mesh). It would be nice if POV
| could
| a) done this automaticly
| b) ...with calculating normals
| c) ...with handling non-continous objects (with holes in them, or with
| totaly not-connected to each other parts)
|

It would be pretty useless. It is better for you as a user to build
meshing macros based on your specific need than to use a generalized
algorithm. The only situations where a generalized algorithm produces
anything at all reasonable are situations where Pov-Ray primitives,
heightfields, and isosurfaces perform well already.

You or I could write a meshing algorithm specifically for snow, but I
can guarantee that some generalized algorithm like marching cubes would
produce so many triangles that no one would have the RAM to render the
scene.

 -Shay

Post a reply to this message

> You or I could write a meshing algorithm specifically for snow

Would probably be a good idea ... maybe even an isosurface would be quicker.
My rendering is *still* running and it's been another 2 days since my last
post. I can see that it's still going to take many hours to complete!
Although I think my image looks nice, it's not worth burning off *that* many
cpu-cycles.

I think, there are some plugins in some commercial modellers that can add
snow or dirt to a mesh.. If anyone knows more about this, I would be
interested since I couldn't find enough information on google.

Regards,
Hugo

Post a reply to this message

"Hugo Asm" <hua### [at] post3teledk> wrote in message
news:3fcbb4b6$1@news.povray.org...
| > You or I could write a meshing algorithm specifically for snow
|
| Would probably be a good idea ...

I really don't have the time, but I am tempted to give it a shot. Out of
curiosity, what algorithm did you use to determine the location and size
of your snow blobs? I've never seen snow.

On the original topic of this thread. That is a quite nice ball of
rings, but it would have been pretty simple and faster rendering as a
mesh also.

 -Shay

Post a reply to this message

> what algorithm did you use to determine the location and size
> of your snow blobs? I've never seen snow.

You've never seen snow? I probably shouldn't take this literally.

Well, I used Gilles Tran's "makesnow.inc" at first, then modified it to
speed up parsing but the idea is still a very simple approximation:

I declare a direction vector that simulates wind and gravity, such as
 <-1, -1, 0>  which would tend to cover the top and right side of an object
(assuming y is height). The size of each particle is random but has a
minimum & maximum limit. I use the "trace" feature to shoot rays at an
object, which in my case is an imported mesh2... Gilles' macro can be found
here: http://www.oyonale.com/ressources/downloads/makesnow.inc

I know you're skilled when it comes to handling triangles - so good luck -
the project is interesting - but feel free to stop when you want to.

Best wishes,
Hugo

PS: we should probably continue the thread somewhere else.

Post a reply to this message

Hugo Asm wrote:
>>what algorithm did you use to determine the location and size
>>of your snow blobs? I've never seen snow.
> 
> 
> You've never seen snow? I probably shouldn't take this literally.
> 

Saw the first snow for the year this morning.  They were filming 
something or other on the corner and had snowmaking equipment out to put 
snow in the scene.

Post a reply to this message

hua### [at] post3teledk news:3fcbb4b6$1@news.povray.org

> Would probably be a good idea ... maybe even an isosurface would be
> quicker. 

No, mesh is quicker. I.e. inside my wax figures are over 200.000 particles. 

-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M

Post a reply to this message

"Hugo Asm" <hua### [at] post3teledk> wrote in message
news:3fcbc6d3$1@news.povray.org...
|
| You've never seen snow? I probably shouldn't take
| this literally.

I meant it literally. It has snowed a handful of times here, but it
melts as soon as it touches the ground.

|
| the project is interesting

I put something together last night. I guess it looked like a blob mesh
would on a little isosurface mauntain range I made. That is, it looked
like white, puffy grass. The parse was about half an hour, but the
render time is measured in minutes, not days. I took a look at Gilles
website and saw that he had noticed the same problem, that the algorithm
only produces good results in small patches on tree limbs and such. I
built the mesh so that it can be further refined (within the limits of
fp precision) so the with enough memory, an acceptable snow might be
made on a jagged enough mountain. I would guess that mountains don't get
snow-covered in one pass anyway, so it might be that this algorithm
would never produce realistic results on a large object.

|
| PS: we should probably continue the thread somewhere else.

I set followups to p.gen if you have any further comment.

 -Shay

Post a reply to this message