On Tue, 29 Jan 2002 14:05:42 +0100 Zeger Knaepen wrote:

>kewl, would you do that? :)

  I am feeding coins through the ventilation slots in my computer. Are they
coming through at your end? :)

-- 
Alan
ako### [at] povrayorg
a k o n g <at> p o v r a y <dot> o r g

Post a reply to this message

> 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.
I know.  I assumed the MegaPov code was good, because it rendered my scenes the way I
wanted it to.

> "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"....
That's exactly what I was trying to say.  But if the MegaPov code isn't as perfect as
I
thought it was, then I understand the need for POV-Ray 3.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

>   I am feeding coins through the ventilation slots in my computer. Are they
> coming through at your end? :)
not yet.
Must be a slow connection :)

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

In article <3C5### [at] readingacuk> , Michael Andrews 
<M.C### [at] readingacuk>  wrote:

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

?!?!?

I don't understand what you want to do or what you are up to.  Or what
supposedly now takes exponential time.

    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

"Zeger Knaepen" <zeg### [at] studentkuleuvenacbe> wrote in message
news:3c56d563@news.povray.org...
> >   I am feeding coins through the ventilation slots in my computer. Are
they
> > coming through at your end? :)


> not yet.
> Must be a slow connection :)

    No, they've taken the wrong turn. Sorry, I'm getting them.

    :)

   ~Steve~


>
> cu!

Post a reply to this message

Zeger Knaepen wrote:

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

I think Thorsten and co. would do well to take note of this fact. Comments concerning
excluded
MegaPOV features are generally motivated by the fact that people care deeply about
POV-Ray and
the direction of its development. I find it ironic that there is an "us and them"
mentality
developing between the POV team and users community that previously only existed
between the
POV community and the world of 3D at large. As for my remarks, from a user's
standpoint, I
stand by them, except for a single clarification; astute readers would have realized I
meant
bicubic patch type 2 (Warp, you of all people should have caught this), instead of
mesh 2. And
yes, the patches in type 2, in addition to parsing faster, seemed to make for smoother
objects, with fewer attifacts. Other than that, I still find the excluded features of
value.
This doesn't mean that I don't like, use, or admire 3.5 (I was careful to praise the
features
that were clear improvements). It simply means that I liked some of the things that
were left
out, and I hope that when 3.5 comes out of beta, a new MegaPOV will arise and
development on
these features will continue. Until that time, My POV arsenal will contain a few
different
executables in the bin folder. Simple as that. If the hostility that is perceived by
the POV
development team were real, the dissenters would all be off using Virtualight or
something.
Fact is, speaking for myself, I love POV-Ray and think the team has done a great job.
This
doesn't mean that I am not entitled to my opinion. It would seem that the whole point
of this
news server is to promote a free exchange of ideas, not to be used as a vehicle for
those of
differing views to be shut down by an intolerant stream of abuse.

Post a reply to this message

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

> > Those are function patterns. ;-)
> > In POV 3.5, you can make functions directly from patterns. In MegaPOV,
> > you have to use a pigment with a Black-White color_map.
> and what's the difference (except for a slightly longer syntax)?

Speed: it takes longer to evaluate a pattern, do the additional 
computation for a pigment, and convert the resulting color to a 
grayscale value than to just evaluate a pattern.


> > Also, check out the additions to the standard includes...
> hmmm, I've never used standard includes... So I'm not really interested in 
> the additions

Check out the additions, you will use them. ;-)
In addition, it will be necessary if you want to access the built-in 
isosurface functions. The includes are a lot more useful now, not just 
lists of predefined textures or colors...

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

In article <3C5613BD.4B8FA532@aol.com>, Dave Dunn <poi### [at] aolcom> 
wrote:

> Is this some "insider" joke?

No.


> Let's take a look at what the "possibly not
> useful" features are that didn't make it into the 3.5 self-incrementing
> Beta (all of which work just fine thank you):

They don't. Most of them are incomplete, redundant, or simply get in the 
way of future plans.


> MegaPOV 0.7
> Reflection blur - I've seen enough workarounds in these groups to know this
> is needed.

The "workarounds" are better: faster and more flexible. The patch was a 
slow and incomplete hack. If this is ever implemented in an official 
version, it will probably be much more flexible.


