On 10/12/20 10:47 PM, Bald Eagle wrote:
> Pfft.
> I rolled my own and came up with more or less the same curves, but the way the
> parameters influence them is different (of course...).
> 
> Maybe I can adapt this into a pigment pattern and a normal.
> 
> Do we know who made, how, and where the files are for the illustrations at:
> http://wiki.povray.org/content/Reference:Quilted_Pattern ?

well as far as who and how... don't know. the where is on the wiki... 
just click on the image to bring up revision info. given my confusion 
about your question i'm guessing my response is a swing and a miss

Post a reply to this message

Ash Holsenback <no### [at] spamcom> wrote:
> On 10/12/20 10:47 PM, Bald Eagle wrote:
> > Pfft.
> > I rolled my own and came up with more or less the same curves, but the way the
> > parameters influence them is different (of course...).
> >
> > Maybe I can adapt this into a pigment pattern and a normal.
> >
> > Do we know who made, how, and where the files are for the illustrations at:
> > http://wiki.povray.org/content/Reference:Quilted_Pattern ?
>
> well as far as who and how... don't know. the where is on the wiki...
> just click on the image to bring up revision info. given my confusion
> about your question i'm guessing my response is a swing and a miss

Jim,


From the source code,
Who:

* FUNCTION
*
*   quilted_pattern

* AUTHOR
*
*   Dan Farmer & Chris Young

As for how - those function graphs didn't make themselves, so I'm wondering what
source information was used and how those graphs were generated for the
documentation.
Their existence implies some (non-POV-Ray?) file(s) that were used to graph the
function, and those might shed some additional light the issue.



-BW

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Pfft.
> I rolled my own and came up with more or less the same curves, but the way the
> parameters influence them is different (of course...).
>
> Maybe I can adapt this into a pigment pattern and a normal.

Played around a bit more.
It seems that the quilted pattern uses a radial/spherical distance as the
driving parameter for the function, whereas I thought using a min max formula
for a box would give a "distance formula" that tracked the square/cubic shape.

It also seems that the quilted normal is an inverted function from the pigment
pattern, as I need to use 1-Fn(x,y,z) to get the same effect (convex face, with
concave edges)

Stock quilted in foreground (control0 0 control1 0), my function in the back
(c0=1 c1=0)

SO many things here have touched on what I learned and developed in past
projects.
rounded box isosurface
bilinear interpolation pattern
Bezier bicubic spline
space-tesselating patterns and isosurfaces
crackle/Delaunay/Voronoi wips

No ideas at this point about performance or numerical stability with regard to
the offsets, etc.

Post a reply to this message

Attachments:
Download 'newquiltedpatternandnormal.png' (93 KB)

Preview of image 'newquiltedpatternandnormal.png'

Added a spherical/Cartesian length function version.
(Midway, right/left)

Looks pretty similar to the stock quilted.

Still throwing darts in the dim light....

Post a reply to this message

Attachments:
Download 'newquiltedpatternandnormal.png' (138 KB)

Preview of image 'newquiltedpatternandnormal.png'

On 10/13/20 1:55 PM, Bald Eagle wrote:
> As for how - those function graphs didn't make themselves, so I'm wondering what
> source information was used and how those graphs were generated for the
> documentation.
> Their existence implies some (non-POV-Ray?) file(s) that were used to graph the
> function, and those might shed some additional light the issue.

indeed... that is likely. all i got when i did the initial load was a 
tarball that i still have access to... i looked and that's what we have 
for the graphs. i was curious because i thought it /might/ have been 
among some of the latex i converted. if you feel inclined to produce a 
set of new images, post them here and i'll replace on the wiki

Post a reply to this message

On 10/13/20 4:55 PM, Bald Eagle wrote:
> Added a spherical/Cartesian length function version.
> (Midway, right/left)
> 
> Looks pretty similar to the stock quilted.
> 
> Still throwing darts in the dim light....
> 

I'd guess there isn't much use in translating the non-working normal.cpp 
quilted code so below is an my initial attempt at a fix for surfaces 
perpendicular to the x, y and z axis. 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

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.

DBL just means double - an sdl float. The normal is the incoming normal. 
  fabs is abs in sdl. The () ? ... : ... stuff is select. floor and ceil 
are floor and ceil. The quilt_cubic you, Bill, understand better than me 
at this point.

This the sort of thing you're looking for?

