|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Sorry for not finding in the docs ...
In the example source I can change the marked scale-value without any
effect...
But as the parser accepts it, it can't be completely wrong, can it ?
If it's wrong, is there another way to set the "scale" of the structure in
the function G ?
#declare FP=
function {
pattern {
gradient 1
}
}
#declare G=
function {
pattern {
crackle solid
scale 0.1 // <---- No effect !
}
}
#declare MyPFkt=
function {
FP(x+G(x,y,z)*1,y+G(x,y,z)*1,z+G(x,y,z)*1)
}
plane { -z,-30
finish {
ambient 1
}
pigment {
function {
MyPFkt(x,y,z)
}
color_map {
[0,rgb z]
[1,rgb x+y]
}
}
}
--
Jan Walzer <jan### [at] lzernet>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 7 Sep 2001 15:39:21 +0200, Jan Walzer wrote:
>Sorry for not finding in the docs ...
>In the example source I can change the marked scale-value without any
>effect...
>But as the parser accepts it, it can't be completely wrong, can it ?
I think this is a known bug.
>If it's wrong, is there another way to set the "scale" of the structure in
>the function G ?
#declare G1=function {pattern{crackle solid}}
#declare G=function{G1(x*10,y*10,z*10)}
--
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbf 1}hollow interior{media{emission 3-T}}}#end
Z(-x-x.2x)camera{location z*-10rotate x*90normal{bumps.02scale.05}}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Ron Parker" <ron### [at] povrayorg> wrote
> >In the example source I can change the marked scale-value without any
> >effect...
> >But as the parser accepts it, it can't be completely wrong, can it ?
>
> I think this is a known bug.
>
> >If it's wrong, is there another way to set the "scale" of the structure in
> >the function G ?
>
> #declare G1=function {pattern{crackle solid}}
> #declare G=function{G1(x*10,y*10,z*10)}
>
wouldn't it be simpler to implement the scale-keyword in the right way ?
--
Jan Walzer <jan### [at] lzernet>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 7 Sep 2001 16:12:05 +0200, Jan Walzer wrote:
>"Ron Parker" <ron### [at] povrayorg> wrote
>> >In the example source I can change the marked scale-value without any
>> >effect...
>> >But as the parser accepts it, it can't be completely wrong, can it ?
>>
>> I think this is a known bug.
>>
>> >If it's wrong, is there another way to set the "scale" of the structure in
>> >the function G ?
>>
>> #declare G1=function {pattern{crackle solid}}
>> #declare G=function{G1(x*10,y*10,z*10)}
>>
>
>wouldn't it be simpler to implement the scale-keyword in the right way ?
Of course. It will be fixed. I thought you were asking for a workaround.
--
#local R=rgb 99;#local P=R-R;#local F=pigment{gradient x}box{0,1pigment{gradient
y pigment_map{[.5F pigment_map{[.3R][.3F color_map{[.15red 99][.15P]}rotate z*45
translate x]}]#local H=pigment{gradient y color_map{[.5P][.5R]}scale 1/3}[.5F
pigment_map{[.3R][.3H][.7H][.7R]}]}}}camera{location.5-3*z}//only my opinions
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jan Walzer <jan### [at] lzernet> wrote:
: wouldn't it be simpler to implement the scale-keyword in the right way ?
He said it's a known bug. This means the behaviour is not by design.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I wasn't sure which behaviour was meant ...
The behaviour of the parser, that (in this case) wrong code is accepted, or
the behaviour that the accepted, right code has no effect ...
of course ... it's clear now ...
--
Jan Walzer <jan### [at] lzernet>
"Warp" <war### [at] tagpovrayorg> schrieb im Newsbeitrag
news:3b98dc7b@news.povray.org...
> Jan Walzer <jan### [at] lzernet> wrote:
> : wouldn't it be simpler to implement the scale-keyword in the right way ?
>
> He said it's a known bug. This means the behaviour is not by design.
>
> --
> #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 wrote:
> Jan Walzer <jan### [at] lzernet> wrote:
> : wouldn't it be simpler to implement the scale-keyword in the right way ?
>
> He said it's a known bug. This means the behaviour is not by design.
Perhaps he's been burned by too much dealing with Adobe. Where "a known bug"
translates to "sure, it's broken, whacha going ta do, sue us?"
--
Wind the Frog!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jon A. Cruz <jon### [at] geocitiescom> wrote:
: Perhaps he's been burned by too much dealing with Adobe. Where "a known bug"
: translates to "sure, it's broken, whacha going ta do, sue us?"
I think that the process is longer:
The first response is: "The problem is not in our software but in yours/you".
When that doesn't work: "Ok, it's broken, live with that."
Then, as time passes: "New version of our magnificent program with huge
improvements, only at $10000000!".
--
#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
|
|
| |
| |
|
|
|
|
| |
|
|