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

> 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

Hey, thanks!  I'll give that a try, and if it work out, post a script to
automatically convert stuff.

--John

Post a reply to this message

"John M. Dlugosz" <joh### [at] dlugoszcom> wrote...
> 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.

The fix will be part of POV 3.5, and for the final release, we will update
all necessary INC files.  The textures will probably not be identical,
because the noise changes in POV 3.5 are more extensive even than the
changes made to MegaPov, but we will work to make the textures similar to
their original look.

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

Yes, I see that.  When I originally made this modification, I should have
provided updated INC files (same for the layered texture changes).  I
apologize for that.  Since then, I have gotten more busy with POV 3.5, and I
forgot about providing updated versions.

If anyone here takes the time to update the INC files (both for the layred
texture changes and the noise changes, the POV team would greatly appreciate
it, because we will be able to use that work towards POV 3.5).

-Nathan

Post a reply to this message

> 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

Something is still amiss -- it still looks the "broke" way.  It seems odd
that the range 0-1 in the original maps to 0.25-0.75 in the new, so what
happens when the function returns something outside that range?  It will
give the first or last value in the map.

If the conversion is really supposed to go the other way, I don't know what
to do with the parts of the map that spill outside the legal range.

--John

==========

Changed T_Stone9 as follows: (the marble map is unchanged, the granite map
changed like so)

old:
    #declare T_Grnt9 =
    texture {
    pigment
     {granite
      turbulence 0.6
      color_map
       {[0.000, 0.154   color rgbf <0.894, 0.886, 0.886, 0.000>
                        color rgbf <0.745, 0.745, 0.753, 0.000>]
        [0.154, 0.308   color rgbf <0.745, 0.745, 0.753, 0.000>
                        color rgbf <0.902, 0.902, 0.859, 0.000>]
        [0.308, 0.444   color rgbf <0.902, 0.902, 0.859, 0.000>
                        color rgbf <0.729, 0.706, 0.694, 0.000>]
        [0.444, 0.615   color rgbf <0.729, 0.706, 0.694, 0.000>
                        color rgbf <0.588, 0.592, 0.635, 0.000>]
        [0.615, 0.803   color rgbf <0.588, 0.592, 0.635, 0.000>
                        color rgbf <0.608, 0.616, 0.659, 0.000>]
        [0.803, 1.001   color rgbf <0.608, 0.616, 0.659, 0.000>
                        color rgbf <0.894, 0.886, 0.886, 0.000>]
       }
     }

new:
    ...
       {[0.000, 0.327   color rgbf <0.894, 0.886, 0.886, 0.000>
                        color rgbf <0.745, 0.745, 0.753, 0.000>]
        [0.327, 0.404   color rgbf <0.745, 0.745, 0.753, 0.000>
                        color rgbf <0.902, 0.902, 0.859, 0.000>]
        [0.404, 0.472   color rgbf <0.902, 0.902, 0.859, 0.000>
                        color rgbf <0.729, 0.706, 0.694, 0.000>]
        [0.472, 0.5575   color rgbf <0.729, 0.706, 0.694, 0.000>
                        color rgbf <0.588, 0.592, 0.635, 0.000>]
        [0.5575, 0.6515   color rgbf <0.588, 0.592, 0.635, 0.000>
                        color rgbf <0.608, 0.616, 0.659, 0.000>]
        [0.6515, 0.7505   color rgbf <0.608, 0.616, 0.659, 0.000>
                        color rgbf <0.894, 0.886, 0.886, 0.000>]
       }
     }

Post a reply to this message

"Mark Wagner" <mar### [at] gtenet> wrote g...
> 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

This formula works for bozo, which is a direct use of noise.  However,
granite uses multiple iterations of noise, so this doesn't work.  However,
you can get very close results by simply dividing all indices by 2 and NOT
adding the 0.25.

For granite, the converted example should look like this:
color_map{
    [.1 rgb 1]
    [.25  rgb <1,1,0>]
    [.35  rgb <0,0,1>]
}

