I've been using the official release of POV, partially because I felt it
was more stable, and partially because I don't have a connection to the
net from home - if I download a new copy, I then split it to x number of
floppies, and sneakernet it to my home machine.  

But I keep hearing about things that can be done in Mega-Pov that can't
be done in the official version.

So, the question is - how many people use it?  Do you use both? Or
gravitate towards one or the other?  Are the extensions in Mega-Pov used
often?  

I'm trying to decide if I should go with Mega-Pov or just wait for the
official V3.5? 

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

Tom A. <tar### [at] my-dejacom> wrote:
: But I keep hearing about things that can be done in Mega-Pov that can't
: be done in the official version.

  On the other hand there are things that can be done with 3.5 that can't
be done with megapov.

: I'm trying to decide if I should go with Mega-Pov or just wait for the
: official V3.5? 

  I would wait for 3.5 and then the megapov made from that.

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

Tom A. <tar### [at] my-dejacom> wrote in message
news:3C5### [at] my-dejacom...

I'm using 3.5 now. I wish that 3.5 had MegaPov's solid mesh feature,
however.
Certainly you have a CD burner wherever you have an internet connection. If
not, remind me and I will burn a CD for you when 3.5 official release comes
out. 3.5 is worth the wait if only for the awesome documentation.

 -Shay

Post a reply to this message

On Mon, 28 Jan 2002 15:13:00 -0600, Shay wrote:
> 
> I'm using 3.5 now. I wish that 3.5 had MegaPov's solid mesh feature,
> however.

Have you tried intersecting a mesh in 3.5?

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

I tried and failed. I am sure that my mesh was closed.
I will definitely give it another shot if it is supposed to work. I was
intersecting with a blob. I'm not sure if this makes a difference or not.

Ron Parker <ron### [at] povrayorg> wrote in message
news:slr### [at] fwicom...

Post a reply to this message

On Mon, 28 Jan 2002 15:52:33 -0600, Shay wrote:
> I tried and failed. I am sure that my mesh was closed.
> I will definitely give it another shot if it is supposed to work. I was
> intersecting with a blob. I'm not sure if this makes a difference or not.

It's not necessarily supposed to work, but the code was never exactly taken
out, either.

-- 
#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 the other hand there are things that can be done with 3.5 that can't
> be done with megapov.
like?

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 have found MegaPOV and its related patches to be stable.  The beta
versions of 3.5 promises that it will be very powerful when the kinks are
out.  Very fast and flexible with most of the Mega features.  I still use
Mega when I need stable splines or want to play with the cloth patch or the
renderman patch.  Otherwise I use 3.5 beta.  I have used the Mega  patch of
3.1  since forever, whether I actually used  the added feature set or not.
There is no reason to distrust it and it is a fast download. And it is not a
oneway street.  With Mega installed you can still start up the 3.1 engine.
You don't have to be a technical he-man  to use either Megapov or 3.5 beta.
Believe me, I should know.

-Jim

"Tom A." wrote:

> I've been using the official release of POV, partially because I felt it
> was more stable, and partially because I don't have a connection to the
> net from home - if I download a new copy, I then split it to x number of
> floppies, and sneakernet it to my home machine.
>
> But I keep hearing about things that can be done in Mega-Pov that can't
> be done in the official version.
>
> So, the question is - how many people use it?  Do you use both? Or
> gravitate towards one or the other?  Are the extensions in Mega-Pov used
> often?
>
> I'm trying to decide if I should go with Mega-Pov or just wait for the
> official V3.5?
>
> Thanks!
> --
> 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

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.

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

MegaPOV:
Fixes many 3.1 bugs.
Not compatible with official versions.
Adds many new features, which may or may not be useful to you.

POV 3.5:
Even more bug fixes than MegaPOV.
Adds the most complete features of MegaPOV, and often with a better 
syntax and implementation.
It's official.

The biggest features of MegaPOV, photon mapping, new media methods, 
isosurfaces, etc, have made it into POV 3.5. MegaPOV itself is a bit 
outdated, it won't be updated until after 3.5 is finished, and probably 
not until most of the authors update their patches.

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

>   Like pattern functions, fractal patterns with exponents >4, transmit
Aren't pattern functions part of MegaPov?

