Hi all!

I've been playing with this for some time now and just can't seem to solve
it, so I'm posting the question here.  Don't know if new users gets much
traffic though, so if there's no response in a few days I might post into
general.

Here's my problem: since I'm simply crazy, I'm trying to convert a mess of
very old (v0.5-v2) scene files to the 3.6 language.  Why?  Just because.
Even when using the version directive to get old files to parse, some things
just don't render correctly because of changes in the engine; for example,
some glasses, and gradient patterns...  So I want to convert the language in
the old files so the render correctly under 3.6 and hopefully future
versions.  Granted, nothing can be perfect, but v1 compatibility will be
phased out much sooner that v3.6 compatibility will.  Right?

This is the first hurdle I haven't been able to get around.  Something
changed with normals between 3.1 and 3.5, and it's really screwing around
with the one texture I've got.  This is from an awesome Mike Miller scene
file (kudos to those who can figure out which one!).  The code below is just
from the simple boilerplate scene with some extra stuff removed (I'd post
links to images but my webserver no likey me at the moment).  Render it with
the version directive intact and you'll see what I *want* to get...  A
sphere, with some gentle, um, horizontal ripples (latitudinal?  whatever).
You can see the crests and troughs without a problem, and the phong
highlight is nicely distributed just as you'd expect it to be.

Now render it without the version override.  Or, for sake of argument, with
#version 3.5; you'll see the difference immediately.  The normal appears to
flatten out, resulting in ugly green and black(ish) bands without any
highlight left.  I can't figure out exactly what's happening here - even if
the normal did *flatten*, then I should still get something of a highlight,
this looks like it's killing the whole finish.

I'm sure part of it has to do with the odd scaling factor, but this is what
he originally used, and I don't know how to accurately recreate it with
different values.  I've tried reordering the pigment / finish / normal
blocks, and using the no_bump_scale keyword, with no effect.  It's not just
like it's a parsing issue / difference, because you can wrap the definitions
with #version tags and it does no good.  The scene *must* be in a pre- 3.5
version state when rendering begins (i.e. that's why version at the end of
the file works), and codewise, I can see why in normal.cpp; it's checking
for version > 310 and applying a warp / unwarp around the normal
perturbation.  Unfortunately, I don't know what the warp / unwarp is doing;
I haven't specified any warp parameters, is there some default I should know
about?

Don't know what else to try here - I don't want to leave the scene in v3.1
mode; it kinda defeats the purpose of a 3.6 conversion, and I don't know
what other 3.5-6 features it disables.  I've searched through the
newsgroups, but can't seem to find anything relating to this, nor can I find
an old changelog from version 3.1 to 3.5 that might tell me what features
changed.  So, if ANYONE know what's going on here and how to get around it
(without #version 3.1; :)) I'd really appreciate it.

Thanks!
-D

Example scene:
#include "colors.inc"

camera {
  location  <0.0, 0.5, -4.0>
  direction 1.5*z
  right     x*image_width/image_height
  look_at   <0.0, 0.0,  0.0>
}

light_source {
  <0, 0, 0>            // light's position (translated below)
  color rgb <1, 1, 1>  // light's color
  translate <-30, 30, -30>
}

#declare Test_Texture =
texture {
   pigment {
      color DarkGreen
   }
   finish {
      ambient 0.350
      diffuse 0.800
      phong 1
      phong_size 60
      crand 0.040
   }
   normal {
      waves .800
      frequency .050
      //no_bump_scale
   }
   scale <10, .001, 10>  // a little smaller than actual to show more
surface waves
}

sphere { <0,0,0>, 1
   texture {
      Test_Texture

   }

}

// REVERT TO VERSION 3.1 TO RENDER AS DESIRED
#version 3.1;

Post a reply to this message

"David Karl" <dka### [at] asninccom> wrote in message
news:40e484b6$1@news.povray.org...
> Hi all!

Hello there!  :-)

8<----
> This is the first hurdle I haven't been able to get around.  Something
> changed with normals between 3.1 and 3.5, and it's really screwing around
> with the one texture I've got.  This is from an awesome Mike Miller scene
> file (kudos to those who can figure out which one!).  The code below is
just
> from the simple boilerplate scene with some extra stuff removed (I'd post
> links to images but my webserver no likey me at the moment).  Render it
with
> the version directive intact and you'll see what I *want* to get...  A
> sphere, with some gentle, um, horizontal ripples (latitudinal?  whatever).
> You can see the crests and troughs without a problem, and the phong
> highlight is nicely distributed just as you'd expect it to be.
>
> Now render it without the version override.  Or, for sake of argument,
with
> #version 3.5; you'll see the difference immediately.  The normal appears
to
> flatten out, resulting in ugly green and black(ish) bands without any
> highlight left.
----8<

