





 
 




 
 


Gerhard Oosthuizen schrieb:
> It would be nice to have a fractal object for trees and lightning.
> Treelike fractal textures would also be nice for veins and leaves.
I guess you're talking about fractals of the recursive kind, as in:
#declare MyTree {
cylinder { <0,0,0>, <0,1,0> }
object { MyTree scale 0.5 rotate z*30 translate y*1 }
object { MyTree scale 0.7 rotate z*20 translate y*1 }
}
(which of course doesn't work in POVRay 3.6 or 3.7)
Unfortunately, such recursive definitions are perfectly unsuited for
raytracing, and would have to be "resolved" prior to rendering anyway
(same goes for textures). I think the best way to go about this is to
make the macro mechanism (or whatever exactly might come to replace it)
more elegant and better suited to define "custom primitives", and leave
definition of such trees to libraries.
Post a reply to this message


 
 




 
 


clipka wrote:
> Gerhard Oosthuizen schrieb:
>> It would be nice to have a fractal object for trees and lightning.
>> Treelike fractal textures would also be nice for veins and leaves.
>
> I guess you're talking about fractals of the recursive kind, as in:
>
> #declare MyTree {
> cylinder { <0,0,0>, <0,1,0> }
> object { MyTree scale 0.5 rotate z*30 translate y*1 }
> object { MyTree scale 0.7 rotate z*20 translate y*1 }
> }
Aren't these termed LSystems? The POVRay SDL is quite well suited to
writing them (in a slightly different manner from what's posted above,
of course :) ).
Additionally, there's always the POVTree utility :) I don't think
anyone's done lightning yet... hmm, I smell a weekend project coming on...
...Chambers
Post a reply to this message


 
 




 
 


Chambers schrieb:
> clipka wrote:
>> Gerhard Oosthuizen schrieb:
>>> It would be nice to have a fractal object for trees and lightning.
>>> Treelike fractal textures would also be nice for veins and leaves.
>>
>> I guess you're talking about fractals of the recursive kind, as in:
>>
>> #declare MyTree {
>> cylinder { <0,0,0>, <0,1,0> }
>> object { MyTree scale 0.5 rotate z*30 translate y*1 }
>> object { MyTree scale 0.7 rotate z*20 translate y*1 }
>> }
>
> Aren't these termed LSystems? The POVRay SDL is quite well suited to
> writing them (in a slightly different manner from what's posted above,
> of course :) ).
The SDL is indeed wellsuited to this task  but the POVRay rendering
engine isn't; the SDL needs to take care of generating all those "limbs"
and leaves.
Post a reply to this message


 
 




 
 


