Now that 3.5 is here (kinda) and uses most of the features from MegaPOV,
what plans do people have to patch 3.5? Will there eventually be another
MegaPOV based on the 3.5 source? Will any of the ideas we've seen
touched on but not incorporated into the Megapatch (visibility patterns
for grime and patina, blurred everything-but-reflection, shaders,
translucency, and probably a zillion other things that I forget) be
making a reappearance?

-Xplo

Post a reply to this message

"Xplo Eristotle" <inq### [at] unforgettablecom> wrote :
>
> Now that 3.5 is here (kinda) and uses most of the features from MegaPOV,
> what plans do people have to patch 3.5?

    Good question.

Post a reply to this message

"Bill DeWitt" <bde### [at] cflrrcom> wrote in message
news:3b9a9ea9@news.povray.org...
>
> "Xplo Eristotle" <inq### [at] unforgettablecom> wrote :
> >
> > Now that 3.5 is here (kinda) and uses most of the features from MegaPOV,
> > what plans do people have to patch 3.5?
>
>     Good question.

    Although I imagine if anything is done, it will be after the beta period
is over.

Post a reply to this message

Xplo Eristotle <inq### [at] unforgettablecom> wrote:
: Will there eventually be another MegaPOV based on the 3.5 source?

  That's what Nathan have said.

  In fact, even the idea of not having any 3.5 patches sounds really weird.
Why do you even think like that? Of course there will be 3.5 patches. What
else?

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

"Bill DeWitt" wrote:
> Although I imagine if anything is done, it will be after
> the beta period is over.

Yes, because the source won't be released before then...

But I don't think and I don't hope that *all* features from MegaPov will be
preserved. I think all patched features should be re-evaluated from scratch,
and the obsolete features and those that were left out of POV-Ray 3.5 for
good reasons shouldn't make a re-appearance if it was up to me.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

Warp wrote:
> 
> Xplo Eristotle <inq### [at] unforgettablecom> wrote:
> : Will there eventually be another MegaPOV based on the 3.5 source?
> 
>   That's what Nathan have said.
> 
>   In fact, even the idea of not having any 3.5 patches sounds really weird.
> Why do you even think like that? Of course there will be 3.5 patches. What
> else?

*shrug* Patching seems to have hit a lull. There haven't been any
additions to the Megapatch for a while now, even though I know there are
things out there that are (at the least) WIPs...

I was kind of hoping that the people who are actually working on the
patches would be able to offer some input more specific than "I expect
so". (Although maybe they aren't for fear of being nagged to finish
them. ;)

-Xplo

Post a reply to this message

Xplo Eristotle wrote:

> *shrug* Patching seems to have hit a lull. There haven't been any
> additions to the Megapatch for a while now, even though I know there are
> things out there that are (at the least) WIPs...
> 
> I was kind of hoping that the people who are actually working on the
> patches would be able to offer some input more specific than "I expect
> so". (Although maybe they aren't for fear of being nagged to finish
> them. ;)

Nathan Kopp has made it pretty clear in the last several months that
he will do nothing more with Mega-Pov until POV-Ray v3.5 is released.
Once released then Mega-Pov will be based on the source for v3.5.
Most of the patch writers are aware of this and are also waiting for
v3.5 to be released before continuing.

-- 
Ken Tyler

Post a reply to this message

"Rune" <run### [at] mobilixnetdk> wrote in message
news:3b9ab3e0@news.povray.org...
> But I don't think and I don't hope that *all* features from MegaPov will
be
> preserved. I think all patched features should be re-evaluated from
scratch,
> and the obsolete features and those that were left out of POV-Ray 3.5 for
> good reasons shouldn't make a re-appearance if it was up to me.

I hope that we'll still have (re-evaluated?) post-process, as well as the
ability to use ini_option (something I *really* miss in 3.5).

Andy Cocker

Post a reply to this message

In article <3b9ba3b0$1@news.povray.org> , "Andy Cocker" 
<big### [at] mariner9fsnetcouk> wrote:

> ability to use ini_option (something I *really* miss in 3.5).

This feature has been left for a lot, lot of reasons.  It really doesn't
belong in the scene description and I would guess as it has been left out
intentionally out of 3.5, it won't be in a future MegaPOV either.  Of
course, this is just a guess and it is Nathan's decision what he adds back
and what not.


    Thorsten

Post a reply to this message

"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:3b9bbd47$1@news.povray.org...
> This feature has been left for a lot, lot of reasons.  It really doesn't
> belong in the scene description <snip>

