> : it's more fun,
>   Not in the long run.
>   If you find yourself using a special feature over and over again, you
> probably will make your own include file in order to avoid writing the same
> thing many times. This is not much different from just using a standard include
> file.
but you have written it yourself in that case.  That's what matters to me.  And if you
write things yourself, you have absolute comprehension of the code (probably anyway),
and
that helps when using it.

> : and the results are more your own.
>   Well, in an extreme case you shouldn't use povray at all then, but write
> your own raytracer. Then the results will really be your own.
I know :)
But that's a little too extreme, even for me :)

>   Why is it ok to use 'rotate' or 'scale', but it's not ok to use
> 'Reorient_Trans' just because it's in an include file instead of being an
> internal keyword? I don't understand.
it is ok, like I said.  I was more talking about textures and things like that.  Those
are
things I rather make myself.

>   If 'Reorient_Trans' was in internal feature instead of being a macro, would
> it then be ok to use it? Why? What's the difference?
there is no difference.  In the contrary: it's better when things are macros, so I
don't
have to download the source to see how it works.

cu!
--
camera{location-z*3}#macro G(b,e)b+(e-b)*(C/50)#end#macro L(b,e,k,l)#local C=0
;#while(C<50)sphere{G(b,e),.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1
;#end#end L(y-x,y,x,x+y)L(y,-x-y,x+y,y)L(-x-y,-y,y,y+z)L(-y,y,y+z,x+y)L(0,x+y,
<.5,1,.5>,x)L(0,x-y,<.5,1,.5>,x)               // ZK http://www.povplace.be.tf

Post a reply to this message

> >   Why is it ok to use 'rotate' or 'scale', but it's not ok to use
> > 'Reorient_Trans' just because it's in an include file instead of being an
> > internal keyword? I don't understand.
> it is ok, like I said.  I was more talking about textures and things like that. 
Those are
> things I rather make myself.

I think I begin to see one of his (many) points; I hardly ever use
colors.inc anymore

That boy has more points than a line!

-- 
signature{
  "Grey Knight" contact{ email "gre### [at] yahoocom" }
  site_of_week{ url "http://digilander.iol.it/jrgpov" }
}

Post a reply to this message

I've never been good at expressing myself.

But whatever I say: if you can interprete it in 2 or more ways, I always meant to say
the
least offending of them.
Fact is that I love POV-Ray, and I have the deepest respect for the POV-Ray team,
although
I don't understand some of the things they do (actually only POV3.5)

cu!
--
camera{location-z*3}#macro G(b,e)b+(e-b)*(C/50)#end#macro L(b,e,k,l)#local C=0
;#while(C<50)sphere{G(b,e),.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1
;#end#end L(y-x,y,x,x+y)L(y,-x-y,x+y,y)L(-x-y,-y,y,y+z)L(-y,y,y+z,x+y)L(0,x+y,
<.5,1,.5>,x)L(0,x-y,<.5,1,.5>,x)               // ZK http://www.povplace.be.tf

Post a reply to this message

Grey Knight <s16### [at] namtarqubacuk> wrote:
: I think I begin to see one of his (many) points; I hardly ever use
: colors.inc anymore

  This is exactly what I meant with "there wasn't anything interesting in
the standard include files".
  Prior to 3.5, the standard include files were not very useful. They contained
things that weren't really worth the trouble of writing the #include line.

  However, 3.5 has changed this completely. Now the standard include file
set is incredibly more powerful, versatile and useful.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

> :> behaviour outside the range 0-1,
> : they have changed the transmit behaviour outside the range 0-1 ???
> : :(
> : I liked it the way it was...
>   Really? Do you know how it was previously? It was pretty illogical and didn't
> make much sense.
hmmm, weird, I tried it, and it is indeed an illogical behaviour.
Strange, cause I thought I used it once as a special effect and it worked exactly the
way
I supposed it would...

cu!
--
camera{location-z*3}#macro G(b,e)b+(e-b)*(C/50)#end#macro L(b,e,k,l)#local C=0
;#while(C<50)sphere{G(b,e),.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1
;#end#end L(y-x,y,x,x+y)L(y,-x-y,x+y,y)L(-x-y,-y,y,y+z)L(-y,y,y+z,x+y)L(0,x+y,
<.5,1,.5>,x)L(0,x-y,<.5,1,.5>,x)               // ZK http://www.povplace.be.tf

Post a reply to this message