> behaviour outside the range 0-1,
they have changed the transmit behaviour outside the range 0-1 ???
:(
I liked it the way it was...

> support for reading JPEG and TIFF,
useful, but not reason enough to use 3.5 instead of MegaPov.  Not for me at least.

> unicode support, etc.
again: might be useful, but to me not reason enough to use 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

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

> >   Like pattern functions, fractal patterns with exponents >4, transmit
> Aren't pattern functions part of MegaPov?

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.

Also, check out the additions to the standard includes...

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

Christopher James Huff wrote:

> Adds many new features, which may or may not be useful to you.

Is this some "insider" joke? 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):

MegaPOV 0.7
Reflection blur - I've seen enough workarounds in these groups to know this
is needed.
Motion blur - okay, flawed, but certainly useful; I use it often.
Blinn microfacets - superior to specular highlights in every way.
Heightfield_height_at (no way trace works better on hfs, sorry).
Text object enhancements (why use a macro when you can just use this?).
Ini_option (why in the world was this removed?).
Mesh Type 2 (parsed much faster and came out smoother).
Glows (Ahem, Chris, didn't you write this one? ; } ).

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

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

OK, there are a few things I like about 3.5 Beta+, like the easier
dispersion and improved functions (especially for isos), but, let's face
it, MegaPOV in general is more powerful. The true breakthroughs in 3.5 are
in the superior interface, with enhanced insert menu features, accessible
command line and better error control, but one could easily load MegaPOV
into the bin folder. That is, if you didn't have to keep downloading and
installing the new betas.

Post a reply to this message

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

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

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

> MegaPOV 0.7
> Reflection blur - I've seen enough workarounds in these groups to know this
> is needed.
I don't use MegaPOV's reflection blur anymore since I know that the "workarounds"
(using
an average texture_map) gives much better results.  Only problem is when you're using
layered textures...

> Motion blur - okay, flawed, but certainly useful; I use it often.
The only time I really wanted motionblur, the effects were really ugly. :(

> Blinn microfacets - superior to specular highlights in every way.
never used them actually...

> Heightfield_height_at (no way trace works better on hfs, sorry).
trace is a more general approach.  I never used heightfield_height_at
Might be because it's longer than trace :)

> Ini_option (why in the world was this removed?).
ini-options have nothing to do with the scene-file.  They should indeed be separated.

> Mesh Type 2 (parsed much faster and came out smoother).
mesh2 ?  There's no mesh2 in POV3.5 ??
:(

> Glows (Ahem, Chris, didn't you write this one? ; } ).
I don't think glows are really useful.  They would be if you could block them with
other
objects.

> POVMan
yeah, POVMan rules! :)

> ClothSim (How is 3.5 better than this?)
never used it, but you're absolutely right: cloth simulation is a nice thing to have
:)

> Renderman-like Shaders (See falling star animations at p.b.a)
tnx for mentioning my animation :)
And again: POVMan rules!!! :)

> MegaPOV Plus
hmmm, what's new in MegaPOV Plus?

> OK, there are a few things I like about 3.5 Beta+, like the easier
> dispersion and improved functions (especially for isos), but, let's face
> it, MegaPOV in general is more powerful. The true breakthroughs in 3.5 are
> in the superior interface, with enhanced insert menu features, accessible
> command line and better error control, but one could easily load MegaPOV
> into the bin folder. That is, if you didn't have to keep downloading and
> installing the new betas.
I almost never use the insert menu, and I'm happy with the ini-settings in POV-Ray
3.1...

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?

Maybe I'm just tired.  I've been awake for 17 hours :)

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

"Zeger Knaepen" <zeg### [at] studentkuleuvenacbe> wrote in message
news:3c561a65$1@news.povray.org...
> 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?

POV3.5's a big improvement, IMHO.  I no longer even touch MegaPOV or 3.1 :)

...Chambers

Post a reply to this message