Hmm.. I don't think I agree with you there. Personally, I'd like the option
of using it or not. I prefer to make my scenes 'stand alone', without having
to load an ., and 'ini_option' would be especially useful when 3rd parties
render your scenes, so image size/ratio can be preset. Also, being able to
place the +QR switch in the scene saves a lot of annoying 'no radiosity'
moments!

I think they should have their own block (  ini_settings {}  ) too.

Still, I am resigned to them not being in future versions of megaPOV.

All the best,

Andy Cocker

Post a reply to this message

FWIW, I agree with Andy. I never liked the concept of an external .INI file.
I think all those things should be setable from within the .POV file.

Post a reply to this message

"Tony[B]" wrote:

> FWIW, I agree with Andy. I never liked the concept of an external .INI file.
> I think all those things should be setable from within the .POV file.

Add me to the list. I liked being able to add switches that, for example, set
the quality of the scene based on what was being rendered. Adding a
scene-specific ini file seems to be a step backwards from something so intuitve
and powerful.

Post a reply to this message

Andy Cocker wrote:

> "I hope that we'll still have (re-evaluated?) post-process,

I really hope that they at least keep the "Depth" post-process, as it makes it
very easy to make masks in PhotoShop. I've never found a use for the other
post-process things though.

Post a reply to this message

On Mon, 10 Sep 2001 00:06:01 +0100, Andy Cocker wrote:
>Hmm.. I don't think I agree with you there. Personally, I'd like the option
>of using it or not. I prefer to make my scenes 'stand alone', without having
>to load an ., and 'ini_option' would be especially useful when 3rd parties
>render your scenes, so image size/ratio can be preset. 

This is one of those things we'll never agree on.  Image size, display gamma,
quality, include paths, and those sorts of things are not inherently part of
the scene description.  Those are physical characteristics of the image you're
generating rather than a logical description of what it looks like.  They 
should be separated.

>Also, being able to
>place the +QR switch in the scene saves a lot of annoying 'no radiosity'
>moments!

This problem will be fixed in a better way.

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

"Ron Parker" <ron### [at] povrayorg> wrote in message > This is one of those
things we'll never agree on.  Image size, display gamma,
> quality, include paths, and those sorts of things are not inherently part
of
> the scene description.  Those are physical characteristics of the image
you're
> generating rather than a logical description of what it looks like.  They
> should be separated.

I can see your point, but I still think that everything *should* be
optionally set from within the scene file. I mostly used ini_option to
specify image size, and from an artistic point of view, the image size and
aspect ratio are often intrinsic to the desired final image, and IMO *are*
part of the scene description (coming from the point of view previously
stated, that I like scene files to be self-contained. You press RUN, and you
get the image as I designed it).

In any other 3D package, you save a scene, you save everything, including
all output options. Why should POV prevent this option?

>
> >Also, being able to
> >place the +QR switch in the scene saves a lot of annoying 'no radiosity'
> >moments!
>
> This problem will be fixed in a better way.

That's good news.

All the best,

Andy Cocker

Post a reply to this message

What about image size?  If you want to do a large or small render?
What about quality?  If you want to do a fast render, without AA?
What about output?  If you want to change the output file name, location or
type?
All these things are command line options.  To save typing, you are also
able to specify them in INI files.  It just doesn't make sense to "fix" such
things in the POV file, when they need to be more flexible.  Of course,
you -could- just change the settings in the POV file, but why should you
have to edit every POV file you get if you want to change the output name?

Remember what the INI files are, an extension of the command line and, as
such, extremely useful.

...Chambers

"Dave Dunn" <poi### [at] aolcom> wrote in message
news:3B9C1347.325BB8E8@aol.com...
>
>
> "Tony[B]" wrote:
>
> > FWIW, I agree with Andy. I never liked the concept of an external .INI
file.
> > I think all those things should be setable from within the .POV file.
>
> Add me to the list. I liked being able to add switches that, for example,
set
> the quality of the scene based on what was being rendered. Adding a
> scene-specific ini file seems to be a step backwards from something so
intuitve
> and powerful.
>
>

Post a reply to this message

"Andy Cocker" <big### [at] mariner9fsnetcouk> wrote in message
news:3b9cf784@news.povray.org...
> I can see your point, but I still think that everything *should* be
> optionally set from within the scene file. I mostly used ini_option to
> specify image size, and from an artistic point of view, the image size and
> aspect ratio are often intrinsic to the desired final image, and IMO *are*
> part of the scene description (coming from the point of view previously
> stated, that I like scene files to be self-contained. You press RUN, and
you
> get the image as I designed it).

You are also assuming square pixels.

...Chambers

Post a reply to this message