> Motion blur - okay, flawed, but certainly useful; I use it often.

Useful, but as you said, flawed, so it didn't get into 3.5.


> Blinn microfacets - superior to specular highlights in every way.

Not that superior, and there were reasons not to add it. The POV-Team 
has mentioned they are considering a more general way of specifying this 
sort of thing, though it won't reach POV 3.5.


> Heightfield_height_at (no way trace works better on hfs, sorry).

Sorry, the trace() function works better, in every single case. The 
hf_height_at feature was only useful when trace() hadn't been added, now 
it is a useless redundancy which probably won't make it into the next 
MegaPOV.


> Text object enhancements (why use a macro when you can just use this?).

Because the macro will work on any object. If you decide you want a 
union of a text object and a cylinder as an underline, you can do so 
with no extra coding.


> Glows (Ahem, Chris, didn't you write this one? ; } ).

I converted the patch from POV AFX and heavily modified it. It is simply 
not ready for an official release.


> POVMan
> ClothSim (How is 3.5 better than this?)
> Renderman-like Shaders (See falling star animations at p.b.a)

Not at all close to ready for the official version.


> MegaPOV Plus
> Particle_system (I know the author is around somewhere).

Again, nowhere near ready for 3.5. I'm actually waiting for 3.5 to be 
released so I can finish this and the glow patch.

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

"Dave Dunn" <poi### [at] aolcom> wrote in message
news:3C56F507.1F0265E4@aol.com...

    Well, I don't think there's been an  "...intolerant stream of abuse",
Dave, but well said anyway.

   I came in when 3.1g was up and running, and as a newbie, found it fairly
easy to use apart from I didn't use all the 'methods' that I could have. 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.

   Personally, I'm glad that 3.5 is coming out and have enjoyed immensly the
experimentation side of it. It also brings me up to date and in line with
other people here too.
   Before I discovered PoV-Ray, I was computer-art illiterate, but 'because'
of PoV-Ray and the people that surround it, I know a fair amount more now,
and for that I will always be thankful to the people that put it together
and will remain loyal as a result.

   And that's it.

   Just my tuppence worth.

   ~Steve~

Post a reply to this message

>   Why? With the "workarounds" you get a nicer result, often even faster.
It's
> also more versatile, as you can scale non-uniformly the blur amount, and
even
> make the blurring amount to follow a pattern (or function). This is not
> possible with the "hack" in megapov.

My tests, using the code from the VFAQ, indicate that the "workaround" shows
serious aliasing, is quite cumbersome to write, is slightly slower, appears
to be less accurate, and cannot be layered.  It seems to be more of a hack
in regards to complexity and end result than the reflection blur in MegaPOV.
The same averaged normal trick works in MegaPOV too, so it's not like having
reflection blur deminishes the versitility of the program at all.  This
applies to many other features in MegaPOV.  Ironically, the issue of
backward compatibility seemed to have been a higher priority in MegaPOV than
it is in 3.5, as least so far in the beta process.  I don't recall ever
having a problem rendering a 3.1 scene file in megapov.

Post a reply to this message

On 28 Jan 2002 21:12:58 -0500, Warp wrote:
> Zeger Knaepen <zeg### [at] studentkuleuvenacbe> wrote:
>:>   On the other hand there are things that can be done with 3.5 that can't
>:> be done with megapov.
>: like?
> 
>   Like pattern functions, fractal patterns with exponents >4, transmit
> behaviour outside the range 0-1, support for reading JPEG and TIFF,
> unicode support, etc.

Forward compatibility with future versions...

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

On Tue, 29 Jan 2002 14:16:23 -0500, Dave Dunn wrote:
> bicubic patch type 2 (Warp, you of all people should have caught this), instead of
mesh 2. And
> yes, the patches in type 2, in addition to parsing faster, seemed to make for
smoother
> objects, with fewer attifacts. Other than that, I still find the excluded features
of value.

Unfortunately, the code for bicubic patch type 2 was buggy and even its 
original author didn't think it was suitable for inclusion in 3.5.

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

On Mon, 28 Jan 2002 22:15:10 -0500, Dave Dunn wrote:
> MegaPOV 0.7
> Reflection blur - I've seen enough workarounds in these groups to know this
> is needed.

Actually, it's not all that necessary.  It wasn't any faster than the 
"workaround" (which isn't a workaround at all, but is based on actual
physical principles) in most day-to-day scenes.  There's only one thing
it did better, and that's multiple blurred interreflections.  It didn't,
however, do blurred transmission, which the "workaround" does.

> Motion blur - okay, flawed, but certainly useful; I use it often.

Written by Nathan Kopp, who is a member of the POV-Team.  I'm pretty sure
he didn't feel it was up to snuff for the 3.5 release.

> Blinn microfacets - superior to specular highlights in every way.

Added to MegaPOV after 3.5 development was started.  We had to draw the
line somewhere, no?

> Heightfield_height_at (no way trace works better on hfs, sorry).

It certainly doesn't work any worse.  hf_height_at didn't return the
normal, it only worked for heightfields, and it bloated the language
unnecessarily.  If you want it, write a macro.  If you don't like
trace, use a pigment function.

> Text object enhancements (why use a macro when you can just use this?).

Because someday you'll discover that the three effects that were "built
in" in MegaPOV just aren't enough.  You'll want flush justification.  
You'll want flush justification that only modifies interword spacing.
You'll want to fit your text to a curve.  You'll want to use a different
angle for the baseline than for the character advance.  Should we add
a new keyword to the language for each of these uses?  Of course not.
Why, then, should there be keywords for left/right/center justification?
What about top/bottom/baseline/center vertical alignment?  What about
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.

> Ini_option (why in the world was this removed?).

Again, written by Nathan Kopp and voluntarily removed.  It caused more
problems than it solved.  There are reasons the things that are INI 
options aren't script options.  Resolution independence, OS independence,
and various other things are among them, but you can think of others if
you try.

> Mesh Type 2 (parsed much faster and came out smoother).

You meant bicubic type 2, as you mentioned.  That was removed because
the author left "//FIXME" comments sprinkled throughout.  When we 
contacted him, he felt that that work shouldn't be added to 3.5 without
major overhauls, and nobody was prepared to do the necessary overhauls.

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

> POVMan

Not in MegaPOV per se, not a complete SL implementation, not offered by
the author for inclusion in the official version, and not completed before
the cutoff for new features in 3.5.

> ClothSim (How is 3.5 better than this?)

See comments for POVMan.

> Renderman-like Shaders (See falling star animations at p.b.a)

I have to assume you mean POVMan here, since I'm not familiar with any other
Renderman-like whatsis.  The POV-Team has to know about these patches for
them to be included, you know.  That means, usually, that the author has to
actually say something to us about them, and give us the rights to include
them.  I know I don't have time to read povray.binaries.<anything> anymore,
so perhaps this patch has escaped our notice.  In any case, it doesn't 
appear to be a vanilla MegaPOV patch.

In any case, if we add programmable shaders they will not resemble 
Renderman SL in any way.  That's not conceit, or hubris, or unreasoning
defiance.  That's simple pragmatism: we can't implement everything SL
needs (in particular, the dU and dV variables turn out to be close to
impossible in POV-Ray) so we shouldn't lead people to believe that any
old SL shader will work.  Such functionality is likely to be available
in some form eventually, but none of the existing patches will help with
that.

By the way, star "shaders" are possible in vanilla 3.1.  See the 3.5 
standard include files.  You're looking for a macro called "Star_Pig"
in textures.inc.
 
> MegaPOV Plus

See comments for POVMan.

> Particle_system (I know the author is around somewhere).

See comments for POVMan.

> OK, there are a few things I like about 3.5 Beta+, like the easier
> dispersion 

Let's not forget "more physically accurate" shall we?  I spent days 
researching color theory to come up with something better there.  

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.  

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

On Tue, 29 Jan 2002 04:43:07 +0100, Zeger Knaepen wrote:
> I really don't understand why POV-Ray 3.5 was made.  IMHO it's a waste of time.  The
> POV-Team should have concentrated on starting with POV-Ray 4.0.
> I mean: POV 4.0 will be a complete rewrite, so everything they do now will have to
be
> redone.  What's the point?

People were whining that there wasn't a new official version.  We can't
please everybody, it seems.

-- 
#macro R(P)z+_(P)_(P)_(P+1)_(P+1)+z#end#macro Q(C,T)bicubic_patch{type 1u_steps
6v_steps 6R(1)R(3)R(5)R(7)pigment{rgb z}}#end#macro _(Y)#local X=asc(substr(C,Y
,1))-65;<T+mod(X,4)div(X,4)9>-2#end#macro O(T)Q("ABEFUQWS",T)Q("WSXTLOJN",T)#
end O(0)O(3)Q("JNKLCGCD",0)light_source{x 1}// ron### [at] povrayorg