----------
DBL nx = normal.x(), ny = normal.y(), nz = normal.z();
DBL ax = fabs(nx),   ay = fabs(ny),   az = fabs(nz);

DBL x = EPoint.x(), y = EPoint.y(), z = EPoint.z();
DBL flx = floor(x), fly = floor(y), flz = floor(z);
DBL sx = (x-flx < 0.5) ? -1 : 1,
     sy = (y-fly < 0.5) ? -1 : 1,
     sz = (z-flz < 0.5) ? -1 : 1;
DBL xm = flx+(ceil(flx+4.4e-8)-flx)/2.0;
DBL ym = fly+(ceil(fly+4.4e-8)-fly)/2.0;
DBL zm = flz+(ceil(flz+4.4e-8)-flz)/2.0;

DBL c0 = pattern->Control0, c1 = pattern->Control1;
DBL na = Tnormal->Amount;

if ((ax >= ay) && (ax >= az))
{
     DBL vy = quilt_cubic(fabs(y-ym),c0,c1)*sy;
     DBL vz = quilt_cubic(fabs(z-zm),c0,c1)*sz;
     nz = (nz < 0.0) ? -1 : 1;
     ny = ny + (na * vy);
     nz = nz + (na * vz);
}
else if ((ay >= ax) && (ay >= az))
{
     DBL vx = quilt_cubic(fabs(x-xm),c0,c1)*sx;
     DBL vz = quilt_cubic(fabs(z-zm),c0,c1)*sz;
     nx = nx + (na * vx);
     ny = (ny < 0.0) ? -1 : 1;
     nz = nz + (na * vz);
}
else
{
     DBL vx = quilt_cubic(fabs(x-xm),c0,c1)*sx;
     DBL vy = quilt_cubic(fabs(y-ym),c0,c1)*sy;
     nx = nx + (na * vx);
     ny = ny + (na * vy);
     nz = (nz < 0.0) ? -1 : 1;
}
normal = Vector3d(nx,ny,nz);
normal.normalize();  // <-- this normal vector what gets updated.

---------
All images in attached image using AA. Why noisy v3.8 results of(A)
looks less noisy at the expense of being quite slow.

A) v3.8 at master.
normal {quilted 0.5 control0 +1.0 control1 +1.0 scale 0.5}

B) povr with a fix.
normal {quilted 0.5 control0 +1.0 control1 +1.0 scale 0.5}

C) normal {quilted 0.5 control0 +1.0 control1 +1.0
no_bump_scale scale 0.5}

D) normal {quilted 0.5 control0 +0.0 control1 +1.0 scale 0.5}
E) normal {quilted 0.5 control0 +1.0 control1 +0.0 scale 0.5}
F) normal {quilted 0.5 control0 +0.0 control1 +0.0 scale 0.5}

G) normal {quilted 0.5 control0 +0.3 control1 +0.3 scale 0.5}
H) normal {quilted 0.5 control0 -0.3 control1 +0.3 scale 0.5}
I) normal {quilted 0.5 control0 +0.3 control1 -0.3 scale 0.5}

Bill P.

Post a reply to this message

Attachments:
Download 'aquiltednormalfix.jpg' (137 KB)

Preview of image 'aquiltednormalfix.jpg'

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.

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

But what did you fix?

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

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

> DBL just means double - an sdl float. The normal is the incoming normal.
>   fabs is abs in sdl. The () ? ... : ... stuff is select. floor and ceil
> are floor and ceil. The quilt_cubic you, Bill, understand better than me
> at this point.

I'll address that and the code supplied below right here.
What I was looking for was as close to a 1:1 translation from the original
source code written in c++ to how it would be done with functions in SDL if it
were written that way from scratch.

Not sure where you are pulling the code below from, but what I had found was:


const DBL INV_SQRT_3_4 = 1.154700538;


DBL quilt_cubic(DBL t, DBL p1, DBL p2)
{
 DBL it=(1-t);
 DBL itsqrd=it*it;
 // DBL itcubed=it*itsqrd;
 DBL tsqrd=t*t;
 DBL tcubed=t*tsqrd;
 DBL val;
 // Originally coded as...
 // val= (DBL)(itcubed*n1+(tcubed)*n2+3*t*(itsqrd)*p1+3*(tsqrd)*(it)*p2);
 //re-written by CEY to optimise because n1=0 n2=1 always.
 val = (tcubed + 3.0*t*itsqrd*p1 + 3.0*tsqrd*it*p2) * INV_SQRT_3_4;
 return(val);
}