Um... hmmmmm. No idea why that is, but your message here got me to trying
number_of_waves and I'm seeing once again what might have been a bug during
beta testing, which could be totally unrelated. However, then again it could
be related in at least some obscure way I guess. Unfortunately, I don't
recall what, if anything might have been done about it. I was a little
sparse on beta testing toward the end.

For instance: if global_settings {number_of_waves 10}} is used (the default)
I get a different (and incorrect) rendering from the next, or following,
render without changing its value. To see this happen yourself you'll need
to set another value, render, then change it to 10, render, and finally
render one last time after that. Take note of the appearance of the sphere
when 10 is used the first time. Of course, it might not happen for everyone.

Bob H.

Post a reply to this message

In article <40e4e38b$1@news.povray.org> , "Hughes, B." 
<bob### [at] charternet> wrote:

> Um... hmmmmm. No idea why that is, but your message here got me to trying
> number_of_waves and I'm seeing once again what might have been a bug during
> beta testing, which could be totally unrelated.

IMHO it is a bad idea to start some random speculation that this could be a
bug and not a user error, in particular if you are not certain and to start
talking about it in povray.newusers .

    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

"Hughes, B." <bob### [at] charternet> wrote in message
news:40e4e38b$1@news.povray.org...
<snip>
>
> Um... hmmmmm. No idea why that is, but your message here got me to trying
> number_of_waves and I'm seeing once again what might have been a bug
during
> beta testing, which could be totally unrelated. However, then again it
could
> be related in at least some obscure way I guess. Unfortunately, I don't
> recall what, if anything might have been done about it. I was a little
> sparse on beta testing toward the end.
>
> For instance: if global_settings {number_of_waves 10}} is used (the
default)
> I get a different (and incorrect) rendering from the next, or following,
> render without changing its value. To see this happen yourself you'll need
> to set another value, render, then change it to 10, render, and finally
> render one last time after that. Take note of the appearance of the sphere
> when 10 is used the first time. Of course, it might not happen for
everyone.
>
> Bob H.
>
>
Yeah, I had noticed that too, but just thought it was me doing something
wrong :)
I tried playing around with just one wave to try and get the desired effect,
but the same 'flattening' occurred, and since the wave center was placed
randomly (well, pseudo-randomly I guess), it didn't really do what I
wanted... I don't have the older source around anymore, but the 2.2
documentation even states it used 10 waves by default, so I don't think it's
as simple as that changing in current versions. I'll keep plugging at it
though, any other ideas?

Thanks,

-D

Post a reply to this message

"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:40e52cba$1@news.povray.org...
> In article <40e4e38b$1@news.povray.org> , "Hughes, B."
> <bob### [at] charternet> wrote:
>
> > Um... hmmmmm. No idea why that is, but your message here got me to
trying
> > number_of_waves and I'm seeing once again what might have been a bug
during
> > beta testing, which could be totally unrelated.
>
> IMHO it is a bad idea to start some random speculation that this could be
a
> bug and not a user error, in particular if you are not certain and to
start
> talking about it in povray.newusers .

Okay. It jumped out at me as being a probable cause and now I see it likely
is not. Too quick to think.

What I meant to be saying, at the moment, was to bring up the strange
behavior of number_of_waves, so I took the opportunity to speak up about
that. Perhaps getting it noticed here anyhow. Seems very peculiar for
something to get rendered twice in a different way each time without making
changes to the file content. Apologies for not moving this observation to
the appropriate place.

Bob H.

Post a reply to this message

"David Karl" <dka### [at] asninccom> wrote in message
news:40e582c0$1@news.povray.org...
> I tried playing around with just one wave to try and get the desired
effect,
> but the same 'flattening' occurred, and since the wave center was placed
> randomly (well, pseudo-randomly I guess), it didn't really do what I
> wanted... I don't have the older source around anymore, but the 2.2
> documentation even states it used 10 waves by default, so I don't think
it's
> as simple as that changing in current versions. I'll keep plugging at it
> though, any other ideas?

Yes, I don't think it really has anything to do with number_of_waves,
specifically, now that I've looked at it more.

What helps, though, is to use:

 warp { cylindrical orientation y dist_exp 0 }

within the normal statement. And yet I can't get a spherical warp to look
okay, so I'm at a loss to explain anything.

Personal note: I realize waves and ripples patterns are somewhat special;
like checker, hexagon and brick, in that they don't use wave forms
modifiers. I just don't know (or remember) much about the internal code for
them. I'm thinking the best place to find info is in the program source
code, as you mentioned already, or from someone who knows of this particular
thing.

Bob H.

Post a reply to this message