On Wed, 30 Jan 2002 04:06:13 +0100, Zeger Knaepen wrote:
>> > and cannot be layered.
>> I don't understand this statement.  Why would you want to layer a normal
>> anyway?
> How would you make a dirty blurred-reflective metal?  In MegaPov you could add
> a layer of
> a dirt-texture to your blurred-reflective metal, but because layered-textures 
> don't work
> with texture_maps, you couldn't add a layer of dirt to the blurred-reflective 
> metal in
> POV3.5.
> It's probably possible to 'fake' layers using texture_maps, but you have to
> agree that
> layered textures are much easier to understand and to make.

True.  Personally, I don't understand why you can't use a texture_map in a
layered texture.  Let me investigate that a little further.
 
BTW, can you fix your newsreader to use 80 columns per line or less?  The
above is what your post looks like here.

--
#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

> True.  Personally, I don't understand why you can't use a texture_map in a
> layered texture.  Let me investigate that a little further.
tnx :)

> BTW, can you fix your newsreader to use 80 columns per line or less?  The
> above is what your post looks like here.
Done.
I hope it didn't ruin my sig :-/

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

> Done.
> I hope it didn't ruin my sig :-/
pfew! :)

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

On Wed, 30 Jan 2002 04:21:21 +0100, Zeger Knaepen wrote:
>> True.  Personally, I don't understand why you can't use a texture_map in a
>> layered texture.  Let me investigate that a little further.
> tnx :)

Well, looking at the code, the main reason is that it would be a major 
rewrite if it were possible at all.  But don't lose hope.

--
#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

> Well, looking at the code, the main reason is that it would be a major
> rewrite if it were possible at all.
AAARGH!!!
<jumping around the room> /me loses all hope for a good life...
<bouncing head against his keyboard> qdfmjaervckjmdfmd

> But don't lose hope.
oh...
sorry 'bout that :)

(I think I need some sleep :)

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

> Please don't cast aspersions like this without backing them up with some
> evidence of some sort.  What evidence do you have that the POV-Team is not
> fixing compatibility bugs wherever they're found?

Most recently there was something in the thread "long time, no see" where
someone brought up a difference in the clock value generated by a scene file
and one of the responses was

"As said, it is a precision issue.  It is irrelevant what 3.1 would output
because it is a precision issue and thus it really doesn't matter if
something changed or not.  Just get used to it."

I don't know if it was an actual bug or not but it seemed to be written off
without investigation.

In another thread:

"In article <Xns### [at] 204213191226> ,
che### [at] sympaticoca
(Coridon Henshaw) wrote:

> Beta 10 ignores the angle statement unless it is the last
> component in the camera block (this change wasn't documented) and requires
> the up and right vectors to be given when using the orthographic camera.

Neither is correct.  Both work at any place in the camera statement.
"

This one is a bug that I noticed when rendering an older file.

Of course, it's still in beta so there's still time for these to be checked
and fixed if needed.  It's just that sometimes users are not asked to double
check if it cannot be reproduced, or if there's a good reason for a change
that it is not given.

Post a reply to this message

In article <slr### [at] fwicom>,
 Ron Parker <ron### [at] povrayorg> wrote:

> bold and italic characters in the middle of a string?  We could write a
> whole freakin' typesetting language in the text object, and somebody
> still wouldn't be happy.  Best to stop that before it starts.

Hmm...embedded PDF support? ;-)


> > Glows (Ahem, Chris, didn't you write this one? ; } ).
> 
> After 3.5 was well past the planning stages, again.  And Chris is a member
> of the TAG, not the POV-Team, so he doesn't decide what goes in and what
> doesn't.

Besides, I've said many times the patch is incomplete...I believe I even 
stated this in the documentation.


> > Particle_system (I know the author is around somewhere).
> 
> See comments for POVMan.

More like the one for glows...not nearly complete enough.


> Other things you don't know about 3.5: it's more stable, cleaner
> code, has more internal consistency in the language, and generally
> runs faster than MegaPOV.  Code you write for 3.5 will be compatible
> in some way with 4.0.  Code you write for MegaPOV today won't even 
> be compatible with the next version of MegaPOV, let alone any 
> official version of POV.  

Personally, this is my favorite part...I plan to rewrite both the 
particle system and glow patches to take advantage of POV 3.5, doing 
things which I couldn't do (without a lot of effort) with MegaPOV.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

25ct wrote:

> In actual fact, It was a very confusing time for me as Megapov and 3.1 were
> being talked about quite a lot in the forums, and as a result, I now have
> 3.1g, Megapov 0.7 and 3.5 beta10 installed.

Is that all? I've got 1.0, 2.2, 3.01, 3.1, 3.5 and a half dozen or more
patched versions installed. :)

-- 
Ken Tyler

Post a reply to this message

On Tue, 29 Jan 2002 21:49:45 -0600, Mike Hough wrote:
>> Please don't cast aspersions like this without backing them up with some
>> evidence of some sort.  What evidence do you have that the POV-Team is not
>> fixing compatibility bugs wherever they're found?
> 
> Most recently there was something in the thread "long time, no see" where
> someone brought up a difference in the clock value generated by a scene file
> and one of the responses was
> 
> "As said, it is a precision issue.  It is irrelevant what 3.1 would output
> because it is a precision issue and thus it really doesn't matter if
> something changed or not.  Just get used to it."

Though that statement was made by a member of the POV-Team, it was not
an official position unless he said it was.  I don't believe he did.

> I don't know if it was an actual bug or not but it seemed to be written off
> without investigation.
> 
> In another thread:
> 
> "In article <Xns### [at] 204213191226> ,
> che### [at] sympaticoca
> (Coridon Henshaw) wrote:
> 
>> Beta 10 ignores the angle statement unless it is the last
>> component in the camera block (this change wasn't documented) and requires
>> the up and right vectors to be given when using the orthographic camera.
> 
> Neither is correct.  Both work at any place in the camera statement.
> "
> 
> This one is a bug that I noticed when rendering an older file.

The camera stuff is still being worked on, to the best of my knowledge.

--
#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

In article <3c576a20$1@news.povray.org>,
 "Zeger Knaepen" <zeg### [at] studentkuleuvenacbe> wrote:

> (I think I need some sleep :)

I think you just need less caffeine and/or sugar...

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message