clipka wrote:
> Gerhard Oosthuizen schrieb:
>> It would be nice to have a fractal object for trees and lightning.
>> Treelike fractal textures would also be nice for veins and leaves.
>
> I guess you're talking about fractals of the recursive kind, as in:
>
> #declare MyTree {
> cylinder { <0,0,0>, <0,1,0> }
> object { MyTree scale 0.5 rotate z*30 translate y*1 }
> object { MyTree scale 0.7 rotate z*20 translate y*1 }
> }
>
> (which of course doesn't work in POVRay 3.6 or 3.7)
>
> Unfortunately, such recursive definitions are perfectly unsuited for
> raytracing, and would have to be "resolved" prior to rendering anyway
> (same goes for textures).
Not necessarily, if the bounding scheme is right.
In the case above, tracing tests for the bound around the whole fractal
object; if the ray intersects the bound, then test for the cylinder and
each of the child objects. Ray tracing recurses well (or else
reflection and refraction would not be something that ray tracing excels
at).
Going into each level, the camera would have to be transformed so that
the subobjects are scaled, rotated, and transformed correctly.
Additional parameters would be helpful here:
* A bound for the whole fractal, allowing the renderer to move on to
other objects in the scene as soon as possible;
* A recursion_level setting, declaring a maximum depth for recursion;
* A minimum_size setting, telling the renderer the smallest amount of
scaling allowed for any further recursion;
* a leaf_object { }, which allows the user to specify an object that is
used in place of recursion when either the recursion_level or the
minimum_size is reached.
The only real problem I can see with such an object is that while it's
probably very good for making trees and plants of a certain quality,
most of its uses are fairly abstract. Most of the things that we want
to model aren't fractal in overall shape.
So barring a compelling reason, other than trees, to have fractals in
the renderer, it seems that the usefulness of the feature does not
justify the effort needed to implement it.
Regards,
John
Post a reply to this message


 
 




 
 


On Sun, 22 Nov 2009 22:32:02 +0200, John VanSickle
<evi### [at] hotmailcom> wrote:
> clipka wrote:
>> Gerhard Oosthuizen schrieb:
>>> It would be nice to have a fractal object for trees and lightning.
>>> Treelike fractal textures would also be nice for veins and leaves.
>> I guess you're talking about fractals of the recursive kind, as in:
>> #declare MyTree {
>> cylinder { <0,0,0>, <0,1,0> }
>> object { MyTree scale 0.5 rotate z*30 translate y*1 }
>> object { MyTree scale 0.7 rotate z*20 translate y*1 }
>> }
>> (which of course doesn't work in POVRay 3.6 or 3.7)
>> Unfortunately, such recursive definitions are perfectly unsuited for
>> raytracing, and would have to be "resolved" prior to rendering anyway
>> (same goes for textures).
>
> Not necessarily, if the bounding scheme is right.
Woohoo! =D
>
> In the case above, tracing tests for the bound around the whole fractal
> object; if the ray intersects the bound, then test for the cylinder and
> each of the child objects. Ray tracing recurses well (or else
> reflection and refraction would not be something that ray tracing excels
> at).
>
I thought most fractals are recursive. I'm sure Mandelbrot is recursive
(though there might be a nonrecursive method that I don't know about)
> Going into each level, the camera would have to be transformed so that
> the subobjects are scaled, rotated, and transformed correctly.
>
> Additional parameters would be helpful here:
>
> * A bound for the whole fractal, allowing the renderer to move on to
> other objects in the scene as soon as possible;
> * A recursion_level setting, declaring a maximum depth for recursion;
> * A minimum_size setting, telling the renderer the smallest amount of
> scaling allowed for any further recursion;
> * a leaf_object { }, which allows the user to specify an object that is
> used in place of recursion when either the recursion_level or the
> minimum_size is reached.
>
I like your ideas.
> The only real problem I can see with such an object is that while it's
> probably very good for making trees and plants of a certain quality,
> most of its uses are fairly abstract. Most of the things that we want
> to model aren't fractal in overall shape.
>
> So barring a compelling reason, other than trees, to have fractals in
> the renderer, it seems that the usefulness of the feature does not
> justify the effort needed to implement it.
>
I wouldn't say that's not enough reason not to implement it. Pov artist
have found weird and wonderful uses of some seemingly useless features :)

Nekar Xenos
"The spoon is not real"
Post a reply to this message


 
 




 
 


"Gerhard Oosthuizen" wrote:
> It would be nice to have a fractal object for trees and lightning.
> Treelike fractal textures would also be nice for veins and leaves.
If you don't mind breaking the rule against recursive functions, it isn't too
difficult to make a fractal pattern. The following scene uses a function
derived from the bifurcation diagram of the logistic map[1] as a pattern.
Although this example only shows it used as a planar pattern, it could also be
mapped to three dimensions in various other ways. With a little turbulence it
might make a decent lightning. With some more tweaking, you could likely get a
tree or at least a scrubby bush out of it.
Since I read the POVRay docs about how turbulence works[2], I have thought it
should be possible to make a fractal_warp that could be applied to existing
patterns...
Cheers!
[1] http://en.wikipedia.org/wiki/File:LogisticMap_BifurcationDiagram.png
[2] http://www.povray.org/documentation/view/3.6.1/407/#s02_05_12_06_04
// 
// Persistence of Vision Ray Tracer Scene Description File
// File: logistic_map_pattern.pov
// Vers: 3.6, 3.7
// Desc: Logistic Map Pattern Example
// Date: 12/03/09
// Auth: David Wagner
// Cite: http://en.wikipedia.org/wiki/Logistic_map
//
// Render at 16:9 with +A0.5 +AM2 +R2 J
#include "colors.inc"
// 
// Returns the distance to the nearest logistic value after lm_imin iterations.
#declare lm_i_distance_min = function( lm_r, lm_pop, lm_val, lm_nearestpop,
lm_i, lm_istart, lm_iend ) {
select(lm_i > lm_iend, 0,
lm_i_distance_min(
lm_r,
lm_r*lm_pop*(1lm_pop),
lm_val,
select(lm_i > lm_istart & ( (abs(lm_poplm_val) <
abs(lm_nearestpoplm_val)) ),0,
lm_nearestpop,
lm_pop),
lm_i+1, lm_istart, lm_iend ),
abs(lm_vallm_nearestpop) )//end select
};
// Calls the recursive iterating function.
#declare lm_fn_distance_min = function( lm_r, lm_val, lm_istart, lm_iend ) {
lm_i_distance_min(lm_r,0.5, lm_val, 1, 0, lm_istart, lm_iend)
};
// 
plane {
y, 1
texture{
pigment { function { lm_fn_distance_min(abs(mod(z,4)), abs(mod(x,1)), 20,
100)}
poly_wave 0.25
color_map{[0 Yellow][0.2 1.2*Goldenrod][0.2 White][0.5 Black][1 Blue]}
translate z*1.04
}//end pigment
}//end texture
}
sphere {
0.0, 1
texture {
pigment {
function { lm_fn_distance_min(mod(abs(z),4), abs(mod(x,1)), 20, 100)}
poly_wave 0.25
color_map {
[0.00 color rgb <1.0,0.4,0.2> ]
[0.33 color rgb <0.2,0.4,1.0> ]
[0.66 color rgb <0.4,1.0,0.2> ]
[1.00 color rgb <1.0,0.4,0.2> ]
}
}//end pigment
normal{function{lm_fn_distance_min(mod(abs(z),4), abs(mod(x,1)), 20, 100) }
poly_wave 2
}
finish{
specular 0.3//0.6
}
translate z*3
}//end texture
}
// 
camera {
location <0.0, 0.51., 4.0>
direction 1.5*z
right x*image_width/image_height
look_at <0.0, 0.01, 0.0>
}
sky_sphere {
pigment {
gradient y
color_map {
[0.0 rgb <0.6,0.7,1.0>]
[0.7 rgb <0.0,0.1,0.8>]
}
}
}
light_source {
<0, 0, 0> // light's position (translated below)
color rgb <1, 1, 1> // light's color
translate <30, 30, 30>
}
// 
Post a reply to this message
Attachments:
Download 'logistic_map_pattern.png' (215 KB)
Preview of image 'logistic_map_pattern.png'


 
 




 
 


Nice one Waggy, and fast too :)
Post a reply to this message


 
 




 
 


waggy <hon### [at] handbasketorg> wrote:
> If you don't mind breaking the rule against recursive functions, it isn't too
> difficult to make a fractal pattern.
It's perfectly possible to eg. replicate the 'mandel' pattern with a
userdefined function. I have done that in the past.

 Warp
Post a reply to this message


 
 




 
 


Great stuff!
Thanks

Nekar Xenos
"The spoon is not real"
Post a reply to this message


 
 




 
 


Warp wrote:
> It's perfectly possible to eg. replicate the 'mandel' pattern with a
> userdefined function. I have done that in the past.
Indeed, it is that code you posted somewhere around here I used as a model, and
I thank you for it.
Post a reply to this message


 
 




 

