|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gerhard Oosthuizen schrieb:
> It would be nice to have a fractal object for trees and lightning.
> Tree-like 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 POV-Ray 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.
>> Tree-like 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 L-Systems? The POV-Ray 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 POV-Tree 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.
>>> Tree-like 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 L-Systems? The POV-Ray SDL is quite well suited to
> writing them (in a slightly different manner from what's posted above,
> of course :) ).
The SDL is indeed well-suited to this task - but the POV-Ray 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.
>> Tree-like 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 POV-Ray 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 sub-objects 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.
>>> Tree-like 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 POV-Ray 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.
Woo-hoo! =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 non-recursive method that I don't know about)
> Going into each level, the camera would have to be transformed so that
> the sub-objects 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.
> Tree-like 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 POV-Ray 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*(1-lm_pop),
lm_val,
select(lm_i > lm_istart & ( (abs(lm_pop-lm_val) <
abs(lm_nearestpop-lm_val)) ),0,
lm_nearestpop,
lm_pop),
lm_i+1, lm_istart, lm_iend ),
abs(lm_val-lm_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.5-1., -4.0>
direction 1.5*z
right x*image_width/image_height
look_at <0.0, 0.0-1, 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
user-defined 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
> user-defined 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
|
|
| |
| |
|
|
|
|
| |
|
|