The lines:

      #version official 3.1
      T_Stone9
      #version unofficial MegaPov 0.7; // go back to using filtered layers

no longer show the correct interpretation of the stone texture.  It worked
fine in 0.6 (with the corresponding constant in the last line).

Post a reply to this message

I was going to mention it before but didn't think it necessary (or did I? My
short-term memory is bad).
I'll guess that you might be able to use the version directives before and
after the include file instead of the texture only.  I just tried it on the
texture like you did and figured it wasn't going to work anyway.
Well, nevermind, it doesn't help.  Tried both places and one or the other,
it didn't work out.
Wonder what happened between 0.6a and 0.7?

Bob H.

"John M. Dlugosz" <joh### [at] dlugoszcom> wrote in message
news:3aabee7f@news.povray.org...
> The lines:
>
>       #version official 3.1
>       T_Stone9
>       #version unofficial MegaPov 0.7; // go back to using filtered layers
>
> no longer show the correct interpretation of the stone texture.  It worked
> fine in 0.6 (with the corresponding constant in the last line).
>
>
>
>

Post a reply to this message

In article <3aabee7f@news.povray.org> , "John M. Dlugosz" 
<joh### [at] dlugoszcom> wrote:

> The lines:
>
>       #version official 3.1
>       T_Stone9
>       #version unofficial MegaPov 0.7; // go back to using filtered layers
>
> no longer show the correct interpretation of the stone texture.  It worked
> fine in 0.6 (with the corresponding constant in the last line).

I guess this is caused by the "noise" changes.

The workaround is not to use #version more than once per scene.  The
behavior of #version when used more than once regarding render-time
differences between multiple official and/or unofficial versions is
undefined.  The #version directive should be the first statement in any
.pov file, and later switching should be avoided.


     Thorsten

Post a reply to this message

"Thorsten Froehlich" <tho### [at] trfde> wrote...
>
> I guess this is caused by the "noise" changes.

That is positively correct.  :-)

> The workaround is not to use #version more than once per scene.  The
> behavior of #version when used more than once regarding render-time
> differences between multiple official and/or unofficial versions is
> undefined.  The #version directive should be the first statement in any
> .pov file, and later switching should be avoided.

Actually, using #version in mulitple places is well defined in MegaPov.

Under these circumstances, it is a good idea to put "#version unofficial
MegaPov 0.4" as the last line in the file.

"#version unofficial" has two effects in MegaPov:

1) It affects parsing
Whichever version is in effect at any specific point in the file will
determine how that file is parsed.  Also, "#version official" can be used to
turn off the parsing of unofficial features.  It is at parse time where
"rgbf" is converted to "rgbt", so if unofficial features are turned off at
parse time, textures will be converted to so that the modified rendering
engine will render them the same way the official engine renders them.

2) It affects rendering
After parsing is done, POV will remember the last "#version" directive that
it came across.  This is used for two backwards-compatibility issues:
a) normal - If the unofficial version is below 0.3, MegaPov will use the old
(buggy) code for perturbing surface normals.
b) noise - If the unoffical version is below 0.5, MegaPov will use the old
(buggy) code for computing fractal noise.

-Nathan

Post a reply to this message

> 2) It affects rendering
> After parsing is done, POV will remember the last "#version" directive
that
> it came across.  This is used for two backwards-compatibility issues:
> a) normal - If the unofficial version is below 0.3, MegaPov will use the
old
> (buggy) code for perturbing surface normals.
> b) noise - If the unoffical version is below 0.5, MegaPov will use the old
> (buggy) code for computing fractal noise.

Thanks for the explaination of what the "last" one does.  What we need,
though, is to have parse-time selection of the noise function on a
per-texture basis, so Miller's classy stuff still works.  I suppose that
could be done by having two different function "objects" and automatically
choose one or the other at parse time, where one is the old way and one is
the new.

The reason it looked like it broke in 0.7 is because I updated the #version
line.  It =was= a 0.4.  (the change, Nathan points out in another note,
happened in 0.5)

--John

Post a reply to this message

In article <3aad6e55$1@news.povray.org> , "John M. Dlugosz" 
<joh### [at] dlugoszcom> wrote:

> Thanks for the explaination of what the "last" one does.  What we need,
> though, is to have parse-time selection of the noise function on a
> per-texture basis, so Miller's classy stuff still works.  I suppose that
> could be done by having two different function "objects" and automatically
> choose one or the other at parse time, where one is the old way and one is
> the new.

