 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Over the weekend, I was trying to implement a CSG method for generating random
planets.
The basic algorithm is simple: Take a sphere, cut it in half along a random
plane, scale each half independently by some small amount, iterate.
#macro Planet(baseRad)
#local Base = sphere { 0.0, baseRad }
#local Plt = Base
#local A = 0;
#while(A < 16)
#local rT = <Rand_Gauss(0.0, 0.33, RdmA), Rand_Gauss(0.0, 0.33, RdmB),
Rand_Gauss(0.0, 0.33, RdmC)>*360;
#declare Plt =
union {
intersection {
object { Plt }
plane { y, 0 rotate rT }
scale (1 + Rand_Gauss(0.0, 0.33, RdmA)*0.15)
}
intersection {
object { Plt }
plane { -y, 0 rotate rT }
scale (1 + Rand_Gauss(0.0, 0.33, RdmB)*0.15)
}
bounded_by { box { -baseRad*0.625, baseRad*0.625 }}
}
#local A = A + 1;
#end
Plt
#end
now, from what I've read, it takes more than a thousand iterations to get good
results, but trying to do just fifty iterations makes POV do an imitation of
PAC-Man with my memory and swap space. All 16GB of it.
I don't know if this is a bug or a natural limitation of the geometry parsing
engine.
Since doing it with CSG proved unreasonable, I thought I'd try functions
instead.
This is as far as I got:
#declare baseFn = function(x,y,z,r) { sqrt(x*x + y*y + z*z) - r }
#declare boxFN = function { y * sqrt(x*x + z*z) }
#declare half = function { max(baseFn(x,y,z,3),boxFN(x, y, z)) }
isosurface {
function { min( half(x,y,z), half(x, -y, z)*Rand_Gauss(0.0,0.33,RdmB)) }
threshold 0
max_gradient 5
contained_by{ box {-5, 5} }
pigment { White }
}
the problem is imposing a rotation on the FUNCTION, rather than the isosurface
as a whole. I know how to impose a rotation around a given axis, but going from
there to rotating about all axes is somewhat more problematic without a matrix
transformation (which would be decidedly more elegant, but harder to compute on
the fly)
The rotation transform would be done on the boxFN(...) function in the half
object, and each iteration would redefine baseFn(...)
scaling each half would then be no trouble with variable substitution.
The only way I've come up with to solve the rotation problem is a separate
transformation (using a separate angle variable) for each axis. It would be
messy, but it could work.
My final option for using this algorithm is some kind of pigment, constructed in
much the same fashion, but I'm not sure which patterns I'd use, or if I'd have
to construct functions for the patterns I'd need.
If anyone has suggestions, I'd welcome them.
Regards,
A.D.B.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> now, from what I've read, it takes more than a thousand iterations to get good
> results, but trying to do just fifty iterations makes POV do an imitation of
> PAC-Man with my memory and swap space. All 16GB of it.
>
> I don't know if this is a bug or a natural limitation of the geometry parsing
> engine.
It looks to me like at each iteration you are doubling the number of
objects POV has in memory (by creating an intersection of two versions
of the previous object). That means after 50 iterations you will have
about 2^50 objects - I'm surprised you got that far!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott <sco### [at] scott com> wrote:
> > now, from what I've read, it takes more than a thousand iterations to get good
> > results, but trying to do just fifty iterations makes POV do an imitation of
> > PAC-Man with my memory and swap space. All 16GB of it.
> >
> > I don't know if this is a bug or a natural limitation of the geometry parsing
> > engine.
>
> It looks to me like at each iteration you are doubling the number of
> objects POV has in memory (by creating an intersection of two versions
> of the previous object). That means after 50 iterations you will have
> about 2^50 objects - I'm surprised you got that far!
That's about what I figured was happening. And I didn't get that far because
I had to shut it down.
Regards,
A.D.B.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Anthony D. Baye" <Sha### [at] spamnomorehotmailcom> wrote:
> Over the weekend, I was trying to implement a CSG method for generating random
> planets.
......
> The rotation transform would be done on the boxFN(...) function in the half
> object, and each iteration would redefine baseFn(...)
>
> scaling each half would then be no trouble with variable substitution.
>
> The only way I've come up with to solve the rotation problem is a separate
> transformation (using a separate angle variable) for each axis. It would be
> messy, but it could work.
It would help, of course, if POV allowed redefinition of functions...
This is where I am now:
#declare baseFn = function(x,y,z,r) { sqrt(x*x + y*y + z*z) - r }
#declare boxFN = function { y * sqrt(x*x + z*z) }
#declare half = function(x,y,z,P,T) { max(baseFn(x,y,z,3),
boxFN(
(x*cos(radians(-T))-z*sin(radians(-T)))*cos(radians(-P))+y*sin(radians(-P)),
-(x*cos(radians(-T))-z*sin(radians(-T)))*sin(radians(-P))+y*cos(radians(-P)),
x*sin(radians(-T)) + z*cos(radians(-T))
)) }
#for(I,0,1000,1)
#local PHI = Rand_Normal(0.0, 0.33, RdmA)*360;
#local THETA = Rand_Normal(0.0, 0.33, RdmB)*360;
#local s1 = 1 + Rand_Normal(0.0, 0.33, RdmB)*0.025;
#local s2 = 1 - Rand_Normal(0.0, 0.33, RdmB)*0.025;
#local newFn = function {
min(half(x/s1,-y/s1,z/s1,-PHI,THETA),half(x/s2,y/s2,z/s2,PHI,THETA)) }
#undef baseFn
#declare baseFn = newFn;
#undef newFn
#end
isosurface {
function { baseFn(x,y,z) }
threshold 0
max_gradient 5
contained_by{ box {-5, 5} }
pigment { White }
}
but it seems that functions are not evaluated as I thought they were. All it
renders is some permutation of the first iteration. (A sphere, split in half,
both halves scaled independently.)
I was really hoping this would work. Again, if anyone has suggestions, I'd
welcome them.
Regards,
A.D.B.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> It would help, of course, if POV allowed redefinition of functions...
> but it seems that functions are not evaluated as I thought they were. All it
> renders is some permutation of the first iteration. (A sphere, split in half,
> both halves scaled independently.)
>
> I was really hoping this would work. Again, if anyone has suggestions, I'd
> welcome them.
Looks like you've run into the oft-encountered function/macro parse/render
dichotomy.
As I understand it, and folks can correct me if I'm wrong or mis-state this,
functions are evaluated ONCE - at parse time. So if you want something that
gets updated during RENDERING, then you need to call the function with a MACRO.
So do something like:
#macro Do_something (x, y)
[whiles, ifs, elses, ends, equations]
#end
Do_something (x, y)
(Think about macros like defining any CSG object, and then INVOKING it with
object {Object_name} )
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 14.08.2013 02:46, schrieb Bald Eagle:
> Looks like you've run into the oft-encountered function/macro parse/render
> dichotomy.
>
> As I understand it, and folks can correct me if I'm wrong or mis-state this,
> functions are evaluated ONCE - at parse time. So if you want something that
> gets updated during RENDERING, then you need to call the function with a MACRO.
Um... no, not at all.
- Macros are /always/ evaluated during parsing.
- Functions may be evaluated either during parsing or during rendering,
depending on the context in which they are used.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> Am 14.08.2013 02:46, schrieb Bald Eagle:
>
> > Looks like you've run into the oft-encountered function/macro parse/render
> > dichotomy.
> >
> > As I understand it, and folks can correct me if I'm wrong or mis-state this,
> > functions are evaluated ONCE - at parse time. So if you want something that
> > gets updated during RENDERING, then you need to call the function with a MACRO.
>
> Um... no, not at all.
>
> - Macros are /always/ evaluated during parsing.
>
> - Functions may be evaluated either during parsing or during rendering,
> depending on the context in which they are used.
So... Just not going to work?
The idea was to build up a progressively more complex function for the surface
of the planet. While I could do this using built-in patterns, that wasn't the
point of the exercise.
I finally found the site where I first read about this:
http://freespace.virgin.net/hugo.elias/models/m_landsp.htm
The great thing about it is: the more iterations you do, the better it gets.
Regards,
A.D.B.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 14/08/2013 07:07, Anthony D. Baye a écrit :
> clipka <ano### [at] anonymousorg> wrote:
>> Am 14.08.2013 02:46, schrieb Bald Eagle:
>>
>>> Looks like you've run into the oft-encountered function/macro parse/render
>>> dichotomy.
>>>
>>> As I understand it, and folks can correct me if I'm wrong or mis-state this,
>>> functions are evaluated ONCE - at parse time. So if you want something that
>>> gets updated during RENDERING, then you need to call the function with a MACRO.
>>
>> Um... no, not at all.
>>
>> - Macros are /always/ evaluated during parsing.
>>
>> - Functions may be evaluated either during parsing or during rendering,
>> depending on the context in which they are used.
>
> So... Just not going to work?
>
> The idea was to build up a progressively more complex function for the surface
> of the planet. While I could do this using built-in patterns, that wasn't the
> point of the exercise.
>
> I finally found the site where I first read about this:
> http://freespace.virgin.net/hugo.elias/models/m_landsp.htm
>
> The great thing about it is: the more iterations you do, the better it gets.
The trick is in iterations: for once, you do not want to keep the real
sphere object, but start with a mesh of a sphere and move/scale parts of
it. As you are not to break any triangle, simply moving the vertex
should be enough.
I hope I will remember that thread & link long enough to expand my mesh
manipulation extension.
(now, I have to find an anisotropic random generator of 3D unit vectors...)
--
Just because nobody complains does not mean all parachutes are perfect.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Anthony D. Baye" wrote in message
news:web.5209e02df7af87b1328783aa0@news.povray.org...
> Over the weekend, I was trying to implement a CSG method for generating
> random
> planets.
> The basic algorithm is simple: Take a sphere, cut it in half along a
> random
> plane, scale each half independently by some small amount, iterate.
That's the concept, not the algorithm. The algorithm is:
* Start with a mesh sphere
Select a random plane, scale vertices above and below the plane
independently by some small amount, iterate.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Anthony D. Baye" wrote in message
news:web.520ab4ece896405b328783aa0@news.povray.org...
> The rotation transform would be done on the boxFN(...) function in the
> half
> object, and each iteration would redefine baseFn(...)
>
That's ugly. Couldn't you just do this with a gradient function and rotate
each instance?
You don't need the tricky macro/function stuff either, just make a loop and
write out 10,000 functions to an include file.
#local f_00000 = function { ...
#local f_00001 = function { f_00000(x, y, z) + ...
That might be a little inelegant for you, but it's what I'd try.
-Shay
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