Post a reply to this message

On Tue, 29 Jan 2002 14:26:11 +0100, Zeger Knaepen wrote:
>> Pov3.5 takes the best of Megapov, remove the bugs, and makes it the official
>> version from which all future versions will be build.. I don't see why
>> Pov4.0 should be a complete rewrite.. Anyway, making Pov3.5 first, is the
>> logical way to go.. It's like to climp up the stairs, instead of trying to
>> jump to the top.
> It's not my idea to make POV4.0 a complete rewrite (although I agree that it would
> probably be a good thing).  But didn't the POV-Team say that POV4.0 would be a
complete
> rewrite in C++?

Yes.  Most of that has to do with having total ownership over the code.  It
might surprise you to know that some of the code is not necessarily ours to
do with as we will.  Thus, we can't really rewrite large chunks of the 
license.

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

But is that what you would do if it had been years since an official version 
was released, the users were getting restless, and 4.0 was probably still
years away?

BTW, parts of the 4.0 rewrite have already started.  Option handling is 
totally redone in 3.5, for example.

-- 
#macro R(P)z+_(P)_(P)_(P+1)_(P+1)+z#end#macro Q(C,T)bicubic_patch{type 1u_steps
6v_steps 6R(1)R(3)R(5)R(7)pigment{rgb z}}#end#macro _(Y)#local X=asc(substr(C,Y
,1))-65;<T+mod(X,4)div(X,4)9>-2#end#macro O(T)Q("ABEFUQWS",T)Q("WSXTLOJN",T)#
end O(0)O(3)Q("JNKLCGCD",0)light_source{x 1}// ron### [at] povrayorg

