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