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