Post a reply to this message

On Tue, 29 Jan 2002 13:26:41 +0100, Christoph Hormann wrote:
> Megapov, although being quite stable and containing various features that
> are not in 3.5 has some serious flaws, especially in the
> isosurface/function part like 'trace()' not working on isosurfaces and

That was a bug.  I thought it was fixed in the latest MegaPOV.


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

On Tue, 29 Jan 2002 19:28:53 -0600, Mike Hough wrote:
> My tests, using the code from the VFAQ, indicate that the "workaround" shows
> serious aliasing, 

You're doing something wrong.  Try adjusting the scales of the normals and
the displacements to fit your scene better.

> is quite cumbersome to write, 

This is why you have macros.

> is slightly slower, 

This is the price of the flexibility you get by specifying your own normals
instead of using the fake one that was in the MegaPOV hack.

> appears
> to be less accurate, 

The word "appears" here cannot be stressed enough.  The "workaround" uses
physically correct principles.  The hack does not.

> and cannot be layered.  

I don't understand this statement.  Why would you want to layer a normal
anyway?

> The same averaged normal trick works in MegaPOV too, so it's not like having
> reflection blur deminishes the versitility of the program at all.  

Nope.  But it limits future expansion if we incorporate a half-baked, ill-
thought-out feature like MegaPOV's reflection blur.  There is a right way
to do this internally to POV, but the way MegaPOV did it isn't it.

> applies to many other features in MegaPOV.  Ironically, the issue of
> backward compatibility seemed to have been a higher priority in MegaPOV than
> it is in 3.5, as least so far in the beta process.  

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?

> I don't recall ever
> having a problem rendering a 3.1 scene file in megapov.

Didn't use too much layered transparency or radiosity, then, did you?


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

> Yes.  Most of that has to do with having total ownership over the code.  It
> might surprise you to know that some of the code is not necessarily ours to
> do with as we will.  Thus, we can't really rewrite large chunks of the
> license.
didn't know that.

> But is that what you would do if it had been years since an official version
> was released, the users were getting restless, and 4.0 was probably still
> years away?
Do users really need an official version every few years?  I'm happy with unofficial
patches, as long as they work the way I expect :)

