I know I have brought this subject up before but
there have been some misunderstandings and I
didn't word my problem clearly enough.

This is my problem:

I have #declared a scg object made of multiple
objects each with different textures. These
textures contains normals of different kinds.

Now I want to use the object in a scene but the
object is way too large so I have to scale it
down 100 times.

But when I have scaled the object down this
problem appears:
All of the normals used in the object which is
of the kind that were not original meant to be
used in normals are now 100 times too deep
(e.g. it looks like bozo 200 instead of bozo 2).

I have made an example to show what I mean.
Change the value "Scale" to high and low values
like 100 and 0.01.
Although the camera, the light_source, and the
#declared object are all scaled by the same
amount you will see that the normal changes.

// Start of example

#declare Scale = 1;

camera {
   location -3*z
   look_at 0
   scale Scale
}

light_source {<10,20,-30>*Scale, color 1}

#declare Sphere =
sphere {
   0, 1
   pigment {color rgb 1}
   normal {bozo 1 scale 0.2}
}

object {Sphere scale Scale}

// End of example

So here's my questions:

Is it a bug? (If it isn't I think it is very
confusing and annoying).

If it isn't a bug how can I come around it
without having to change the object itself?
Because it is not always possible to change the
object for example in include files where
objects are used in multiple scenes.

I'm writing this because I have so far come
across the problem quite a lot of times and it
often blocks me from getting on with the project.
So I hope you can help me!

Greetings,

Rune S. Johansen

---
Visit The RSJ Website at http://welcome.to/rsj
for 3D images including still lives, dragons,
mathematical shapes, and more. Stereograms,
tutorials, The POV Desktop Theme, hundreds of
raytracing jokes, miscellaneous other things,
and a lot of fun!

Post a reply to this message

This could be looked at as a 'bug' or a 'feature'.  The fact of the matter is
that the apparent depth of the bumps generated by the surface normal
perturbing is not affected by the object's scaling.  You can counter this
when you apply the normal to the object by scaling it yourself.  Changing
the sphere declaration in the following way _almost_ solves the problem:

#declare Sphere =
sphere {
   0, 1
   pigment {color rgb 1}
   normal {bozo 1*Scale scale 0.2}
}

I say _almost_ because it fixes the problem for scaling larger (e.g.
Scale=100) but not for scaling smaller (e.g. Scale=0.01).

-Nathan

"Rune S. Johansen" wrote:
> 
> I have #declared a scg object made of multiple
> objects each with different textures. These
> textures contains normals of different kinds.
> 
> Now I want to use the object in a scene but the
> object is way too large so I have to scale it
> down 100 times.
> 
> But when I have scaled the object down this
> problem appears:
> All of the normals used in the object which is
> of the kind that were not original meant to be
> used in normals are now 100 times too deep
> (e.g. it looks like bozo 200 instead of bozo 2).

Post a reply to this message

One more thing... this only affects normals that are slope_map normals.
(i.e.  normals that are created from patterns that are ususally used for
pigment_maps, color_maps, etc.).  If you are using normals that were
designed to be normals (e.g. bumps, dents, wrinkles, etc.) you should not
experience this problem.

-Nathan

Post a reply to this message

Yes it is a bug and yes it is quite annoying that patterns that were
originally designed for normals and those designed for pigments behave
differently.

A problem might be that fixing it would break quite a few scene files.

Cheers, PoD.

Post a reply to this message

Nathan Kopp wrote:
> 
> One more thing... this only affects normals that are slope_map normals.
> (i.e.  normals that are created from patterns that are ususally used for
> pigment_maps, color_maps, etc.).  If you are using normals that were
> designed to be normals (e.g. bumps, dents, wrinkles, etc.) you should not
> experience this problem.
> 
> -Nathan

I think this proves that it is a bug.

Cheers, PoD.

Post a reply to this message