"Andy Cocker" <big### [at] mariner9fsnetcouk> wrote in message
news:3b9cf784@news.povray.org...
>
> I can see your point, but I still think that everything *should* be
> optionally set from within the scene file. I mostly used ini_option to
> specify image size, and from an artistic point of view, the image size and
> aspect ratio are often intrinsic to the desired final image, and IMO *are*
> part of the scene description (coming from the point of view previously
> stated, that I like scene files to be self-contained. You press RUN, and
you
> get the image as I designed it).
>

    Agreed - a good example is abyss.pov in the 3.5 beta 1 distribution - it
doesn't even have associated .ini file and requires a 'non-standard' aspect
ratio - if it were possible to, at the very least, encode the output
aspect-ratio into the .pov it would prevent the problem I discovered - queue
all the sample scenes and render them at 320x240 and abyss.pov comes out all
squished... IMO, this shouldn't happen...

--
Scott Hill.
Software Engineer.
E-Mail        : sco### [at] innocentcom
Pandora's Box : http://www.pandora-software.com

*Everything in this message/post is purely IMHO and no-one-else's*

Post a reply to this message

"Scott Hill" <nos### [at] nospamthanks> a écrit dans le message news:

>     Agreed - a good example is abyss.pov in the 3.5 beta 1 distribution -
it
> doesn't even have associated .ini file and requires a 'non-standard'
aspect
> ratio - if it were possible to, at the very least, encode the output
> aspect-ratio into the .pov it would prevent the problem I discovered -
queue
> all the sample scenes and render them at 320x240 and abyss.pov comes out
all
> squished... IMO, this shouldn't happen...

There should maybe be a feature (set by default) to automatically adjust
the rendering area to the camera's aspect ratio.  I can't think of any
situation where it would be problematic.

By "rendering area", I mean that, if the camera ratio is 2:1, and the
rendering
resolution is set to 4:3, the resolution should remain intact, but you'll
get
black stripes on top and bottom, like when you watch a 16:9 movie on a 4:3
TV.

Fabien

Post a reply to this message

"Fabien Mosen" <fab### [at] skynetbe> wrote in message
news:3b9efbef@news.povray.org...
> "Scott Hill" <nos### [at] nospamthanks> a écrit dans le message news:
>
> >     Agreed - a good example is abyss.pov in the 3.5 beta 1
distribution -
> it
> > doesn't even have associated .ini file and requires a 'non-standard'
> aspect
> > ratio
>
> There should maybe be a feature (set by default) to automatically adjust
> the rendering area to the camera's aspect ratio.  I can't think of any
> situation where it would be problematic.
>

    Yeah, that sounds like a good solution - I don't know how hard it would
be to implement in POV though...

--
Scott Hill.
Software Engineer.
E-Mail        : sco### [at] innocentcom
Pandora's Box : http://www.pandora-software.com

*Everything in this message/post is purely IMHO and no-one-else's*

Post a reply to this message

Fabien Mosen wrote in message <3b9efbef@news.povray.org>...
>There should maybe be a feature (set by default) to automatically adjust
>the rendering area to the camera's aspect ratio.  I can't think of any
>situation where it would be problematic.


I see one possible problem with this: Suppose I'm rendering on a system with
square pixels, but the image will be displayed on a system with non-square
pixels.  A specific example would be creating a Win98 splash screen.  That
needs to be rendered at 320x400, at a 4:3 aspect ratio.

--
Mark

Post a reply to this message

"Mark Wagner" <mar### [at] gtenet> wrote in message
news:3ba03c9d@news.povray.org...
> Fabien Mosen wrote in message <3b9efbef@news.povray.org>...
> >There should maybe be a feature (set by default) to automatically adjust
> >the rendering area to the camera's aspect ratio.  I can't think of any
> >situation where it would be problematic.
>
> I see one possible problem with this: Suppose I'm rendering on a system
with
> square pixels, but the image will be displayed on a system with non-square
> pixels.  A specific example would be creating a Win98 splash screen.  That
> needs to be rendered at 320x400, at a 4:3 aspect ratio.
>

    Then you unset the 'automatically adjust resolution to fit desired
aspect ratio' option... ;-) Seriously, though, as you point out, there are
situations where this automatic adjustment could be annoying I think these
are far fewer than those situations in which the current settings are
annoying... I don't think Fabien was suggesting doing anything that would
make it impossible to render at non-matching scene and output aspect
ratios...

--
Scott Hill.
Software Engineer.
E-Mail        : sco### [at] innocentcom
Pandora's Box : http://www.pandora-software.com

*Everything in this message/post is purely IMHO and no-one-else's*

Post a reply to this message