"Zeger Knaepen" <zeg### [at] studentkuleuvenacbe> wrote in message
news:3c560caf@news.povray.org...
> >   Like pattern functions, fractal patterns with exponents >4, transmit
> Aren't pattern functions part of MegaPov?
>
> > behaviour outside the range 0-1,
> they have changed the transmit behaviour outside the range 0-1 ???
> :(
> I liked it the way it was...
>
> > support for reading JPEG and TIFF,
> useful, but not reason enough to use 3.5 instead of MegaPov.  Not for me at
least.
>
> > unicode support, etc.
> again: might be useful, but to me not reason enough to use 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
>

object{MyObject finish{reflection{<.1,.2,.3>,<.5,.6,.7> falloff 3}}}

MegaPov wouldn't parse a scene in which I used variable reflections...


Does MegaPov have average patterns? I don't remember any, but I've never really
fully gone through the docs either.

--
#local X=20*<-2,2,5>;sphere_sweep{catmull_rom_spline 6<-8,-8>1<-8,-8>1<-8,8>1<
8,-8>1<8,8>1<8,8>1translate 20*z pigment{gradient z scale 3color_map{[0rgb<0,9
,18>][1rgb 0]}}}#local K=2*z*X-X;#local R=seed(clock);blob{#while(K.x>X.x)
#local N=X+<rand(R)rand(R)1>/3;#local X=(vlength(N-K)<vlength(X-K)?N:2*X-N);
sphere{X,1,1rotate z*90}sphere{X,1,1}#end pigment{rgbt 1}interior{media{//Nekar
emission<2,4,5>*5}}hollow scale.05}//   http://nekar_xenos.tripod.com/metanoia/


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.317 / Virus Database: 176 - Release Date: 2002/01/21

Post a reply to this message

In article <3c561a65$1@news.povray.org> , "Zeger Knaepen" 
<zeg### [at] studentkuleuvenacbe> 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.

To make one thing absolutely clear, and this is not only to you but also some
others in this thread:
You have no, I repeat no, business to tell us how we spend our time!!!  If we
would make a POV-Ray 3.6, 3.7, 3.8 and 3.9, it would be our decision to do so
and you would have no business telling us to not to do it!

The POV-Team is not going to justify any design decisions for POV-Ray 3.5.
There is a reason for everything, and if you are not willing to understand
this, it is your problem alone.  If you don't like POV-Ray 3.5 fine, then
don't use it and quit whining and wasting the time of everybody else!

Thank you for your attention,

    Thorsten Froehlich

____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

On Tue, 29 Jan 2002 04:25:26 +0100 Zeger Knaepen wrote:

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

>> unicode support, etc.
>again: might be useful, but to me not reason enough to use 3.5

  How about if we paid you? ;)

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

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

Uh oh.. Such comments are not gladly seen by the Pov-team, and I hope you
understand why.. Pov3.5 is their baby.. Well, I think ... surely Pov3.5 is
not a waste of time, you see, it cleans up all the features in Megapov. The
coders do their best to clean Povray - both the source code and SDL - so
that future coders will be able to understand what's going on in Pov and
easily move forwards from that point, to make further improvements.

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.

> Maybe I'm just tired.  I've been awake for 17 hours :)

Okay, then I would definetely be tired.. Hope you had some rest, when you
read this..  :o)  Peace..

Regards,
Hugo

Post a reply to this message

I still use MegaPOV at the minute, but that's only because I'm waiting
for the final release (I just have a thing about beta software). I'm
kinda disappointed that mesh2's weren't added to POV3.5, but I've been
thinking about a #macro that can turn triangle data into a solid object
anyway, so...

On Tue, 29 Jan 2002 04:25:26 +0100 Zeger Knaepen wrote:
>hmmm, I've never used standard includes... So I'm not really interested in the
additions

You should try it sometime. I still find interesting things in the 3.1
stincs occaisonally.

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

Post a reply to this message

"Zeger Knaepen" <zeg### [at] studentkuleuvenacbe> wrote in message
news:3c561a65$1@news.povray.org...
>
> 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?
>
> Maybe I'm just tired.  I've been awake for 17 hours :)
>

Hmm, is this a valid arguement? 4.0 may be a rewrite, but I wouldn't imagine
that that means throwing out everything that has proceeded it. More a question
of implementing the algorithms in a different framework.

Besides, what's there to complain about? Jam today and tomorrow suits me
fine....

Post a reply to this message

In article <3C56867C.BB10902E@namtar.qub.ac.uk> , Grey Knight 
<s16### [at] namtarqubacuk>  wrote:

