 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I'm not sure if this is known yet, but I'm working with a scene and I set
max trace level to 512 in global_settings, evertime I run the scene it
crashes, occasionally It gives me an error message other times it just
exits. I tried it with both compiles of beta 7, same thing. I'll post the
scene files in p.b-t.b
thanks
--
Kevin
http://www.geocities.com/qsquared_1999/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3bed84a1$1@news.povray.org> , "Kevin Loney" <klo### [at] pt2m com>
wrote:
> I'm not sure if this is known yet, but I'm working with a scene and I set
> max trace level to 512 in global_settings, evertime I run the scene it
> crashes, occasionally It gives me an error message other times it just
> exits. I tried it with both compiles of beta 7, same thing. I'll post the
> scene files in p.b-t.b
Use a lower max_trace_level. If the crash goes away, no need to post a
scene.
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
>
> In article <3bed84a1$1@news.povray.org> , "Kevin Loney" <klo### [at] pt2mcom>
> wrote:
>
> > I'm not sure if this is known yet, but I'm working with a scene and I set
> > max trace level to 512 in global_settings, evertime I run the scene it
> > crashes, occasionally It gives me an error message other times it just
> > exits. I tried it with both compiles of beta 7, same thing. I'll post the
> > scene files in p.b-t.b
>
> Use a lower max_trace_level. If the crash goes away, no need to post a
> scene.
Would the crash be related to the use of high max_trace_levels and the
"stack overflow error" mentioned in the docs under max_trace_level ?
--
Ken Tyler
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3BEDA69A.448E8BED@pacbell.net> , Ken <tyl### [at] pacbellnet>
wrote:
> Would the crash be related to the use of high max_trace_levels and the
> "stack overflow error" mentioned in the docs under max_trace_level ?
Yes.
The solution is to change the POV-Ray source code to limit max_trace_level.
I know some other people will start a flame war now that it is so necessary
to have an unlimited max_trace_level, but that doesn't change the fact that
it has to be limited. Crashing is obviously not an option and a limit is
the way to fix it.
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
>
> In article <3BEDA69A.448E8BED@pacbell.net> , Ken <tyl### [at] pacbellnet>
> wrote:
>
> > Would the crash be related to the use of high max_trace_levels and the
> > "stack overflow error" mentioned in the docs under max_trace_level ?
>
> Yes.
>
> The solution is to change the POV-Ray source code to limit max_trace_level.
> I know some other people will start a flame war now that it is so necessary
> to have an unlimited max_trace_level, but that doesn't change the fact that
> it has to be limited. Crashing is obviously not an option and a limit is
> the way to fix it.
Since it is already a documented limitation I see no reason for a flame war
to erupt. People will just have to learn to live with it.
--
Ken Tyler
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trfde> wrote:
: The solution is to change the POV-Ray source code to limit max_trace_level.
Why limit the max_trace_level because of *ONE* platform? Why all other
platforms have to suffer because it crashes in one?
In Unix I can use virtually any max_trace_level and it will not crash.
If I need to use a max_trace_level of 10000, I can use it; it will work just
perfectly. This is because unix programs do not have a limited stack.
I don't understand why is it so difficult to just tell the compiler to
make a bigger stack.
When I was making my triangle mesh smoother program, I had a stack problem
as well. As I had a recursive call, it crashed when the recursion was too
deep. I learned that the compiler generated by default a 8 kilobytes stack
to the program, which is laughably small. What I did was just to tell the
compiler to generate a 1 megabyte stack instead (of course in DOS; as said
earlier, this is not a problem in Unix).
: Crashing is obviously not an option and a limit is the way to fix it.
A rather harsh way of "fixing" a bug.
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3bee3aac@news.povray.org> , Warp <war### [at] tagpovrayorg> wrote:
> Why limit the max_trace_level because of *ONE* platform? Why all other
> platforms have to suffer because it crashes in one?
It crashes all platforms for which the beta is available. Those platforms
together represent more than 99% of all installed systems, thus it will be a
problem for 99% of all potential users and right now a problem for 100% of
users (because no other versions are available).
Thorsten
____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg
I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3bee3aac@news.povray.org> , Warp <war### [at] tagpovrayorg> wrote:
> In Unix I can use virtually any max_trace_level and it will not crash.
Well, I hope you can at least assign a stack limit (or general memory) limit
to processes in any system that supports unlimited stack sizes. If not, you
would have a problem, and thus all Unix versions I know support such a
limit.
Ask yourself the question what happens if this space has been consumed by
the stack? You get a signal, one that will force you to terminate POV-Ray
(because it cannot cope with the problem in another way).
Now, I see little difference between a forced termination and a crash from
the _user_ perspective. So, in conclusion for the user it does absolutely
not matter why POV-Ray quits while rendering - the image cannot be
completed. What reasonable argument is there to tell the user before and
prevent the problem in advance? The proper way to do this is to set a limit
in advance so the user can be told _in_advance_, without rendering possibly
for days just to find that it will break somewhere after wasting so much
time*.
As for a new design (read: POV-Ray 4.0), one solution could be to use a
stack data structure, not the program stack.
Thorsten
* Yes, you could argue POV-Ray could run out of memory while rendering, but
as you might know, by far most memory is consumed during parsing and some is
freed after parsing is done. Thus such a case will be very, very rare!
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trfde> wrote:
: Well, I hope you can at least assign a stack limit (or general memory) limit
: to processes in any system that supports unlimited stack sizes. If not, you
: would have a problem, and thus all Unix versions I know support such a
: limit.
: Ask yourself the question what happens if this space has been consumed by
: the stack? You get a signal, one that will force you to terminate POV-Ray
: (because it cannot cope with the problem in another way).
Of course there's a limit: Physical memory.
However, I think that the trace level has to go to millions before you are
getting even close to filling the stack with a regular-sized scene.
Of course the scene itself could eat up most of the memory thus leaving
less space for the stack, but in this case a povray's internal limit will
not help. The memory could be so filled that even a recursion level of 10
could fill the stack. Of course this is an extremely rare case, but
theoretically possible. What I'm trying to say here is that imposing an
artificial limit to the recursion level does not help at all in unix. If the
memory fills up, it can run out of stack space, regardless of any internal
limit.
As for the Windows version: I still don't understand why a bigger stack
could not be linked to the program. Most compilers have an option to specify
the stack size the program will use; this stack size is usually very small
(eg. 8 or 16 kilobytes); just increase it and there you are: You can have
tens of thousands of recursions in winpov.
If you are going to limit the max recursion limit, then at least put
somewhere an easily modifiable flag that can be switched to get rid of
this limitation. This way people compiling the unix version can get an
unlimited version.
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trfde> wrote:
: It crashes all platforms for which the beta is available.
It doesn't crash in this Solaris machine. :)
Why is it so difficult to just increase that stack size?
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3bee5f5b@news.povray.org> , Warp <war### [at] tagpovrayorg> wrote:
> Why is it so difficult to just increase that stack size?
Because it cannot be increased to not crash with a max_trace_level set to
2^31?
> As for the Windows version: I still don't understand why a bigger stack
> could not be linked to the program. Most compilers have an option to specify
> the stack size the program will use; this stack size is usually very small
> (eg. 8 or 16 kilobytes); just increase it and there you are: You can have
> tens of thousands of recursions in winpov.
The stack size is already at 1024 KB on Windows, and 600 KB on Macs! Did
you really think POV-Ray would ever run if there was such a low limit as 16
KB?
So how much more should it be to please you? Ten MB, 100 MB or one GB?
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trfde> wrote:
: So how much more should it be to please you? Ten MB, 100 MB or one GB?
I'm just not happy with an artificial limit which has been imposed due
to one braindead OS which doesn't even have a dynamic stack for programs.
I can use almost any max_trace_level in unix, but that will no longer be
true just because another OS can't grasp that.
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message news:3bee5f11@news.povray.org...
> Thorsten Froehlich <tho### [at] trfde> wrote:
> As for the Windows version: I still don't understand why a bigger stack
> could not be linked to the program. Most compilers have an option to specify
> the stack size the program will use; this stack size is usually very small
> (eg. 8 or 16 kilobytes); just increase it and there you are: You can have
> tens of thousands of recursions in winpov.
I agree with Warp here. I understand that the stack has been set to 1 MB. I've
done that with just about every non-trivial Windows program I've written. But
considering what POV-Ray is doing, and if my understanding is correct in that
lots of things get put on the stack, I don't think 4 or even 8 MB would be
unreasonable. IIRC, in some (most?) compilers you can even set the stack size
at runtime, but that would be a feature request, so consider it just a comment.
Of course, once source is out, we can change it ourselves :-)
> If you are going to limit the max recursion limit, then at least put
> somewhere an easily modifiable flag that can be switched to get rid of
> this limitation. This way people compiling the unix version can get an
> unlimited version.
>
I completely agree with that. Also, what limit to use? Wouldn't some scenes be
able to survive a higher limit than others?
I would say put an extra note about it in the FAQ and leave the rest alone.
Yes, I know people ask stupid questions (I'm guilty on occasion). but putting
info in two places about it might help head off some of those questions. I was
actually a little surprised that there is not a section on possible errors, that
is a list of errors with likely causes. I realize many of the errors are
self-explanatory, but many only make sense if you know what's going on
internally. Such a list would have helped me several times so far.
By the way, on the topic of stupid questions and why they're asked, I'd like to
explain why I sometimes ask them. In the case of max_trace_level, I've used it
many times before 3.5. I've read the manual about before. But it was a long
time ago, and I didn't figure max_trace_level (which really has only one
purpose) would have changed. I didn't realize too high a value could cause a
crash. Until I did it the other day. And now I see it's in the manual.
Just my 5 cents (I went over the 2 cent limit, I think)
Michael
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Redbeard wrote:
> By the way, on the topic of stupid questions and why they're asked, I'd like to
> explain why I sometimes ask them. In the case of max_trace_level, I've used it
> many times before 3.5. I've read the manual about before. But it was a long
> time ago, and I didn't figure max_trace_level (which really has only one
> purpose) would have changed. I didn't realize too high a value could cause a
> crash. Until I did it the other day. And now I see it's in the manual.
The following quote comes straight from the POV-Ray v2.2 docs so it is
obvious that this limitation has been known for many years now -
"Note: Raising max_trace_level will use more memory and time and it could
cause the program to crash with a stack overflow error. Values for
max_trace_level are not restricted, so it can be set to any number as long
as you have the time and memory."
--
Ken Tyler
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message news:3beea0b0@news.povray.org...
> I'm just not happy with an artificial limit which has been imposed due
> to one braindead OS which doesn't even have a dynamic stack for programs.
Frankly, I think you should get your facts right before mouthing off about
supposedly 'braindead' operating systems.
Win32 behaves exactly as it should - it dynamically grows the stack as it's
needed. The default stack size (as given in the EXE) is merely the maximum
stack size, not the initial size.
Put another way, POVWIN has a maximum stack size of 1mb per thread, currently,
as I have to date seen no compelling reason to change this.
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sun, 11 Nov 2001 00:05:49 +0100, "Thorsten Froehlich"
<tho### [at] trfde> wrote:
>The solution is to change the POV-Ray source code to limit max_trace_level.
>I know some other people will start a flame war now that it is so necessary
>to have an unlimited max_trace_level, but that doesn't change the fact that
>it has to be limited. Crashing is obviously not an option and a limit is
>the way to fix it.
How about issuing a stack overflow exception or something along the
same line and catching it? This way the program will exit with a
reasonable error message and possibly warn the user about the problem
(or point to the relevant section of the docs :) )
Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG e-mail : pet### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Cason <newsadmin-despam-@povray-no-spam.org> wrote:
: Win32 behaves exactly as it should - it dynamically grows the stack as it's
: needed.
: The default stack size (as given in the EXE) is merely the maximum
: stack size, not the initial size.
Ok, then it's better than I thought.
I had the impression that programs allocate a stack for themselves with just
a regular memory allocation call. Thus the stack will always take the same
amount of memory and its size would be fixed. This would mean that one has to
always find a compromise between stack size and memory usage (ie. it's a waste
of space to reserve a 100MB stack if you are just going to use 1KB of it).
However, if it's just a maximum size, not a fixed size to be allocated, as
you say, then I don't see any problem in increasing it considerably. If more
memory is not consumed even if a 100MB maximum stack size is specified, then
I don't see any problem in doing this.
: Put another way, POVWIN has a maximum stack size of 1mb per thread, currently,
: as I have to date seen no compelling reason to change this.
Increasing the possible max_trace_level is a very good reason in my opinion.
People wouldn't have found this limitation (what is it? something like 300?)
if they never would need it.
Increasing the maximum stack size to 100 times the current should be enough
for everyone. (Yes, pun intended.)
A max_trace_level limit of about 30000 is very acceptable in my opinion.
Just add to the documentation a visible note that using a bigger
max_trace_level can use lots of memory.
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12 Nov 2001 06:56:23 -0500, Warp wrote:
> Chris Cason <newsadmin-despam-@povray-no-spam.org> wrote:
>: Win32 behaves exactly as it should - it dynamically grows the stack as it's
>: needed.
>: The default stack size (as given in the EXE) is merely the maximum
>: stack size, not the initial size.
>
> Ok, then it's better than I thought.
> I had the impression that programs allocate a stack for themselves with just
> a regular memory allocation call. Thus the stack will always take the same
> amount of memory and its size would be fixed. This would mean that one has to
> always find a compromise between stack size and memory usage (ie. it's a waste
> of space to reserve a 100MB stack if you are just going to use 1KB of it).
Nope, a Win32 stack has a "reserve" size and a "commit" size. The loader
allocates address space for the "reserve" size, but it only actually maps
memory for the "commit" size. It then marks the page just below the
commit as Not Present and waits for it to fault. When it faults, the OS
maps another page into the address space. (Theoretically, it's possible
to blow up an app by decrementing the stack pointer by more than a page.)
This is the reason for the maximum size: it's not a matter of allocated
memory, but of allocated address space. The stack has to be contiguous.
--
#local R=<7084844682857967,0787982,826975826580>;#macro L(P)concat(#while(P)chr(
mod(P,100)),#local P=P/100;#end"")#end background{rgb 1}text{ttf L(R.x)L(R.y)0,0
translate<-.8,0,-1>}text{ttf L(R.x)L(R.z)0,0translate<-1.6,-.75,-1>}sphere{z/9e3
4/26/2001finish{reflection 1}}//ron.parker@povray.org My opinions, nobody else's
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> A max_trace_level limit of about 30000 is very acceptable in my opinion.
> Just add to the documentation a visible note that using a bigger
> max_trace_level can use lots of memory.
Out of curiosity, what would you do, render-wise, with a limit of
30 000 ??? (or, if you want, even 300).
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <slr### [at] fwicom> , Ron Parker
<ron### [at] povrayorg> wrote:
> Nope, a Win32 stack has a "reserve" size and a "commit" size. The loader
> allocates address space for the "reserve" size, but it only actually maps
> memory for the "commit" size. It then marks the page just below the
> commit as Not Present and waits for it to fault. When it faults, the OS
> maps another page into the address space
But it cannot shrink the stack this way. So once you have a stack that is
i.e. 100 MB you have to restart the application. I think the same problem
exists under Unix. Unless, of course, you have a system function to shrink
the stack "manually".
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 12 Nov 2001 20:48:44 +0100, Thorsten Froehlich wrote:
> In article <slr### [at] fwicom> , Ron Parker
><ron### [at] povrayorg> wrote:
>
>> Nope, a Win32 stack has a "reserve" size and a "commit" size. The loader
>> allocates address space for the "reserve" size, but it only actually maps
>> memory for the "commit" size. It then marks the page just below the
>> commit as Not Present and waits for it to fault. When it faults, the OS
>> maps another page into the address space
>
> But it cannot shrink the stack this way. So once you have a stack that is
> i.e. 100 MB you have to restart the application. I think the same problem
> exists under Unix. Unless, of course, you have a system function to shrink
> the stack "manually".
Threads.
Each thread has its own stack allocation. Kill the render thread and
restart it, and the stack allocation starts over at the "commit" size again.
--
#macro R(L P)sphere{L __}cylinder{L P __}#end#macro P(_1)union{R(z+_ z)R(-z _-z)
R(_-z*3_+z)torus{1__ clipped_by{plane{_ 0}}}translate z+_1}#end#macro S(_)9-(_1-
_)*(_1-_)#end#macro Z(_1 _ __)union{P(_)P(-_)R(y-z-1_)translate.1*_1-y*8pigment{
rgb<S(7)S(5)S(3)>}}#if(_1)Z(_1-__,_,__)#end#end Z(10x*-2,.2)camera{rotate x*90}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Ken" <tyl### [at] pacbellnet> wrote in message
news:3BEF1927.DABD73B5@pacbell.net...
>
>
>
> The following quote comes straight from the POV-Ray v2.2 docs so it is
> obvious that this limitation has been known for many years now -
>
> "Note: Raising max_trace_level will use more memory and time and it could
> cause the program to crash with a stack overflow error. Values for
> max_trace_level are not restricted, so it can be set to any number as long
> as you have the time and memory."
>
I'm not denying it hasn't been there for a long time... it's just that this is
the first time I've run into it being a problem. Like I said, I probably read
it a long time ago.
Michael
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fabien Mosen <fab### [at] skynetbe> wrote:
: Out of curiosity, what would you do, render-wise, with a limit of
: 30 000 ??? (or, if you want, even 300).
Perhaps not 30000, but 300 and more could be necessary to render lots of
semi-transparent objects (eg. lens flares, "sprites" which form things like
flames, clouds, etc).
If people would never need a max_trace_level higher than about 300, then
they wouldn't have found this limit.
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> a écrit dans le message news:
> Perhaps not 30000, but 300 and more could be necessary to render lots of
> semi-transparent objects (eg. lens flares, "sprites" which form things
like
> flames, clouds, etc).
Please write a (reasonable) POV-Ray scene where you can see the difference
between 50 and 80 levels.
(reasonable means : not a serie of 100 transparent planes)
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
fabien <fab### [at] skynetbe> wrote:
: Please write a (reasonable) POV-Ray scene where you can see the difference
: between 50 and 80 levels.
There is a visible difference between 50, 100 and 500 recursions in this
scene. Of course I could have came up with a scene where the difference is
more _important_, but I didn't have time for anything fancier.
global_settings { max_trace_level 500 }
camera { location <-1,2.5,-10> look_at y angle 35 }
light_source { <1000,2000,-1500>, 1 }
plane { y,0 pigment { rgb <1,.8,.4> } }
#declare GrassPatch =
box
{ <-50,0,0><50,2,.1>
pigment
{ spherical color_map
{ [0 rgbt <0,0,0,1>][.1 rgb y]
}
scale <.02, 1.95, .02>
translate x*.1
warp { repeat x*.2 }
warp { turbulence x*.1 }
}
}
#declare S = seed(0);
#declare Ind = 0;
#while(Ind < 1000)
object { GrassPatch translate <-2+4*rand(S),0,-5+Ind> }
#declare Ind = Ind + 1;
#end
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