> BTW, parts of the 4.0 rewrite have already started.  Option handling is
> totally redone in 3.5, for example.
kewl :)

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

> People were whining that there wasn't a new official version.  We can't
> please everybody, it seems.
don't get me wrong, it's not that I'm not happy with an official version of POV-Ray,
but I
just hope working on POV3.5 doesn't have a sideeffects, like a later POV4.0 release :)
I mean: I can see the need for official version of POV-Ray, but I'd rather have POV4.0
within 2 years and no official version in the meantime, than POV4.0 withing 4 years
but an
official 3.X version every year.
But as long as I can play with POV-Ray, I'm happy :)

(I hope 2 years wasn't too optimistic?)

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

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

For the record: I haven't used MegaPov's reflection_blur much, because I didn't really
like the results.  The 'workaround' gives much better results, and seems to be faster,
so
except for the layering-problems, I think it's a much better way to make blurry
reflections.

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

Zeger Knaepen wrote:

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

Perhaps a little history might help -
http://news.povray.org/povray.announce.frequently-asked-questions/16698/106689/?tmax=100#106689

-- 
Ken Tyler

Post a reply to this message

/* 
On 29 Jan 2002 22:26:26 -0500, Ron Parker wrote:
> 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.

Okay, for those of you who didn't lose hope, I have something resembling
good news.  It's true that you can't layer over texture maps.  But the 
next best thing is to not have to use a texture map.

Notes: 
 
- This won't work with blurred refraction.  POV uses only the normal
  of the top layer to spawn a refracted ray.  Sorry, but this isn't
  likely to change in the near future.
- The limit on the number of layers you can have in a single texture
  is currently 20, so you can't use more than 20 samples minus the
  number of other layers you want to use.  I'm not sure, but I think 
  that number doesn't need to be so low.
- Note the changes from the VFAQ example: the pigment is only on the
  lowest layer, and the reflection amount must be divided by the number
  of samples (this division happens automatically in average texture_maps)
*/

#declare BlurAmount = .2; // How blurred the reflection should be  
#declare BlurSamples = 10; // How many reflected rays to shoot

camera {location <0,1,-5> look_at y}
plane { y 0 
  finish {ambient 1} 
  pigment {gradient x color_map {[0 red 1][1 blue 1]} scale .5}
}

cylinder {0 5*y 1
  texture {
    pigment { color rgb 0 } // The pigment of the object here
  } 
  #declare Ind = 0; 
  #declare S = seed(0); 
  #while(Ind < BlurSamples) 
    texture {
      pigment {color rgbt 1}
      finish { reflection .9/BlurSamples}
      normal { bumps 
        BlurAmount 
        translate <rand(S),rand(S),rand(S)>*10
        scale 1000 
      } 
    } 
    #declare Ind = Ind+1; 
  #end 
}

-- 
plane{-z,-3normal{crackle scale.2#local a=5;#while(a)warp{repeat x flip x}rotate
z*60#local a=a-1;#end translate-9*x}pigment{rgb 1}}light_source{-9red 1rotate 60
*z}light_source{-9rgb y rotate-z*60}light_source{9-z*18rgb z}text{ttf"arial.ttf"
"RP".01,0translate-<.6,.4,.02>pigment{bozo}}light_source{-z*3rgb-.2}//Ron Parker

Post a reply to this message

"Mike Hough" <Ama### [at] aolcom> wrote in message
news:3c576c79@news.povray.org...
> 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.

Bad example.  The person with the problem had done something you are told
never to do with floating point values, and was upset when it (as predicted)
eventually failed on him.

...Chambers

Post a reply to this message

Ron Parker wrote:

> > "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.

That one was a direct quote. I thought it was a bit abrupt but figure
that since Thorsten knows more about the inner-workings of POV-Ray
than I far be it from me to question him on it.

-- 
Ken Tyler

Post a reply to this message

On Tue, 29 Jan 2002 20:05:31 -0800, Ken wrote:
> 
> 
> Ron Parker wrote:
> 
>> > "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.
> 
> That one was a direct quote. I thought it was a bit abrupt but figure
> that since Thorsten knows more about the inner-workings of POV-Ray
> than I far be it from me to question him on it.

I'm not questioning the factual accuracy of the statement (i.e. that it is,
indeed, a precision issue.)  I'm just saying the tone is not necessarily
indicative of official policy.

-- 
#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{rgbt 1}hollow interior{media{emission T}}finish{
reflection.1}}#end Z(-x-x.2y)Z(-x-x.4x)camera{location z*-10rotate x*90}