>  I'm
> kinda disappointed that mesh2's weren't added to POV3.5,

Where and how did you get this idea?  You obviously never even bothered to
check either the program or the documentation 8which is available online after
all).  It is even listed on the Windows and Mac download pages as feature:
"More efficient mesh type".

    Thorsten

In the docs:
<http://www.povray.org/working-docs/id000017.html#2_6_6>
<http://www.povray.org/working-docs/id000165.html#6_5_2_4>


____________________________________________________
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

Sorry, I just checked that. Someone said that solid meshes weren't being
added (although the official page says they are being "considered"), and
I, having not really used the MegaPOV meshes much assumed they meant
mesh2's. I think in future I'll double-check what I'm talking about
before I post; this is embarassing!

Thorsten Froehlich wrote:
> Where and how did you get this idea?  You obviously never even bothered to
> check either the program or the documentation which is available online after
> all).  It is even listed on the Windows and Mac download pages as feature:
> "More efficient mesh type".

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

Post a reply to this message

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

If you just don't use the features that are new or strongly improved in
3.5 there is of course no point, but for most people this won't be a valid
argument.  

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
much more limited functions.  

I totally understand if people don't use the current betas because they
don't want to regularly download large packages, don't want to have
problems with the various bugs still present and don't want to start
learning a syntax still subject to changes, but just saying Povray 3.5 has
no worthy improvements does not seem a very qualified opinion to me.

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

Zeger Knaepen <zeg### [at] studentkuleuvenacbe> wrote:
:>   Like pattern functions, fractal patterns with exponents >4, transmit
: Aren't pattern functions part of MegaPov?

  There are only pigment functions, which is a bit different beast.

  Note that you can also use pigment functions in pov3.5, but it's more
versatile: You can not only get the gray value of the pigment as its value,
but also any of the color channels or even a hf value.

  I also forgot to mention that in megapov you can only have 3 parameters to
functions, while in pov3.5 you can have any number of parameters from 1 to
some bigger value (which I don't remember). This means that you can do things
like, for example:

#declare MyFunction = function(x,y,z,s) { s*(sin(x)*sin(y)*sin(z))^2 }

and then use it like for example:

  pigment
  { function { MyFunction(x,y,z,(x+y)^2) }
    color_map { [0 rgb 0][.5 rgb x][1 rgb 1] }
  }

:> behaviour outside the range 0-1,
: they have changed the transmit behaviour outside the range 0-1 ???
: :(
: I liked it the way it was...

  Really? Do you know how it was previously? It was pretty illogical and didn't
make much sense.

:> support for reading JPEG and TIFF,
: useful, but not reason enough to use 3.5 instead of MegaPov.  Not for me at least.

  If you are ever going to use imported 3DS files, you'll probably appreciate
the JPEG support, as 3DS textures are often given in JPEG format.

  Other big advantages include the new windows editor, which is much nicer,
the greatly improved documentation and the greatly improved include files.

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

Dave Dunn <poi### [at] aolcom> wrote:
: Reflection blur - I've seen enough workarounds in these groups to know this
: is needed.

  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.

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

  I don't understand why not.
  Tracing is also a lot more versatile than height_at, as you can trace also
from other directions than just directly from above (for example suppose that
you want to simulate meteorites falling and creating holes on a heightfield
at an angle of 60 degrees). Tracing also works if you have a union of a
heightfield with other primitives, which is just not possible with height_at.

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

  Why not?

  I have explained several times why using macros is better than making an
internal feature (if the macro is not annoyingly slower). Macros should always
be preferred to internal support whenever possible.
  Macros are more versatile (internal support is fixed and rigid), changeable
(you can't change internal support) and you can learn from macros (they are
much more readable than reading the povray source code) and make your own
macros based on it.

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

  Because it breaks the boundaries of what a scene file should be able to
do. It's up to the user to specify rendering settings (such as image
resolution), not the scene file.
  Suppose that you have a really huge scene file with an extremely obfuscated
ini_option which sets the resolution of the rendering to 500000x500000 pixels.
Happy swapping then...

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

  Uh? You mean pov3.5 has no mesh2?
  And what do you mean "smoother"?

: OK, there are a few things I like about 3.5 Beta+, like the easier
: dispersion and improved functions (especially for isos), but, let's face
: it, MegaPOV in general is more powerful.

  Not that more powerful. Most of the things you said made just no sense.

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

Christoph Hormann <chr### [at] gmxde> wrote:
: I totally understand if people don't use the current betas because they
: don't want to regularly download large packages

  Honestly speaking, I don't.
  Installing the newer beta over the older one is a question of a couple
of minutes. I don't have any trouble with that.
  (Granted, some settings are reset to their defaults in winpov when
installing the new beta, and you have to set them back to what they were,
but fortunately at least the codemax settings (eg. syntax coloring) is
preserved.)

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

> >> unicode support, etc.
> >again: might be useful, but to me not reason enough to use 3.5
>   How about if we paid you? ;)
kewl, would you do that? :)

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

