 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Lars R." <rou### [at] gmx de> wrote:
> I forgot to mention how I got attention to these types of fractals:
>
> https://youtu.be/c-K4Lk98m38 "Fractal 3D - Mandelbrot Quaternion"
>
> *.*
>
> But with 10h render time per frame it is hopeless to do any animations
> with it. :'-(
>
> L.
Oh wow, on both counts! I always thought of Julia Fractal as driftwood or dead
tree stumps, and I sure didn't think Mandelbrot could be anything except 2D
slices.
Guess I don't get out much... or is that in?
Bob
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I'd probably make sure you're optimizing your speed as described in the docs on
isosurfaces (max gradient)
I'd keep the accuracy low for tests to boost the speed.
You may also consider buying something with 12 or more cores so that you can do
multithread renders and really cut down the render time.
You might even consider distributing renders on servers or something.
and also consider using:
http://www.econym.demon.co.uk/isotut/approx.htm
For best performance you should specify a value close to the real maximum
gradient.
evaluate POV-Ray can also dynamically adapt the used max_gradient. To activate
this technique you have to specify the evaluate keyword followed by three
parameters:
P0: the minimum max_gradient in the estimation process,
P1: an over-estimating factor. This means that the max_gradient is multiplied
by the P1 parameter.
P2: an attenuation parameter (1 or less)
In this case POV-Ray starts with the max_gradient value P0 and dynamically
changes it during the render using P1 and P2. In the evaluation process, the P1
and P2 parameters are used in quadratic functions. This means that
over-estimation increases more rapidly with higher values and attenuation more
rapidly with lower values. Also with dynamic max_gradient, there can be
artefacts and holes.
If you are unsure what values to use, start a render without evaluate to get a
value for max_gradient. Now you can use it with evaluate like this:
P0 : found max_gradient * min_factor
'min_factor' being a float between 0 and 1 to reduce the max_gradient to a
'minimum max_gradient'. The ideal value for P0 would be the average of the found
max_gradients, but we do not have access to that information.
A good starting point is 0.6 for the min_factor
P1 : sqrt(found max_gradient/(found max_gradient * min_factor))
'min_factor' being the same as used in P0 this will give an over-estimation
factor of more than 1, based on your minimum max_gradient and the found
max_gradient.
P2 : 1 or less
0.7 is a good starting point.
When there are artifacts / holes in the isosurface, increase the min_factor and
/ or P2 a bit. Example: when the first run gives a found max_gradient of 356,
start with
#declare Min_factor= 0.6;
isosurface {
...
evaluate 356*Min_factor, sqrt(356/(356*Min_factor)), 0.7
//evaluate 213.6, 1.29, 0.7
...
}
This method is only an approximation of what happens internally, but it gives
faster rendering speeds with the majority of isosurfaces.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 27.07.2017 um 13:59 schrieb Bald Eagle:
> I'd probably make sure you're optimizing your speed as described in the docs on
> isosurfaces (max gradient)
Captain Obvious? Is it you?
Beleave me, the max_gradient is >9000, and povray complains when I set a
lower value. That's why I switched to the "evaluate" method, as
described on the Povray website that you copied unecessarily.
The render time differences are neglible.
> I'd keep the accuracy low for tests to boost the speed.
Unfortunately neither you nor the Povray website gave me usable hints
which values might be sensible or how the "accuracy" value influences
the visual output of the rendering at all. :-(
> You may also consider buying something with 12 or more cores so that you can do
> multithread renders and really cut down the render time.
If you give me the money we can talk about that, sure.
> You might even consider distributing renders on servers or something.
Do you have a ready-to-use software for that? (for Linux & Mac)
L.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
On 28/07/2017 08:58, Lars R. wrote:
> Am 27.07.2017 um 13:59 schrieb Bald Eagle:
>> You might even consider distributing renders on servers or something.
>
> Do you have a ready-to-use software for that? (for Linux & Mac)
have a look at http://www.southampton.ac.uk/~sjc/raspberrypi/ as an
example. I'm pretty sure that you can use machines other than
Raspberries to work as nodes. from there it'd be just a couple of shell
scripts to orchestrate the distributed render.
hth, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Lars R." <rou### [at] gmxde> wrote:
> Captain Obvious? Is it you?
You have --- unmasked me. :O
Now that my true identity is known, I will probably have to resort to getting a
job on Hotels.Com or something...
> Unfortunately neither you nor the Povray website gave me usable hints
> which values might be sensible or how the "accuracy" value influences
> the visual output of the rendering at all. :-(
I've played with it a little in the past, and it seems mostly to affect the
smoothness of the surface. I'm not sure what the actual mechanism is, but I
find it a useful fiction to envision it as a sort of subdivision of the curve -
large values are rough/blocky, and small values are very smooth.
> If you give me the money we can talk about that, sure.
I only suggest it since I see what gets offered for sale on Ebay, etc. and got
my friend just such a machine for a few hundred dollars. Might not be a
worthwhile investment for static renders, but for a challenging animation, I
figured it was worth suggesting for serious consideration.
After seeing the speed increase on his machine, I myself may go that route in
the near future.
> > You might even consider distributing renders on servers or something.
>
> Do you have a ready-to-use software for that? (for Linux & Mac)
I had the impression that it wasn't that hard to do, and that as far back as a
decade or more ago, people were doing that with POV-Ray. I just thought I'd
bring it up as a possibility, figured someone else might be able to give you
details for the implementation, and that it might be a viable solution whether I
personally know the details of how to actually do it or not.
Obviously Dick Balaska has been doing it, I have seen people offer services to
upload a .pov file to the web and have it be rendered and the graphic file be
sent back, and I figured that with all of this cloud computing, maybe there was
some analogous mechanism by which "The Cloud" could do the heavy lifting.
Sorry I didn't have a magic bullet for you.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Lars R." <rou### [at] gmxde> wrote:
> But with 10h render time per frame it is hopeless to do any animations
> with it. :'-(
I thought about this some more, and I wonder if you generate a mesh of the
fractal, if you can speed up the animation by using the saved mesh.
If you subtract away the half facing away from the camera, it ought to look the
same, and potentially speed up the render time as well.
You can use a difference, a contained_by box for your isosurface, or back-face
culling of the mesh.
Graphics Gems has some tips and tricks for speeding up code with pre-defined
values and look-up tables for things like sqrt() and trig functions.
I think if you take a look at
https://nylander.wordpress.com/2008/08/25/cross-section-of-the-quintic-calabi-yau-manifold/
http://bugman123.com/Physics/Calabi-Yau.zip
you'll see that he generates his surface by a parametric set of equations,
populates an array of vertices and normals, and then generates a "mesh" of
smooth_triangles.
I did some similar work with my parametric animations.
You might be able to turn those arrays into proper mesh{} objects and save them
to a file.
I'd say the only other option would be to use a 3rd party tool to generate the
fractal mesh quickly (non-SDL), and then use POV-ray to render it.
Maybe that's a bit more helpful.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
https://en.wikipedia.org/wiki/Mandelbulb
has some links that list software to generate 3D fractals like the Mandelbulb,
etc.
Perhaps you would find those useful.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/1/2017 6:02 PM, Bald Eagle wrote:
>
> https://en.wikipedia.org/wiki/Mandelbulb
>
> has some links that list software to generate 3D fractals like the Mandelbulb,
> etc.
> Perhaps you would find those useful.
>
I did, thanks.
I downloaded Mandelbulb 3D today but still need to find how to texture
the mesh.
http://mandelbulb.com/2014/mandelbulb-3d-mb3d-fractal-rendering-software/
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Stephen <mca### [at] aolcom> wrote:
> I did, thanks.
> I downloaded Mandelbulb 3D today but still need to find how to texture
> the mesh.
Do you mean color-code the different areas of the mesh?
You'll probably need to define a pigment function that mirrors the shape.
So, for instance, Paul Nylander colors his Calabi-Yau "mesh" using:
pigment {
function {atan2(y-x,sqrt(2)*z)/(2*pi)}
color_map{
[0 rgbt <1,0,0,0.5>]
[1/6 rgbt <1,1,0,0.5>]
[1/3 rgbt <0,1,0,0.5>]
[1/2 rgbt <0,1,1,0.5>]
[2/3 rgbt <0,0,1,0.5>]
[5/6 rgbt <1,0,1,0.5>]
[1 rgbt <1,0,0,0.5>]}}
finish {reflection 0.4}
}
That produces the HSV-style hue gradient going around the 5-fold symmetry.
Perhaps you can search around for color functions that people have used and come
up with something along those lines.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/1/2017 8:04 PM, Bald Eagle wrote:
> Stephen <mca### [at] aolcom> wrote:
>
>> I did, thanks.
>> I downloaded Mandelbulb 3D today but still need to find how to texture
>> the mesh.
>
> Do you mean color-code the different areas of the mesh?
>
> You'll probably need to define a pigment function that mirrors the shape.
>
Yes, I guessed as much.
> So, for instance, Paul Nylander colors his Calabi-Yau "mesh" using:
>
> pigment {
> function {atan2(y-x,sqrt(2)*z)/(2*pi)}
>
> color_map{
> [0 rgbt <1,0,0,0.5>]
> [1/6 rgbt <1,1,0,0.5>]
> [1/3 rgbt <0,1,0,0.5>]
> [1/2 rgbt <0,1,1,0.5>]
> [2/3 rgbt <0,0,1,0.5>]
> [5/6 rgbt <1,0,1,0.5>]
> [1 rgbt <1,0,0,0.5>]}}
>
> finish {reflection 0.4}
> }
>
> That produces the HSV-style hue gradient going around the 5-fold symmetry.
>
Thanks I'll try that.
> Perhaps you can search around for color functions that people have used and come
> up with something along those lines.
>
I intend to but I've just found the s/ware and there is so much to do
and only one life to do it in.
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
