On 10/14/20 4:07 PM, Bald Eagle wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
>> I'd guess there isn't much use in translating the non-working normal.cpp
>> quilted code so
> 
> Translating the non-working code would help reproduce the nonworkability.
> Then we could see where and why it doesn't work.

No doubt it might help you and perhaps others play with that code, but 
suppose I believe I've already sorted through the issues with the 
normal.cpp code as it was. I don't recall anything extra needed for 
translation to SDL over what I posted and I know you know where the code 
is based upon your questions below. :-)

> 
>> below is an my initial attempt at a fix for surfaces
>> perpendicular to the x, y and z axis.
> 
> But what did you fix?

All the bugs about which I previously posted - and a couple lessor about 
which I did not write. ;-)

We are only handling cube and flat surfaces without distortion. There 
thinking about it more the documentation - it is pretty clear the about 
the application being via unit cubes.

My fix amounts to being axis-projective within each unit cube - taking 
care with the polarity of the original normals and the '2D' offsets with 
respect to the unit square's two center axes. Maybe we forget trying to 
make 'quilted' work for other than via projection or on flat surfaces 
surfaces.

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.

Plus, I now have cases with the no_bump_scale where I don't understand 
what is happening. Your interpretation matches mine - which makes me 
think there is another bug somewhere in the normals handling, but this 
one probably outside quilted itself.

And I rambled a little about there being unfinished warp related normal 
code. With this I expect some warps beyond transforms are not working 
correctly, but I've never explored in this direction. These issues are 
outside the quilted code itself in any case.

(1) - With the initial povr fix in place it looks to me as if the center 
of the square face relates to control point 0 and control point 1 the 
edges. One and one values is a rounded at both ends and two and two 
flat. Negative values inverts the curvature so you can get for example 
tile looking faces where the corners are slightly raised relative to the 
centers - which I think is kinda cool.

Argh, here I am writing chapters of books again...

What to do when questions are simple; folks want simple answers, but the 
situations are, with even a single feature, brutally complicated. :-(

> 
>> This updated code passes most of
>> my test cases but of course has varying results with respect to curved
>> surfaces - as does the original.  Whether this is what we want for a
>> best quilted fix - I don't know! I don't think we really know what the
>> original coders expected or perhaps even got to one degree or another in
>> older versions of code
> 
> I'm not sure what you mean about curved surfaces - no examples have been
> provided.
> 
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.

>> One puzzle for me is I looked at no_bump_scale in the upper right render
>> (C).  I expected it to have some effect on all three surfaces, but it's
>> only changing the -x one! Not dug into code. Anyone have an idea what's
>> going on? This touches on me not being a big user of normals. Not sure
>> I've ever used no_bump_scale myself.
> 
> You haven't supplied any of your scene code, so I can't tell if you have any
> scaling or offsets.  The wiki says that no_bump_scale just cancels out any
> scaling of the normal depth when the texture or normal itself is scaled.
> 
Yeah, sorry, I meant to say in my post I just hacked the allnormals.pov 
replacing the:

#declare Quilted = normal {...}

declare with the normal{} blocks indicated. FWIW. I also changed the T 
texture to read:

#declare T=texture {
     pigment {rgb 1}
     normal { Quilted }  // <--- This
     finish {phong 0.5 phong_size 20}
}

So I wouldn't have to play with animation flags.

> 
> And so my first attempt at translating that was:
> 
> #declare INV_SQRT_3_4 = 1.154700538;
...
> #declare IT = function (T) {1-T}
> #declare ITsqr = function (T) {pow(IT (T), 2)}
> #declare Tsqr = function (T) {pow(T, 2)}
> #declare Tcub = function (T) {pow(T, 3)}
> #declare Val0 = function (T, _P1, _P2) {
> (
> pow(T, 3) +
> (3 * T * pow(1-T, 2) * _P1) +
> (3 * pow(T,2) * (T - pow(T, 2)) * _P2)
> )
> * INV_SQRT_3_4
> 
> }
> 

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

> 
> 2.  There's some interface problem between the output of the function and the
> rest of what happens to that information after it gets evaluated and sent down
> the ray / surface rendering pipeline.

Yes. One apparent in the initial "DBL it=(1-t);" the function is 
expecting inputs in the range of 0 to 1 because it's inverting on that 
range, but we are not providing it exactly that range(2). In fact in the 
normal version the value strengths passed are varying as we move a 
surface along the axis in the cube.

(2) - And neither am I in my initial re-code. This maybe needs 
adjustment...

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'd also need the following three statements in c++ syntax decrypted, so I could
> try translating those into SDL.
> 
>      const QuiltedPattern *pattern =
> dynamic_cast<QuiltedPattern*>(Tnormal->pattern.get());
> 
>      POV_PATTERN_ASSERT(pattern);
> 
> and
> 
>      normal += (DBL)Tnormal->Amount * value;
> 

The first two amoung to getting the correct object pattern pointer type 
to get access to the two control values. This is one place where my povr 
code had already diverged. In my code this is coded:

POV_PATTERN_ASSERT(dynamic_cast<QuiltedPattern*>(Tnormal->pattern.get()) 
!= nullptr);

const QuiltedPattern *pattern = 
static_cast<QuiltedPattern*>(Tnormal->pattern.get());

so we only take the hit of the dynamic_cast run time checking if certain 
debug settings are on during a compile. The POV_PATTERN_ASSERT does 
nothing in a regular compile. (Aside: one thing I noticed in the future 
debian work is they currently have such a debug enabled version of 
povray as possible install version.)

Ah, dang. And your question about "normal += (DBL)Tnormal->Amount * 
value;" makes obvious I forgot to do that step in my re-code! Thanks. I 
was getting a normal scaling of 1.0 despite coding 0.5 due this. :-)

Oh, that statement is adding an adjustment vector - one scaled by the 
normal patterns sizing value (and/or bump_size in at least some 
patterns) - to the original surface normal. The is the "perturb the 
normal" step.

...
> 
> So, as I currently understand it, if the default bump_size is 1.0, then
> no_bump_scale decouples the bump_size from the scale 0.5 statement, so that the
> area of the normal gets scaled, but the bump_size stays the same at 1.0 instead
> of getting shrunk to 0.5 .
> 
Thanks. Guess I need to dig into the cause for the asymmetry in 
application seen here.

Bill P.

Post a reply to this message