> object{MyObject finish{reflection{<.1,.2,.3>,<.5,.6,.7> falloff 3}}}
object{MyObject finish {reflection_min <.1,.2,.3> reflection_max <.5,.6,.7>
reflection_falloff 3}}}

> MegaPov wouldn't parse a scene in which I used variable reflections...
it would, but the syntax is different :)

> Does MegaPov have average patterns? I don't remember any, but I've never really
> fully gone through the docs either.
Sure, average patterns are allready included in POV-Ray  3.0 if I'm right.

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

"Warp" <war### [at] tagpovrayorg> wrote in message news:3c569cc1@news.povray.org...
> Christoph Hormann <chr### [at] gmxde> wrote:
> : I totally understand if people don't use the current betas because they
> : don't want to regularly download large packages
>
>   Honestly speaking, I don't.

?

Over a slow modem, the d/l can be quite demanding - or did you misunderstand?

Post a reply to this message

>   There are only pigment functions, which is a bit different beast.
In what way?  As I see it, you can do a lot more with pigments than with patterns.

>   Note that you can also use pigment functions in pov3.5, but it's more
> versatile: You can not only get the gray value of the pigment as its value,
> but also any of the color channels or even a hf value.
Ok, that's a good thing indeed.

>   I also forgot to mention that in megapov you can only have 3 parameters to
> functions, while in pov3.5 you can have any number of parameters from 1 to
> some bigger value (which I don't remember). This means that you can do things
> like, for example:
>
> #declare MyFunction = function(x,y,z,s) { s*(sin(x)*sin(y)*sin(z))^2 }
>
> and then use it like for example:
>
>   pigment
>   { function { MyFunction(x,y,z,(x+y)^2) }
>     color_map { [0 rgb 0][.5 rgb x][1 rgb 1] }
>   }
cool!
Now add the missing features from MegaPov, and i'm all for it! :)

> :> behaviour outside the range 0-1,
> : they have changed the transmit behaviour outside the range 0-1 ???
> : :(
> : I liked it the way it was...
>   Really? Do you know how it was previously? It was pretty illogical and didn't
> make much sense.
actually it seemed to make a lot of sense to me.  I don't know exactly how it worked,
but
I do know that I used it once to create a special effect.

> :> support for reading JPEG and TIFF,
> : useful, but not reason enough to use 3.5 instead of MegaPov.  Not for me at least.
>   If you are ever going to use imported 3DS files, you'll probably appreciate
> the JPEG support, as 3DS textures are often given in JPEG format.
Hmmm, I'm one of those who makes everything himself.  I don't use 3DS-files, because I
don't have 3DS :)

>   Other big advantages include the new windows editor, which is much nicer,
> the greatly improved documentation and the greatly improved include files.
A good POVver no longer needs the documentation :)
And again: I never used the include files bundled with POV-Ray.
And what's so special about the new editor, actually?

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

Zeger Knaepen <zeg### [at] studentkuleuvenacbe> wrote:
: And again: I never used the include files bundled with POV-Ray.

  Because there wasn't anything interesting in them, until now.

: And what's so special about the new editor, actually?

  Read the first chapter of the documentation.

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

> To make one thing absolutely clear, and this is not only to you but also some
> others in this thread:
> You have no, I repeat no, business to tell us how we spend our time!!!  If we
> would make a POV-Ray 3.6, 3.7, 3.8 and 3.9, it would be our decision to do so
> and you would have no business telling us to not to do it!
wow, sorry, I didn't mean to offend you or anyone else.  I never said you shouldn't
spend
time on POV3.5, I only said *I* wouldn't do it, and (I quote):"IMHO it's a waste of
time"
Mind the IMHO-part, I don't write the H because it's supposed to be there, but because
I
really think my opinion is humble.  I know I have no business to tell you how to spend
your time.  But I never did so and I never will.

> The POV-Team is not going to justify any design decisions for POV-Ray 3.5.
> There is a reason for everything, and if you are not willing to understand
> this, it is your problem alone.  If you don't like POV-Ray 3.5 fine, then
> don't use it and quit whining and wasting the time of everybody else!
I don't know whether I like POV3.5 or not, I never tried it.
And if I'm wasting someone's time: I'm sorry, that was never my intention.  I was just
saying what's on my mind, and I think if everyone did this more often, the world would
be
a beter place :)

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

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

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)

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