The correct solution is to abandon texture using the old, broken noise
function and adjust textures accordingly.  You should not count on
POV-Ray supporting every broken feature forever.  Future versions of
POV-Ray could just change the default textures to compensate for the
changed noise functions and then, while not looking identical, the
texture will look similar.  Of course, this is a one-time inconvenience,
but fixing it once properly is far better than just patching around it.


     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

> The correct solution is to abandon texture using the old, broken noise
> function and adjust textures accordingly.  You should not count on
> POV-Ray supporting every broken feature forever.  Future versions of
> POV-Ray could just change the default textures to compensate for the
> changed noise functions and then, while not looking identical, the
> texture will look similar.  Of course, this is a one-time inconvenience,
> but fixing it once properly is far better than just patching around it.

Is Mike Miller still around?  The T_Stone9 texture isn't just some slight
difference -- the whole apparance seems to require the old function.  If you
render Stones1.pov from the scenes directory, you'll see that =most= of the
textures change in character or have utterly different apparances.  The demo
doesn't show everything, either, since the swatches are so small.  But they
introduce patterns that are apparant in larger surfaces.

Is it *possible* to port these textures over?  This is not a slight roundoff
problem or a "bug" -- this is the fractal function that they were designed
for!  Just like we have several to choose from now, we still need the old
one.  Maybe that's not what the function was meant to be when it was
written, but what it *is* was appreciated by some and used as such.

For comparison, why hasn't anyone adjusted the supplied textures to use
gamma 1?  Changing the colors in the map is not enough (I've tried) -- it
changes the transparancy too, so they mix and layer differently.  Everyone
still uses "assumed_gamma 2.2" in their scenes even though the documentation
says not to do that anymore, and has for years.

If you're going to drop a feature while calling it a "bug", you must update
the include files first!  Otherwise it's no fix.  If someone wants to
"change the default textures...look similar (not identical)" that's fine,
and I'll use it.  But I think keeping the old noise function around is less
work, and something we can do *now*.

--John

Post a reply to this message

In article <3aaebef8@news.povray.org> , "John M. Dlugosz" 
<joh### [at] dlugoszcom> wrote:

> If you're going to drop a feature while calling it a "bug", you must update
> the include files first!  Otherwise it's no fix.  If someone wants to
> "change the default textures...look similar (not identical)" that's fine,
> and I'll use it.  But I think keeping the old noise function around is less
> work, and something we can do *now*.

The POV-Team does _not_ and never has officially supported or endorsed
MegaPOV.  For POV-Ray 3.5 we will surely make an attempt to supply
compatible textures, but for now when using MegaPOV keep in mind that
the include files you are using are for POV-Ray 3.1, not MegaPOV!


       Thorsten


____________________________________________________
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

John M. Dlugosz wrote in message <3aaebef8@news.povray.org>...

>Is it *possible* to port these textures over?  This is not a slight
roundoff
>problem or a "bug" -- this is the fractal function that they were designed
>for!  Just like we have several to choose from now, we still need the old
>one.  Maybe that's not what the function was meant to be when it was
>written, but what it *is* was appreciated by some and used as such.


To port color_maps/pigment_maps/whatever_maps from the old (clipped) noise3D
to the new (scaled) version, divide all map indices by 2 and add 0.25.  For
example,

color_map{
    [.2 rgb 1]
    [.5 rgb <1,1,0>]
    [.7 rgb <0,0,1>]
}

becomes

color_map{
    [.35 rgb 1]
    [.5  rgb <1,1,0>]
    [.6  rgb <0,0,1>]
}

--
Mark

Post a reply to this message

> The POV-Team does _not_ and never has officially supported or endorsed
> MegaPOV.  For POV-Ray 3.5 we will surely make an attempt to supply
> compatible textures, but for now when using MegaPOV keep in mind that
> the include files you are using are for POV-Ray 3.1, not MegaPOV!

So you're saying that in POV 3.5, you'll either not apply this particular
"fix", or you will indeed update the *.inc files to match?  That's good to
know.

In the mean time, I'm discussing MegaPOV and trying to lobby the maintainer
to support this better by pointing out the need.  This is the
unofficial.patches newsgroup, you know.

--John

Post a reply to this message