Post a reply to this message

Ron Parker wrote:

> I'm not questioning the factual accuracy of the statement (i.e. that it is,
> indeed, a precision issue.)  I'm just saying the tone is not necessarily
> indicative of official policy.

My Bad. (don't you hate it when people say that? I do.)

Post a reply to this message

On Tue, 29 Jan 2002 20:11:47 -0800, Ken wrote:
> 
> 
> Ron Parker wrote:
> 
>> I'm not questioning the factual accuracy of the statement (i.e. that it is,
>> indeed, a precision issue.)  I'm just saying the tone is not necessarily
>> indicative of official policy.
> 
> My Bad. (don't you hate it when people say that? I do.)

Nope, mine.  I didn't make that clear in the original post.

(And yes, I do.  Your bad what?  Breath?)

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

"Ken" <tyl### [at] pacbellnet> wrote in message
news:3C576D9E.D6CEA9B8@pacbell.net...
>
>
> 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. :)

    Well you've been around for aeons....  ;)

    ~Steve~

>
> --
> Ken Tyler

Post a reply to this message

In article <3c576c79@news.povray.org> , "Mike Hough" <Ama### [at] aolcom> 
wrote:

> "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.

Oh, come on.  First of all you are quoting from the second thread about this,
in the original thread several people had explained the problem in more detail
and the nature of floating-point precision and how to properly deal with it.
As I have no way in proving that there is no problem until the source code is
released, you either take my word for it or you don't.  If you really want to
use this fact to claim there is a problem and nobody cares, I find it rather
unreasonable :-(

Do you really think there is some code in there that says:
"add 0.00000000298023224 to clock to annoy users"?  ;-)

    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

Warp wrote:
<snip lots of stuff>

Great!  Now I'm drooling on my keyboard for 3.5

From reading the messages, I have decided to wait for 3.5.  If, after a
while, I learn and exploit everything in it, I'll check into the then
3.5 based Mega-Pov.  

But since there's still lot's of 3.1 aspects that I haven't figured out
how to use, it may take a while.

-- 
Tom A.
"No doubt many that post deserve to be flamed.  And many that are flamed
didn't deserve it.  Can you give them the latter?  Then don't be so
quick to deal out the former!" - not Gandalf.
Deja mail is gone.  Look for me at raugost at yahoo . com

Post a reply to this message

I always meant to ask; I keep hearing that in POV3.5 iso's, "&" means OR
and "|" means AND. How come?

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

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
: Do you really think there is some code in there that says:
: "add 0.00000000298023224 to clock to annoy users"?  ;-)

  I was wondering if floats could *really* be that inaccurate. When I make
this with povray:

#debug concat(str(99/100,0,25), "\n")

what I get is:

0.9899999999999999911182158

(instead of 0.99). I though, "is this really possible?".
  Then I wanted to be sure and I made a small C program which does basically
the same thing:

#include "stdio.h"
int main()
{
    printf("%.25f\n", 99.0/100.0);
    return 0;
}

  This program prints, surprise surprise:

0.9899999999999999911182158

  So now I am convinced that there's no bug in povray.

  Of course, when making a scene file, one has to minimize the effects of
floating point inaccuracy.
  For example, don't do it this way:

#declare Ind = 0;
#declare Clock = 0;
#while(Ind <= 100)
  #debug concat("Clock: ", str(Clock,0,25), "\n")
  #declare Clock = Clock+1/100;
  #declare Ind = Ind+1;
#end

(The last number printed is 1.0000000000000006661338148.)
  Instead, do it this way:

#declare Ind = 0;
#while(Ind <= 100)
  #declare Clock = Ind/100;
  #debug concat("Clock: ", str(Clock,0,25), "\n")
  #declare Ind = Ind+1;
#end

(The last number printed is 1.0000000000000000000000000.)

  The reason for the second code being better than the first is left as