> Hmm, is this a valid arguement? 4.0 may be a rewrite, but I wouldn't imagine
> that that means throwing out everything that has proceeded it. More a question
> of implementing the algorithms in a different framework.
maybe, I don't know enough about C and C++.  Maybe they can just copy/paste most of
the
code, and in that case I can understand why they made POV3.5.

> Besides, what's there to complain about? Jam today and tomorrow suits me
> fine....
I'm not complaining, I'm just telling you what I think about POV3.5.  If you don't
like my
opinion: have your own one :)

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

> : And what's so special about the new editor, actually?
>   Read the first chapter of the documentation.
hmmm, ok, I will.

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

Zeger Knaepen <zeg### [at] studentkuleuvenacbe> wrote:
: no, because I like to make everything myself.

  Why?
  If I want to, for example, reorient an object from one axis to another,
I'm not interested in calculating the transformations needed for that when
I can easily use the standard macro which comes with pov3.5. It saves me
time and trouble.

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

> : no, because I like to make everything myself.
>   Why?
it's more fun, and the results are more your own.  Of course I don't make everything
myself, and the example you give below is one of the things I use other people code
for.
So I'll probably like POV3.5's include files :)

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

Zeger Knaepen <zeg### [at] studentkuleuvenacbe> wrote:
: it's more fun,

  Not in the long run.
  If you find yourself using a special feature over and over again, you
probably will make your own include file in order to avoid writing the same
thing many times. This is not much different from just using a standard include
file.

: and the results are more your own.

  Well, in an extreme case you shouldn't use povray at all then, but write
your own raytracer. Then the results will really be your own.

  Why is it ok to use 'rotate' or 'scale', but it's not ok to use
'Reorient_Trans' just because it's in an include file instead of being an
internal keyword? I don't understand.
  If 'Reorient_Trans' was in internal feature instead of being a macro, would
it then be ok to use it? Why? What's the difference?

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

> : it's more fun,
>   Not in the long run.
>   If you find yourself using a special feature over and over again, you
> probably will make your own include file in order to avoid writing the same
> thing many times. This is not much different from just using a standard include
> file.
but you have written it yourself in that case.  That's what matters to me.  And if you
write things yourself, you have absolute comprehension of the code (probably anyway),
and
that helps when using it.

> : and the results are more your own.
>   Well, in an extreme case you shouldn't use povray at all then, but write
> your own raytracer. Then the results will really be your own.
I know :)
But that's a little too extreme, even for me :)

>   Why is it ok to use 'rotate' or 'scale', but it's not ok to use
> 'Reorient_Trans' just because it's in an include file instead of being an
> internal keyword? I don't understand.
it is ok, like I said.  I was more talking about textures and things like that.  Those
are
things I rather make myself.

>   If 'Reorient_Trans' was in internal feature instead of being a macro, would
> it then be ok to use it? Why? What's the difference?
there is no difference.  In the contrary: it's better when things are macros, so I
don't
have to download the source to see how it works.

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

> >   Why is it ok to use 'rotate' or 'scale', but it's not ok to use
> > 'Reorient_Trans' just because it's in an include file instead of being an
> > internal keyword? I don't understand.
> it is ok, like I said.  I was more talking about textures and things like that. 
Those are
> things I rather make myself.

