 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Anthony D. Baye" <Sha### [at] spamnomore hotmailcom> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> - Macros are /always/ evaluated during parsing.
I guess I didn't say or mean to imply that they weren't.
> - Functions may be evaluated either during parsing or during rendering,
> depending on the context in which they are used.
And those contexts are?
Function outside of a macro only at parse time, function inside a macro during
parse and render?
Eventually I WILL flowchart this out and do something to explain this with SDL
and graphics, for both my own edification as well as for the benefit of others.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Anthony D. Baye" <Sha### [at] spamnomorehotmailcom> wrote:
> scott <sco### [at] scottcom> 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.
And no matter what you do, you won't be able to get that many with POV on any
system available on this planet today. Even with references, and no
transformations, it would take 8 petabytes (8192 terabytes) just to store the
references. Realistically you might get 2^30 spheres on a PC, but not with a
regular Windows (you need the a server variant, desktop variants only support 64
GB of RAM) as you will probably need 256 to 512 GB of RAM for it. Or you need a
lot of fast swap space.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Thorsten Froehlich" <nomail@nomail> wrote in message
news:web.520bbf49e896405b45eb5620@news.povray.org...
> "Anthony D. Baye" <Sha### [at] spamnomorehotmailcom> wrote:
>> scott <sco### [at] scottcom> 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.
>
> And no matter what you do, you won't be able to get that many with POV on
> any
> system available on this planet today. Even with references, and no
> transformations, it would take 8 petabytes (8192 terabytes) just to store
> the
> references. Realistically you might get 2^30 spheres on a PC, but not with
> a
> regular Windows (you need the a server variant, desktop variants only
> support 64
> GB of RAM) as you will probably need 256 to 512 GB of RAM for it. Or you
> need a
> lot of fast swap space.
and the website link shows a 10,000-iteration version.
-Shay
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