an exercise to the reader.

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

Grey Knight <s16### [at] namtarqubacuk> wrote:
: I always meant to ask; I keep hearing that in POV3.5 iso's, "&" means OR
: and "|" means AND. How come?

  I haven't followed this thing quite closely, but AFAIK the meaning of '&'
and '|' was changed to logical operators "logical and" and "logical or"
(instead of being set theory operators "intersection" and "union", as they
are in megapov, I think).

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

"Warp" <war### [at] tagpovrayorg> wrote in message news:3c580c79@news.povray.org...

<snip>

Just out of curiousity, why does this surprise you?

Also just out of curiosity, if you ask a robot do they say "but it does say
0.99"? Hmm...

Post a reply to this message

Tom Melly <tom### [at] tomandlucouk> wrote:
: Just out of curiousity, why does this surprise you?

  I knew that doubles are inaccurate, but it surprised me that they are *that*
inaccurate. The inaccuracy is "only" in the 18th decimal.

  On the other hand, 18 decimals starts to sound like the maximum number of
digits (when converted to decimal) that the base of a double can hold...

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

"Ken" <tyl### [at] pacbellnet> wrote in message
news:3C576D9E.D6CEA9B8@pacbell.net...
>
>
> 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. :)
>

Why do I never see anyone mention 2.1? That's what I've still got
loaded, not 2.2 but all after and megapov 0.7, all DOS. Now I'm in
serious trouble <grin> coz I needed to get Winpov 3.1 for 1st time to
try Schmitt's recompile (Hey! I can use my box while Pov is working.
Thats a novelty!). So thought might as well get WinMega while I'm at
it. If I'm not careful, 3.5b will worm its way in soon.

Alf

Post a reply to this message

Wasn't it Zeger Knaepen who wrote:
>>   On the other hand there are things that can be done with 3.5 that can't
>> be done with megapov.
>like?

One neat little feature is spline functions. It's now possible to use a
spline to define a function, and then use that function, say, to specify
an isosurface without any of the mathematics that would otherwise be
involved.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

Wasn't it Zeger Knaepen who wrote:
>> : And again: I never used the include files bundled with POV-Ray.
>>   Because there wasn't anything interesting in them, until now.
>no, because I like to make everything myself.  Even when I add a lensflare, it's 
>with a
>customized version of Colefax' include file and using a custom lens effect.

Note, however, that there's been a slight tendency to move some of the
stuff out of the core code and into standard include files. A few things
that are features of the MegaPOV language are implemented in the 3.5
include files.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

"Zeger Knaepen" <zeg### [at] studentkuleuvenacbe> wrote:
> > But is that what you would do if it had been years since an official
version
> > was released, the users were getting restless, and 4.0 was probably still
> > years away?
> Do users really need an official version every few years?  I'm happy with
unofficial
> patches, as long as they work the way I expect :)
>

AFAIK: Yes! Just consider the use of POV as a benchmark...
Although this is probably not, what POV was invented for, and where it's
real powers are, it's still used as an official benchmark...

You can't think, that people are using "unofficial patches" for doing serious
benchmarks ...


--
#macro J(N A)#local a=mod(N 3);#local W=<int(mod(A,4)*2)int(-A/4)9>*2;#if
(!mod(a 2))sphere{W,2,2pigment{color rgb<a*5A/2W.x/A*5>}}#if(a<1)sphere{W
+<2,0>2 2pigment{color rgb<a*10A 10>}}#end#end#if(N>3)J(int(N/3)A+1)#end#
end blob{J(29229171 0)threshold 1translate<-6 3>}/******Jan Walzer******/

Post a reply to this message

probably it would have been enough, to look at IEEE 754 ?

--
#macro J(N A)#local a=mod(N 3);#local W=<int(mod(A,4)*2)int(-A/4)9>*2;#if
(!mod(a 2))sphere{W,2,2pigment{color rgb<a*5A/2W.x/A*5>}}#if(a<1)sphere{W
+<2,0>2 2pigment{color rgb<a*10A 10>}}#end#end#if(N>3)J(int(N/3)A+1)#end#
end blob{J(29229171 0)threshold 1translate<-6 3>}/******Jan Walzer******/

Post a reply to this message