"Zeger Knaepen" <zeg### [at] studentkuleuvenacbe> wrote in message
news:3c56a307$1@news.povray.org...
> If I'm wrong about this, then I have no problems whatsoever with POV3.5,
but if that's
> right, I really think starting with POV4.0 would have been a better idea
(and no: I'm not
> telling you what to do, I'm telling you what I would do)
>
> cu!

The POV Team has made it very clear that they wanted to incorporate certain
features (which everybody liked) into POV-Ray in a clean, efficient manner.
To hear them write about it, the code in Mega POV is literally a wasteland
of half-finished patches and undocumented shortcuts.  When they decided to
incorporate these features into the official compile, most of them had to
have their syntax reworked, and have their code rewritten, which is a lot of
work.  They felt that actually getting these features into POV ~first~ was
more important than the C++ rewrite that 4.0 seems to be.  Personally, I'm
just glad I've got any version of POV - Great job, Team!

...Chambers

Post a reply to this message

Warp wrote:

>   Note that you can also use pigment functions in pov3.5, but it's more
> versatile: You can not only get the gray value of the pigment as its value,
> but also any of the color channels or even a hf value.

The one thing I truely mourn in the changes to the functions is their 
inability to return colour at run-time.

There were certain things that could be done with

#declare fn_pig = function { pigment { ... } }
#declare warped_pig = pigment { function { fn_pig(fn_x,fn_y,fn_z) } }

type constructs in O(n) time which now need O(exp(n)) time and become 
ludicrously slow.

Please note this isn't a complaint or (Heaven forbid!) a feature request 
- just a small requiem for a useful feature fallen by the wayside ...

Bye for now,
	Mike Andrews.

Post a reply to this message

> The POV Team has made it very clear that they wanted to incorporate certain
> features (which everybody liked) into POV-Ray in a clean, efficient manner.
> To hear them write about it, the code in Mega POV is literally a wasteland
> of half-finished patches and undocumented shortcuts.  When they decided to
> incorporate these features into the official compile, most of them had to
> have their syntax reworked, and have their code rewritten, which is a lot of
> work.  They felt that actually getting these features into POV ~first~ was
> more important than the C++ rewrite that 4.0 seems to be.  Personally, I'm
> just glad I've got any version of POV - Great job, Team!
Now this is a reply that's helping me to understand why POV3.5 was made.  tnx :)
I didn't know the MegaPov code was like that.  I've never looked at POV-Ray's source.

cu!
--
camera{location-z*3}#macro G(b,e)b+(e-b)*(C/50)#end#macro L(b,e,k,l)#local C=0
;#while(C<50)sphere{G(b,e),.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1
;#end#end L(y-x,y,x,x+y)L(y,-x-y,x+y,y)L(-x-y,-y,y,y+z)L(-y,y,y+z,x+y)L(0,x+y,
<.5,1,.5>,x)L(0,x-y,<.5,1,.5>,x)               // ZK http://www.povplace.be.tf

Post a reply to this message

Ben Chambers <bdc### [at] yahoocom> wrote:
: The POV Team has made it very clear that they wanted to incorporate certain
: features (which everybody liked) into POV-Ray in a clean, efficient manner.
: To hear them write about it, the code in Mega POV is literally a wasteland
: of half-finished patches and undocumented shortcuts.  When they decided to
: incorporate these features into the official compile, most of them had to
: have their syntax reworked, and have their code rewritten, which is a lot of
: work.  They felt that actually getting these features into POV ~first~ was
: more important than the C++ rewrite that 4.0 seems to be.  Personally, I'm
: just glad I've got any version of POV - Great job, Team!

  These are the reason which also I think that pov3.5 is a superb work.

  Also remember that being an official version gives the program certain
status. Not all people want or like to use third-party programs and patches
but only officially distributed versions and this is understandable.

  Besides, pov3.5 is a really good testbed for pov4. Really many things have
been developed and implemented in 3.5 that might not have been implemented in
pov4 if 3.5 had not been made. 3.5 gives invaluable experience for the big
work of making pov4.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

"Zeger Knaepen" <zeg### [at] studentkuleuvenacbe> wrote in message
news:3c56ca96@news.povray.org...
> Now this is a reply that's helping me to understand why POV3.5 was made.  tnx
:)
> I didn't know the MegaPov code was like that.  I've never looked at POV-Ray's
source.
>

Ah! Now I understand your confusion. I (and presumably others) assumed you knew
this. Of course it's still your fault ;) - you should have said.

"IMHO, given the perfect code in use in MegaPov, the official POV team should
move on to v4.0 rather than re-inventing the wheel"....

Post a reply to this message