I tested this and it works great for T_Grnt9.

Also, make sure to convert rgbf to rgbt if layered textures with filter are
being used (not necessary for T_Grnt9).

-Nathan

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

Post a reply to this message

> If anyone here takes the time to update the INC files (both for the layred
> texture changes and the noise changes, the POV team would greatly
appreciate
> it, because we will be able to use that work towards POV 3.5).
>

If I knew what algorithm to apply, I could probably whip out a Perl script
to do most of the work.  Some need cleaning up anyway, with the old syntax
and all.

--John

Post a reply to this message

Just what is happening here?  That is, I wonder why the converted range will
be 0-.5 not 0-1.  When I did my Bozo tutorial waaaaaay back when (I think
it's on the first POV CD), it appeared that there were spots with values at
both 0 and 1, and I thought it was symetric -- both colored spots were the
same size.

Ah, the new Bozo range is .25-.75, so the end value is stretched to fit.
So, in the old formula, that was happening too?  Meaning my spots were too
big and not fuzzy, right?

Anyway, it looks like dividing by 2 on the Granite and changing filter to
transmit everywhere (Stone9 uses T_Crack1 also) gave me the same spirit as
the original.  Thanks!

So... what's the "layered texture change" you refered to in your earlier
note?

--John

"Nathan Kopp" <nat### [at] koppcom> wrote in message
news:3ab047cb$1@news.povray.org...
>
> "Mark Wagner" <mar### [at] gtenet> wrote g...
> > 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
>
> This formula works for bozo, which is a direct use of noise.  However,
> granite uses multiple iterations of noise, so this doesn't work.  However,
> you can get very close results by simply dividing all indices by 2 and NOT
> adding the 0.25.
>
> For granite, the converted example should look like this:
> color_map{
>     [.1 rgb 1]
>     [.25  rgb <1,1,0>]
>     [.35  rgb <0,0,1>]
> }
>
> I tested this and it works great for T_Grnt9.
>
> Also, make sure to convert rgbf to rgbt if layered textures with filter
are
> being used (not necessary for T_Grnt9).
>
> -Nathan
>
> > 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>]
> > }
>
>
>

Post a reply to this message

"John M. Dlugosz" <joh### [at] dlugoszcom> wrote...
> So... what's the "layered texture change" you refered to in your earlier
> note?

The layred texture change is the reason you need to change rgbf to rgbt for
layered textures.  The official POV treats "f" like "t" (i.e. using rgbf and
rgbt will yeild identical results for layered textures, but not for
individual textures).  This is a bug.  In MegaPov (and in the future in POV
3.5), layred textures will treat the "f" like filter and the "t" like
transmit.

Of course, all old textures that say "filter" really meant to say
"transmit" - so we have to go back and make them say what they really mean.

-Nathan

Post a reply to this message

"John M. Dlugosz" <joh### [at] dlugoszcom> wrote...
> Ah, the new Bozo range is .25-.75, so the end value is stretched to fit.
> So, in the old formula, that was happening too?  Meaning my spots were too
> big and not fuzzy, right?

Yes, that is correct.

-Nathan

Post a reply to this message

Update: simply dividing by two is better but still gives "stripes", not in
the spirit of the original texture, when I rendered a larger area to see it
better.  I'll play around with the map tomorrow, but if you have any
specific suggestions on how else I might transform it, I'd appreciate it.

--John

"Nathan Kopp" <nat### [at] koppcom> wrote in message
news:3ab1667a$1@news.povray.org...
>
> "John M. Dlugosz" <joh### [at] dlugoszcom> wrote...
> > Ah, the new Bozo range is .25-.75, so the end value is stretched to fit.
> > So, in the old formula, that was happening too?  Meaning my spots were
too
> > big and not fuzzy, right?
>
> Yes, that is correct.
>
> -Nathan
>
>
>

Post a reply to this message