I think I begin to see one of his (many) points; I hardly ever use
colors.inc anymore

That boy has more points than a line!

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

Post a reply to this message

I've never been good at expressing myself.

But whatever I say: if you can interprete it in 2 or more ways, I always meant to say
the
least offending of them.
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)

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

Grey Knight <s16### [at] namtarqubacuk> wrote:
: I think I begin to see one of his (many) points; I hardly ever use
: colors.inc anymore

  This is exactly what I meant with "there wasn't anything interesting in
the standard include files".
  Prior to 3.5, the standard include files were not very useful. They contained
things that weren't really worth the trouble of writing the #include line.

  However, 3.5 has changed this completely. Now the standard include file
set is incredibly more powerful, versatile and useful.

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

> :> behaviour outside the range 0-1,
> : they have changed the transmit behaviour outside the range 0-1 ???
> : :(
> : I liked it the way it was...
>   Really? Do you know how it was previously? It was pretty illogical and didn't
> make much sense.
hmmm, weird, I tried it, and it is indeed an illogical behaviour.
Strange, cause I thought I used it once as a special effect and it worked exactly the
way
I supposed it would...

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

"Zeger Knaepen" <zeg### [at] studentkuleuvenacbe> wrote in message
news:3c56a307$1@news.povray.org...
> 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)
>
> cu!

The POV Team has made it very clear that they wanted to incorporate certain
features (which everybody liked) into POV-Ray in a clean, efficient manner.
To hear them write about it, the code in Mega POV is literally a wasteland
of half-finished patches and undocumented shortcuts.  When they decided to
incorporate these features into the official compile, most of them had to
have their syntax reworked, and have their code rewritten, which is a lot of
work.  They felt that actually getting these features into POV ~first~ was
more important than the C++ rewrite that 4.0 seems to be.  Personally, I'm
just glad I've got any version of POV - Great job, Team!

...Chambers

Post a reply to this message

Warp wrote:

>   Note that you can also use pigment functions in pov3.5, but it's more
> versatile: You can not only get the gray value of the pigment as its value,
> but also any of the color channels or even a hf value.

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.

Please note this isn't a complaint or (Heaven forbid!) a feature request 
- just a small requiem for a useful feature fallen by the wayside ...

Bye for now,
	Mike Andrews.

Post a reply to this message

> The POV Team has made it very clear that they wanted to incorporate certain
> features (which everybody liked) into POV-Ray in a clean, efficient manner.
> To hear them write about it, the code in Mega POV is literally a wasteland
> of half-finished patches and undocumented shortcuts.  When they decided to
> incorporate these features into the official compile, most of them had to
> have their syntax reworked, and have their code rewritten, which is a lot of
> work.  They felt that actually getting these features into POV ~first~ was
> more important than the C++ rewrite that 4.0 seems to be.  Personally, I'm
> just glad I've got any version of POV - Great job, Team!
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.

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

Ben Chambers <bdc### [at] yahoocom> wrote:
: The POV Team has made it very clear that they wanted to incorporate certain
: features (which everybody liked) into POV-Ray in a clean, efficient manner.
: To hear them write about it, the code in Mega POV is literally a wasteland
: of half-finished patches and undocumented shortcuts.  When they decided to
: incorporate these features into the official compile, most of them had to
: have their syntax reworked, and have their code rewritten, which is a lot of
: work.  They felt that actually getting these features into POV ~first~ was
: more important than the C++ rewrite that 4.0 seems to be.  Personally, I'm
: just glad I've got any version of POV - Great job, Team!

  These are the reason which also I think that pov3.5 is a superb work.

  Also remember that being an official version gives the program certain
status. Not all people want or like to use third-party programs and patches
but only officially distributed versions and this is understandable.

  Besides, pov3.5 is a really good testbed for pov4. Really many things have
been developed and implemented in 3.5 that might not have been implemented in
pov4 if 3.5 had not been made. 3.5 gives invaluable experience for the big
work of making pov4.

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

"Zeger Knaepen" <zeg### [at] studentkuleuvenacbe> wrote in message
news:3c56ca96@news.povray.org...
> 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.
>

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.

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

Post a reply to this message