 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
My latest rendering...
I don't know why, but this image took 30 hours to render??
30 hours on a AMD 2100+ XP...but radiosity settings need to be tweaked
probably.
Post a reply to this message
Attachments:
Download 'Ball-of-rings.jpg' (214 KB)
Preview of image 'Ball-of-rings.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Pyr### [at] shaw ca news:3fc875ac@news.povray.org
> I don't know why, but this image took 30 hours to render??
This is probably problem with bounding boxes, I quess that vista buffer
and/or BB don't work very vell with differences (I quess You used
differences of cones to create rings?)
Probably if You used mesh, or divide each ring into small sectors (each
having own BB) that might help... BUT it's only imho.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ah, your probably right!
The rings are made by the difference of 2 spheres and 2 cones (then union
two torus), so the bb must be of the sphere right now...no wonder!
Thanks, I'll try to see if that helps.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> This is probably problem with bounding boxes,
> I quess that vista buffer and/or BB don't work very vell
> with differences (I quess You used differences of cones to
> create rings?)
Apropos bounding boxes, does any of you have an idea why my recent rendering
with a few hundred thousand blob components (maybe 300.000) has now taken 70
hours to render in 800x600 and STILL need a few days?? I am completely
stunned! I've split the blob into a grid of 8*8 blocks so that not all
300.000 components needs to be considered for every pixel... But... It's
still so slow?
Maybe I should mention that I'm using focal_blur with 40 samples (not a lot,
but enough) and I'm using pre-calculated radiosity settings.
Regards,
Hugo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hugo Asm wrote:
>
> Apropos bounding boxes, does any of you have an idea why my recent rendering
> with a few hundred thousand blob components (maybe 300.000) has now taken 70
> hours to render in 800x600 and STILL need a few days?? I am completely
> stunned! I've split the blob into a grid of 8*8 blocks so that not all
> 300.000 components needs to be considered for every pixel... But... It's
> still so slow?
Splitting the blob components into several objects will usually not
speed up the render but slow it down. If all components would have to
be considered for every pixel you probably would not even have finished
the first line yet.
> Maybe I should mention that I'm using focal_blur with 40 samples (not a lot,
> but enough) and I'm using pre-calculated radiosity settings.
Then i would not complain.
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 25 Oct. 2003 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
