 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Dave Dunn" <poi### [at] aol com> 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
|
|
| |
| |
|
|
|
|
| |
|
|
