William F Pokorny <ano### [at] anonymousorg> wrote:

> Beyond that, you and I have questions as to whether the control point
> graphs and descriptions are correct with respect to the pattern(1). An
> update to these so they are better looking and generated with generated
> POV-Ray code is a good idea no matter. Christoph often made arguments
> for this and the v3.8 documentation has taken steps in this direction.

Yes, I think that such a thing would help answer most of the usual questions
about implementation, syntax, limitations, artefacts and other issues, etc.

Something using #switch to control the scene would allow easy generation of the
official documentation image, but with supplemental code showing variations and
slick tricks that one can do with the pattern.


> A sphere say. For example, and though there is turbulence, you can see
> the issue with the shipped quilt1 scene using the current quilted normal
> implementation. The curved surface is catching parts of the cube rather
> than adjusting with the surface curvature. As said above. I think we
> just let this go as is for quilted. Not to say we cannot work on and
> implement something better.

I have a "quilted.pov" scene - but yes, I understand (it's what I thought).
Same as if you use checkered.
Don't you just use uv_mapping to fix that?

> To my eye that looks good. I'll give it a try an maybe code up and
> in-built using the original c++ coding and compare to be paranoid. I see
> wanting to see this as a pigment (easier in povr due negative values).
> Not sure what you are after with the normal{} test...

You said the normal had different properties / handling than the pattern.  So
I'm treating them as two separate things.

> It has 360 degrees of directions to get perturbed in.
>
> And that's a problem. It needs to be perturb only in the half sphere of
> the original surface normal. Something I think my code addresses.

I mean that I don't understand exactly how a normal gets perturbed if I plug
some scalar function into a normal {} statement.
The top of a cube has a normal of +y.
If I perturb that normal, it gets tilted.
But in what direction?   I STILL have a full 360 degrees of a circle to choose
from - the tilt needs to be directional, but there is no basis vector
information associated with the scalar of the function.
Does the +y get tilted in the +x direction?  The +z direction?
Is it dependent on the light source or camera vector?


> Thanks. Guess I need to dig into the cause for the asymmetry in
> application seen here.

I must admit that I can't really see from your examples what the problem is -
but if you see it and it's real....

Post a reply to this message