And so my first attempt at translating that was:

#declare INV_SQRT_3_4 = 1.154700538;
#declare Floor = function (T) {select (T, floor (1-T), floor (T))}
#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

}

So:
I would say that if we could get that working as a pigment {function{}}
statement and as a normal{function{}}, then we should be able to then graph it
out the way I did mine to emulate the graphs in the documentation.
They _should_ match (aside from any misleading typos in the docs)

As for the underlying problems with the raytraced result of the pattern, I can
only speculate:
1. it's a function gradient problem since the function may be discontinuous,
have cusps, or whatever else resulting from the use of floor(), etc - since it's
a function designed to be constrained to a unit cube.
I'll have to look at what the isosurface looks like, etc.

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.

As for the normal-specific function, I'd just need a very basic and specific
explanation of exactly how a given surface normal gets perturbed, in general (by
any user-written scalar function{}), and specifically by this function.
Just so it's crystal clear to me -  because what direction does a +y normal get
tilted to? It has 360 degrees of directions to get perturbed in.

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;




> This the sort of thing you're looking for?
>
> ----------
> DBL nx = normal.x(), ny = normal.y(), nz = normal.z();
> DBL ax = fabs(nx),   ay = fabs(ny),   az = fabs(nz);
>
> DBL x = EPoint.x(), y = EPoint.y(), z = EPoint.z();
> DBL flx = floor(x), fly = floor(y), flz = floor(z);
> DBL sx = (x-flx < 0.5) ? -1 : 1,
>      sy = (y-fly < 0.5) ? -1 : 1,
>      sz = (z-flz < 0.5) ? -1 : 1;
> DBL xm = flx+(ceil(flx+4.4e-8)-flx)/2.0;
> DBL ym = fly+(ceil(fly+4.4e-8)-fly)/2.0;
> DBL zm = flz+(ceil(flz+4.4e-8)-flz)/2.0;
>
> DBL c0 = pattern->Control0, c1 = pattern->Control1;
> DBL na = Tnormal->Amount;
>
> if ((ax >= ay) && (ax >= az))
> {
>      DBL vy = quilt_cubic(fabs(y-ym),c0,c1)*sy;
>      DBL vz = quilt_cubic(fabs(z-zm),c0,c1)*sz;
>      nz = (nz < 0.0) ? -1 : 1;
>      ny = ny + (na * vy);
>      nz = nz + (na * vz);
> }
> else if ((ay >= ax) && (ay >= az))
> {
>      DBL vx = quilt_cubic(fabs(x-xm),c0,c1)*sx;
>      DBL vz = quilt_cubic(fabs(z-zm),c0,c1)*sz;
>      nx = nx + (na * vx);
>      ny = (ny < 0.0) ? -1 : 1;
>      nz = nz + (na * vz);
> }
> else
> {
>      DBL vx = quilt_cubic(fabs(x-xm),c0,c1)*sx;
>      DBL vy = quilt_cubic(fabs(y-ym),c0,c1)*sy;
>      nx = nx + (na * vx);
>      ny = ny + (na * vy);
>      nz = (nz < 0.0) ? -1 : 1;
> }
> normal = Vector3d(nx,ny,nz);
> normal.normalize();  // <-- this normal vector what gets updated.


> C) normal {quilted 0.5 control0 +1.0 control1 +1.0
> no_bump_scale scale 0.5}

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 .

Post a reply to this message

And the other thing that's throwing me off is what exactly are the function
inputs and outputs.

I was trying to graph the built-in quilted pattern before I headed out, and got
some curved inverted "V" shapes instead of anything resembling the documentation
shapes.

#declare CN = array [5] {0, 0.33, 0.5, 0.67, 1}
#local c0 = CN[0];
#for (c1, 0, 4)
#ifdef (Q) #undef Q #end
#declare Q = function {pigment {quilted control0 c0 control1 CN[c1]}}
.....

Then it struck me that the function probably isn't using linear x at the surface
of the cube where I see the pattern - it's using the vector length of <x,y,z>,
and spitting out --- a scalar.

So if I get the native pattern function worked out and graph it, I'll be sure to
LABEL THE AXES this time 'round.

'till then, hi ho, hi ho....

Post a reply to this message

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

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