4 Pages<1234>
Options
Go to last post Go to first unread
3dcheapskate  
#21 Posted : Thursday, April 21, 2016 11:12:14 AM(UTC)
3dcheapskate

Rank: Advanced Member

Joined: 3/18/2016(UTC)
Posts: 220

Thanks: 6 times
Was thanked: 4 time(s) in 4 post(s)
Thoughts About Meaning (Or Not) Of Multipliers, And About Concave/Convex Detection

A thought came to mind while I was looking at those last two renders. Maybe the multiplying factor that I'm trying to work out for dNdu and dPdu is truly a red herring, and it has no meaning other than being 'the value that gives me a correct-looking colour range for my half-cylinder test'. (I could probably have inferred that from bagginsbill's comment in post 7, but I really wanted to prove it to myself)

However, the search for these probably meaningless multipliers has given me two useful bits of information. For smooth blobby* things of a scale similar to a human being:

1) dNdu seems to be in the range -0.07 to +0.07 and is unaffected by making the object bigger or smaller
2) dPdu seems to be in the range -15 to +15, but changing the size of the object has an effect.

I'm still hoping to find out what the raw output of dNdu and dPdu actually represents, not in vague 'rate of change of X against Y' terms, but in more specific terms - e.g. that the value of dNdu was something like 'radians per full width of the UV mapping' (N.B. it isn't!).

But in addition to delving deeper into what they actually are, I think I'm now at the point where I can start playing with them.

The first thing I'm interested in is working out whether a surface is concave or convex (bagginsbill was demonstrating a node based curvature detector a year ago in that Bronze and Verdigris thread).

Imagine two of my half-cylinders and flip the normals on one of them (badly drawn sketch attached).
I'm thinking that the dPdu node will give the same values for both cylinders.
I'm also thinking that there's a way to use the dNdu node (or maybe even the N node) in conjunction with the dPdu node to determine which of the two situations we have.

I'm also off to bed...so hopefully tomorrow I'll have some more

*technical term meaning... well, it's difficult to describe...

Edited by user Monday, April 25, 2016 3:22:46 AM(UTC)  | Reason: Not specified

3dcheapskate attached the following image(s):
convexconcave.jpg
I'm still on Poser 9 and/or PP2014...
3dcheapskate  
#22 Posted : Thursday, April 21, 2016 10:27:18 PM(UTC)
3dcheapskate

Rank: Advanced Member

Joined: 3/18/2016(UTC)
Posts: 220

Thanks: 6 times
Was thanked: 4 time(s) in 4 post(s)
Behaviour of dPdu and dNdu Not As Expected When Normals Are Flipped

This morning I created a very simple test. A double cylinder prop, each cylinder identical except for the normal direction. 10.312" radius. 100x30 mesh with the circumference mapped horizontally (U) and the length mapped vertically (V).

I placede three of these props in the scene with Andy, with the outward-facing normal cylinders on his right (our left), and the inward facing cylinders on his left (our right).

I applied an (N x 1) shader to the pair at shoulder height, a (dNdu x 15) shader to the pair at his feet, and a (dPdu x 0.15) shader to the pair in front of him and rendered (that render will have negative RGB values represented as black).

I then added an Abs to make the negative values positive and re-rendered

Most puzzling.
- On the NON-Abs render I had expected to see some red-orange-green colours on the inside of the inward-facing normal dNdu and dPdu cylinders.
- On the ABS render - where on earth is the BLUE coming from ?


Third render I simply applied a U node to the pair at Andy's feet and a V node to the pair in front. Nothing odd with the UV mapping.

Damn it ! And I thought that it was all beginning to make sense !

(Poser 9 renders.  I forgot to turn off the lights, but I don't think that is the cause of the unexpected results)

Edited by user Thursday, April 21, 2016 11:25:43 PM(UTC)  | Reason: added third render

3dcheapskate attached the following image(s):
ScaledSignedValues.jpg
ScaledAbsValues.jpg
UVcheck.jpg
I'm still on Poser 9 and/or PP2014...
3dcheapskate  
#23 Posted : Thursday, April 21, 2016 11:08:03 PM(UTC)
3dcheapskate

Rank: Advanced Member

Joined: 3/18/2016(UTC)
Posts: 220

Thanks: 6 times
Was thanked: 4 time(s) in 4 post(s)
Possible Major Bug In dPdu (and possibly dNdu too) ? (Edit: I overlooked something I wasn't aware of, And Still Don't Understand... ;o)

I'm really hoping that I've got it wrong and done something stupid. Either:
1) I've seriously misunderstood something.
2) I've overlooked something important     <--- something about flipping the normal in Blender created a square that behaves strangely. More on that in post 32
3) I've made a stupid mistake in my test setup.
4) There's a major bug in dPdu (and possibly dNdu too)

I'm hoping for 1, 2, or 3 but I just can't see what I've done wrong.

Here's another simple test (again in Poser 9). I applied each individual component of dPdu in turn to the front pair of cylinders. (There's an infinite light in the scene). There is absolutely no way I can see that component 2 (blue, Z) of dPdu can be anything except zero for this test. It definitely looks like a bug to me.

Edit: confirmed exactly the same behaviour in PP2014.

Edited by user Saturday, April 23, 2016 11:52:01 AM(UTC)  | Reason: Not specified

3dcheapskate attached the following image(s):
reallyodd.jpg
I'm still on Poser 9 and/or PP2014...
3dcheapskate  
#24 Posted : Thursday, April 21, 2016 11:40:55 PM(UTC)
3dcheapskate

Rank: Advanced Member

Joined: 3/18/2016(UTC)
Posts: 220

Thanks: 6 times
Was thanked: 4 time(s) in 4 post(s)
Off At A Tangent, Trying To Understand What's Going On With My Flipped-Normal Cylinder

The blue cylinder in post 22 seems more like what I'd expect from dPdv, not dPdu. So I changed my U variables to V variables and redid that test.
- The blue and black cylinders are what I'd expect for dNdv and dPdv on the cylinders with outward facing normals.
- the two green-orange-red cylinders at floor level on the right are what I'd expect for dNdu and dPdu on the inward-facing-normal clinders

Very interesting result - flipping normals (without changing the UV mapping) seems to flip U and V as far as dNdu, dNdv, dPdu and dPdv are concerned.

I need a break from this for a while, so I'm off to play with a cube and ridiculous displacements !   :)

Edited by user Saturday, April 23, 2016 11:51:19 AM(UTC)  | Reason: Not specified

3dcheapskate attached the following image(s):
tryingvinstead.jpg
I'm still on Poser 9 and/or PP2014...
3dcheapskate  
#25 Posted : Friday, April 22, 2016 5:24:50 AM(UTC)
3dcheapskate

Rank: Advanced Member

Joined: 3/18/2016(UTC)
Posts: 220

Thanks: 6 times
Was thanked: 4 time(s) in 4 post(s)
Off At A Tangent, Trying To Understand What's Going On With My Flipped-Normal Cylinder (Continued)

I recall something about normals usually pointing in a specific direction in relation to the 'winding' of the vertices forming the face. Something like "if a quad face is defined as 'f 1 2 3 4' (OBJ format) then if you hold your right (or was it left?) hand - fingers curled, thumb extended, hitchhiker fashion - and place your hand in the centre of the face with your curled fingers pointing in the 'winding', i.e. 1-2-3-4, direction, then your thumb is pointing along the normal".

Simply flipping the normals as I did in Blender  for one cylinder of the pair would mean that one cylinder conformed to that while the other didn't. 

So I redid the double cylinder in Blender, but this time as well as flipping the normals I also inverted the U direction (by multiplying the U coordinates by -1 in Blender's UV pane)

Here's my results (Poser 9) plugging variable nodes directly into Ambient_Color and setting Ambient_Strength to my multipliers.


Not quite sure what to make of them yet.

Edited by user Saturday, April 23, 2016 11:52:32 AM(UTC)  | Reason: Not specified

3dcheapskate attached the following image(s):
flipNorm+U.jpg
I'm still on Poser 9 and/or PP2014...
bagginsbill  
#26 Posted : Friday, April 22, 2016 6:40:47 AM(UTC)
bagginsbill

Rank: Advanced Member

Joined: 2/25/2016(UTC)
Posts: 76

Thanks: 1 times
Was thanked: 24 time(s) in 19 post(s)
I'm sorry I'm not helping. You caught me at the worst possible time. I'm at end of a big project, about to go out of town for the weekend, and immediately out of town again for work.

One tidbit. dNdu can be enormous, not just within -1 to 1. The  change of any single component with N (such as N.x) with respect to U could be large. Consider a box with sides, U mapped 0 to 1 over all 4 side faces, so that first face is 0 to .25, second is .25 to .5, etc. Now consider the normal of the front face (where N.x is 0) vs. the side face (where N.x is 1). At the corner, we have dNdu = dN / du = (1 - 0) / (?). Suppose the corner is completely hard so that the transition is finished in 0 units of u (no transition from front to side). The du is 0, so the dN/du is infinite.

What if the corner is slightly rounded? Well it's still going to be tiny - perhaps du is .01? In which case dN/du is 1 / .01 = 100.
Suppose it's very rounded, like du = .1? Then dN/du is 1/.1 = 10.


See? There's no well-defined range for dNdu. Since it is a ratio, with a denominator that can be pretty much any value between 0 and 1, the ratio can be any value between - infinite and +infinity.
bagginsbill  
#27 Posted : Friday, April 22, 2016 6:43:15 AM(UTC)
bagginsbill

Rank: Advanced Member

Joined: 2/25/2016(UTC)
Posts: 76

Thanks: 1 times
Was thanked: 24 time(s) in 19 post(s)
One other tidbit. A surface can be simultaneously convex and concave, such as the middle of a saddle.

Depending on the orientation of your UV coordinates, you would either see that it's convex in U and concave in V, or it could be the other way around, or (and this is mind boggling) if U and V are 45 degrees to the saddle they can both claim convex or both claim concave.


I confess the math of 3D convexity is actually unknown to me.
3dcheapskate  
#28 Posted : Friday, April 22, 2016 10:16:06 AM(UTC)
3dcheapskate

Rank: Advanced Member

Joined: 3/18/2016(UTC)
Posts: 220

Thanks: 6 times
Was thanked: 4 time(s) in 4 post(s)
Originally Posted by: bagginsbill Go to Quoted Post
I'm sorry I'm not helping. You caught me at the worst possible time. I'm at end of a big project, about to go out of town for the weekend, and immediately out of town again for work...


No worries - I realize that everybody has other things keeping them busy. Besides, working through this stuff for myself is waking up brain cells !  :)

Originally Posted by: bagginsbill Go to Quoted Post
...One tidbit. dNdu can be enormous, not just within -1 to 1. The  change of any single component with N (such as N.x) with respect to U could be large. Consider a box with sides, U mapped 0 to 1 over all 4 side faces, so that first face is 0 to .25, second is .25 to .5, etc. Now consider the normal of the front face (where N.x is 0) vs. the side face (where N.x is 1). At the corner, we have dNdu = dN / du = (1 - 0) / (?). Suppose the corner is completely hard so that the transition is finished in 0 units of u (no transition from front to side). The du is 0, so the dN/du is infinite.

What if the corner is slightly rounded? Well it's still going to be tiny - perhaps du is .01? In which case dN/du is 1 / .01 = 100.
Suppose it's very rounded, like du = .1? Then dN/du is 1/.1 = 10.

See? There's no well-defined range for dNdu. Since it is a ratio, with a denominator that can be pretty much any value between 0 and 1, the ratio can be any value between - infinite and +infinity.


Yes indeed  - I think that was beginning to dawn on me around posts 19 to 21, with the renders of Andy with the tree trunk and mushroom. I realized that the  x15 for dNdu and x0.15 for dPdu are totally meaningless - except in my specific test cases with the cylinders and half-cylinders. And I'm running into plenty of problems with even this very simple setup, so sticking with my dNdux15 and dPdux0.15 is simply a temporary way to keep the number of unknowns to a minimum until I solve the most basic problems (e.g. the blue cylinder).

Once I'm confident of the basics I'll be abandoning my x15 and x0.15 and using the visualizer, so I can start looking at more realistic cases.

Originally Posted by: bagginsbill Go to Quoted Post
One other tidbit. A surface can be simultaneously convex and concave, such as the middle of a saddle.

Depending on the orientation of your UV coordinates, you would either see that it's convex in U and concave in V, or it could be the other way around, or (and this is mind boggling) if U and V are 45 degrees to the saddle they can both claim convex or both claim concave.

I confess the math of 3D convexity is actually unknown to me.


I'll leave saddles till later then. Much later...  ;o)
Edit: the phrase "point of inflexion" surfaced in my brain overnight.

Edited by user Friday, April 22, 2016 11:01:06 PM(UTC)  | Reason: Not specified

I'm still on Poser 9 and/or PP2014...
3dcheapskate  
#29 Posted : Saturday, April 23, 2016 12:07:02 AM(UTC)
3dcheapskate

Rank: Advanced Member

Joined: 3/18/2016(UTC)
Posts: 220

Thanks: 6 times
Was thanked: 4 time(s) in 4 post(s)

Checking dPdu For A Simple Pair Of  Squares, One With The Normal Flipped

Edit: Correction: I noticed a mistake in transferring texture vertex numbers from the OBJ to the drawing - the U and V axes of both squares are actually the same (corrections in red on the drawing).

I also forgot that the Blender OBJ export is doing an axis conversion to the 'Z Forward' convention - this may account for the fact that I've got the V direction on my drawing opposite to what I expected.


I decided to use a pair of planes (one with the normal flipped),  instead of pair of cylinders (one with the normal flipped). Here's my procedure for creating the OBJ file.

Open Blender, Create>Mesh>Plane ...creates a 2x2 plane, 4 vertices/i face, normal pointing upwards.
Goo into Edit mode, and from top view Mesh>UV Unwrap > Project From View (Bounds) ... this UV maps it to the full square
Scale the plane by 0.5 and then again by 0.1 with respect to the cursor at world origin ...the plane's now 0.1 x 0.1
Shift it in X by -0.1
Duplicate it and move the duplicate 0.2 in X
With the duplicate selected do Mesh>Normals>Flip Normals
(Take a screenshot with face normals displayed)
Export as an OBJ - here it is:

# Blender v2.77 (sub 0) OBJ File: ''
# www.blender.org
mtllib SquarePairOneFlipped.mtl
o Plane
v -0.150000 0.000000 0.050000
v -0.050000 0.000000 0.050000
v -0.150000 0.000000 -0.050000
v -0.050000 0.000000 -0.050000
v 0.050000 0.000000 0.050000
v 0.150000 0.000000 0.050000
v 0.050000 0.000000 -0.050000
v 0.150000 0.000000 -0.050000
vt 0.000000 0.000000
vt 1.000000 0.000000
vt 1.000000 1.000000
vt 0.000000 1.000000
vt 0.000000 0.000000
vt 0.000000 1.000000
vt 1.000000 1.000000
vt 1.000000 0.000000
usemtl None
s off
f 1/1 2/2 4/3 3/4
f 5/5 7/6 8/7 6/8

For both planes the U direction is in the Blender +X direction, which is the Poser +X direction. So I expect dPdu to be red for both.


*The drawing also confirms that my 'winding' recollection was along the right lines, but I got the wrong hand. It's actually a LEFT-handed hitchhike hand pose with your fist oriented so the fingers curl in the winding direction - your thumb points along the normal.



Edited by user Saturday, April 23, 2016 4:50:39 AM(UTC)  | Reason: Not specified

3dcheapskate attached the following image(s):
Results.jpg
edited.jpg
I'm still on Poser 9 and/or PP2014...
3dcheapskate  
#30 Posted : Saturday, April 23, 2016 12:15:29 AM(UTC)
3dcheapskate

Rank: Advanced Member

Joined: 3/18/2016(UTC)
Posts: 220

Thanks: 6 times
Was thanked: 4 time(s) in 4 post(s)
Inconsistency In U Direction For Texture Mapping And dPdu

Edited after finding the error in the previous post

There definitely seems to be an inconsistency in the U direction for texture mapping and the U direction for dPdu.

When I applied a world map as texture to the squares it came out the same way on both.

This made me go back to Blender and start playing. When I applied a simple image as a texture within Blender, the images showed the same way round on both squares (viewed from above - screenshot attached). So I looked at the OBJ file again, redrew the diagram, and spotted the mistake I'd made with texture vertices 6 and 8 (see red note in previous post).

This means that the world map displaying the same way on both squares seems to be correct, since the U and V directions when viewed from above are the same on both.

There's a new puzzle - Why is the V direction (as drawn from the OBJ files) opposite to the V direction I've drawn on the world map, and in my simple UV-axes image? (Edit:this may be because I overlooked the 'Z Forward'conversion that occurred when exporting the OBJ from Blender)


Edited by user Saturday, April 23, 2016 11:56:56 AM(UTC)  | Reason: Not specified

3dcheapskate attached the following image(s):
whaaatttt.jpg
uvInBlender.jpg
edit2.jpg
I'm still on Poser 9 and/or PP2014...
3dcheapskate  
#31 Posted : Saturday, April 23, 2016 1:39:24 AM(UTC)
3dcheapskate

Rank: Advanced Member

Joined: 3/18/2016(UTC)
Posts: 220

Thanks: 6 times
Was thanked: 4 time(s) in 4 post(s)
Originally Posted by: bagginsbill Go to Quoted Post
...Note - I tried 5 times to write k to the power x using superscript. The editor showed it right, but the page did not.


I hate UI software engineers. They are almost uniformly incompetent.

I had to use double astersk ... k ** x means k to the power x.



OT: I think I worked out why you couldn't get superscript to work. If you edit a post and only change formatting, then nothing gets changed. You have to also make a change to the text. Also I've just noticed that strikeout simply doesn't work.

Edited by user Saturday, April 23, 2016 4:11:20 AM(UTC)  | Reason: Not specified

I'm still on Poser 9 and/or PP2014...
3dcheapskate  
#32 Posted : Saturday, April 23, 2016 5:01:23 AM(UTC)
3dcheapskate

Rank: Advanced Member

Joined: 3/18/2016(UTC)
Posts: 220

Thanks: 6 times
Was thanked: 4 time(s) in 4 post(s)
After Many Corrections To Posts 29 And 30 It Still Looks As If I Have Strange Behaviour Of dPdu In A Simple Test Case

Having gone through several corrections and rewrites of posts 29 and 30 I think I now have a very simple test case.
Edit: I think the key to understianding this is probably the relationship between winding direction, normal direction, and U direction. Note that the normal is facing DOWNWARDS, i.e. along Blender's -ve Z-axis (the cyan line), which is Poser's -ve Y-axis (the plane is invisible from above in preview).

And dPdu is behaving strangely.

I'm 99% certain that this square should render red, not blue - as you increase U you are moving along the +ve world X-axis direction (red), and the Y (green) and Z (blue) values of the points you trace do not change.

I've double checked for all sorts of mistakes, but I may still have missed something

Edited by user Sunday, April 24, 2016 10:33:50 PM(UTC)  | Reason: Not specified

3dcheapskate attached the following image(s):
Oddsquare.jpg
I'm still on Poser 9 and/or PP2014...
3dcheapskate  
#33 Posted : Sunday, April 24, 2016 11:42:38 PM(UTC)
3dcheapskate

Rank: Advanced Member

Joined: 3/18/2016(UTC)
Posts: 220

Thanks: 6 times
Was thanked: 4 time(s) in 4 post(s)
(Forgetting about the blue square problem from the previous post for the time being. I think that may be a problem with geometries created in a specific, unusual way, and not generally observed. Except by me. Sod&#39;s law)



Is dPdu Actually Just The Tangent To The Surface ?



Tangent as in perpendicular to the normal.



The fact that dPdu is with respect to the U direction would mean it&#39;s not quite that straightforward.



Here&#39;s my latest understanding in pictures...

(Edit 14June2016: Going back to the Poser 9 Reference Manual, this matches the definition in Chapter 16 Material Room Nodes on page 350 which says that "The dPdu node represents a varying point surface shader variable. It is a vector perpendicular to the surface normal in the ā€˜Uā€™ direction. Specifically, it indicates the derivative of the surface position along ā€˜Uā€™. It has no user-definable attributes.")

Edited by user Monday, June 13, 2016 11:26:39 PM(UTC)  | Reason: Not specified

3dcheapskate attached the following image(s):
1A-Mesh.jpg
1B-Renders.jpg
1C-Theory.jpg
1D-Summary.jpg
I'm still on Poser 9 and/or PP2014...
3dcheapskate  
#34 Posted : Monday, April 25, 2016 1:56:23 AM(UTC)
3dcheapskate

Rank: Advanced Member

Joined: 3/18/2016(UTC)
Posts: 220

Thanks: 6 times
Was thanked: 4 time(s) in 4 post(s)
Trying To Find The Magnitude Of dPdu

I decided to try and work out exactly what the magnitude of dPdu is, and succeeded.

To start with I created a simple shader to take any single positive number between 0 and 9,999,999,999 as an input

Edit: I've tidied the shader up an uploaded it at ShareCG here http://www.sharecg.com/v/84834/gallery/11/Poser/Ten-Digit-Visualizer-Poser-MT5 and I've deleted stuff from this post that's more about the shader than dPdu tests.

For the tests here I plugged the X component of dPdu ('Component' value of the 'Comp' node set to zero) into 'Value_1' of 'NUMBER_TO_VIZUALIZE', and set 'Value_1' to a million. So the number being displayed was 1,000,000 times the X component of dPdu.

For the screenshot I disconnected 'Value_1' and enter 9876543210 (Poser changed it to 9876543488, so there's an 8 digit accuracy limit or something like that)

Edited by user Friday, April 29, 2016 4:24:25 AM(UTC)  | Reason: Not specified

3dcheapskate attached the following image(s):
TenDigit.jpg
I'm still on Poser 9 and/or PP2014...
3dcheapskate  
#35 Posted : Monday, April 25, 2016 2:30:26 AM(UTC)
3dcheapskate

Rank: Advanced Member

Joined: 3/18/2016(UTC)
Posts: 220

Thanks: 6 times
Was thanked: 4 time(s) in 4 post(s)
Unexpected Variation Of dPdu With Camera Position

I really hope I've done something stupid again...

The plane is 4 vertices / 1 face, 10.312" x 10.312", and is placed perfectly horizontal at the origin.
U direction is the same as the world X axis.

Andy is shifted backwards sufficiently to not obscure the plane

The number displayed on the plane is one million times the absolute value (I added an extra node) of the X component of dPdu.

I expected it to be a fixed value for these renders. (I could of course have got something messed up in the shader)


Note: the two renders that show the same value of 3493935 had the camera directly above the origin, facing straight down, but with different y rotations.

Edited by user Monday, April 25, 2016 3:15:07 AM(UTC)  | Reason: Not specified

3dcheapskate attached the following image(s):
UnexpectedVariation.jpg
I'm still on Poser 9 and/or PP2014...
3dcheapskate  
#36 Posted : Monday, April 25, 2016 3:10:39 AM(UTC)
3dcheapskate

Rank: Advanced Member

Joined: 3/18/2016(UTC)
Posts: 220

Thanks: 6 times
Was thanked: 4 time(s) in 4 post(s)
Brief Sidestep To See If My Shader Can Sort Out Du For Me. It Can't. Or Maybe It Can ?

Back in post 11 I tried checking whether Du was linear using the render colour, but ran into problems.

With this new shader I can actually display the value of Du.

So I did three renders with the main camera at different positions and Du plugged into my shader.

Combined screenshot of a couple of renders, table below showing a few more results, and a graph of these results.

Ht/Wdth Du x 1M
170 5952
206 5208
278 3676
319 3125
380 2840
533 1953

There's a trend, but it doesn't look like any obvious function.

Edit (16 June 2016): Based on a new simple equation these results are all within about 1% of the expected values ! See post #49 for details.

Edited by user Thursday, June 16, 2016 8:34:44 AM(UTC)  | Reason: Not specified

3dcheapskate attached the following image(s):
DuTest2.jpg
DuGraph.jpg
I'm still on Poser 9 and/or PP2014...
3dcheapskate  
#37 Posted : Monday, April 25, 2016 4:30:54 AM(UTC)
3dcheapskate

Rank: Advanced Member

Joined: 3/18/2016(UTC)
Posts: 220

Thanks: 6 times
Was thanked: 4 time(s) in 4 post(s)
Multiple Step Function In dPdu As You Move The Camera Closer !?!?

I tried a similar test to the previous post, but with the X component of dPdu instead of Du.

                                

I'm really at a loss now as far as magnitude of the dPdu vector is concerned.
It seems that the quantization effect that I thought I saw in the shades of grey for my Du tests back in post 11 wasn't just my imagination.

However, I think that I'm on the right track with the DIRECTION of the dPdu vector - it does seem to be the tangent to the surface, aligned in some way with the U direction of the UV mapping (post 33)

Edited by user Monday, April 25, 2016 4:44:09 AM(UTC)  | Reason: Not specified

3dcheapskate attached the following image(s):
Confusion-StepFunctions.jpg
I'm still on Poser 9 and/or PP2014...
3dcheapskate  
#38 Posted : Wednesday, April 27, 2016 1:37:25 AM(UTC)
3dcheapskate

Rank: Advanced Member

Joined: 3/18/2016(UTC)
Posts: 220

Thanks: 6 times
Was thanked: 4 time(s) in 4 post(s)
Working on the principle that if you ignore a problem for long enough it'll go away I'm going to forget about blue cylinders and step functions for a while...

Do Bump, Displacement, And Normal Maps Affect These Nodes ?


Displacement maps actually move the points of the surface - so I'd expect them to affect N, dNdu, P and dPdu
Bump and normal just affect the surface normal at each point, not the points themselves - so I'd expect them to affect N and dNdu.

I did another simple test.

Bump and displacement maps seem to operate as expected.

However, normal maps seen to have no effect.
Or the scale at which they have an effect is too small to see in this test - but even multiplying N x 1,000,000 the plane renders totally green if I plug N into ambient, so I don't think it's the scale.

Edited by user Wednesday, April 27, 2016 1:48:52 AM(UTC)  | Reason: Not specified

3dcheapskate attached the following image(s):
BumpDispNormTest.jpg
I'm still on Poser 9 and/or PP2014...
3dcheapskate  
#39 Posted : Thursday, May 5, 2016 2:18:20 AM(UTC)
3dcheapskate

Rank: Advanced Member

Joined: 3/18/2016(UTC)
Posts: 220

Thanks: 6 times
Was thanked: 4 time(s) in 4 post(s)
I haven't abandoned this - I'm just off on a sidetrack trying to improve the 10 digit visualizer.

The apparent step function in dPdu is really puzzling me. Since I also thought I saw a step function earlier in Du I've been wondering if maybe the magnitude of dPdu is actually dependent on Du? If so, then explaining the step function in Du may be an essential first step?

I'm also wondering if the step function is perhaps due to the rounding errors inherent in the IEEE754 representation of the numbers, as mentioned in the Accuracy Of Numeric Values In Nodes thread ?
I'm still on Poser 9 and/or PP2014...
3dcheapskate  
#40 Posted : Monday, May 9, 2016 2:47:37 AM(UTC)
3dcheapskate

Rank: Advanced Member

Joined: 3/18/2016(UTC)
Posts: 220

Thanks: 6 times
Was thanked: 4 time(s) in 4 post(s)
Looking At Du Again - And There's That Step Function Again...

I've got a slightly improved visualizer now, so I did a quick test in PP2014. I put my single face square at the origin and applied my shader to it, plugging Du in as the number I want to see (multiplied by a million as the new shader just shows integers). I used the top camera and changed the Scale in steps of 10% from 10% to 120%, rendered, and noted the green number on the render (most were very clear, but those that were not, such as the one on the screenshot, I marked with a '?'). I then plotted a graph. It seemed a straight line with a kink at the top right, but two points (60% and 70%, which I'd marked with a '?') were way off. I then took some more readings near these points.

This is really odd. I definitely don't trust my shader 100%, but I can't get rid of that gut feeling that something is seriously wrong with Du... I hope I'm wrong.

Note: I had Poser full screen on my laptop, rendering to the preview size. If I change the preview window size the green numbers change. If I set a fixed render size the green numbers change. And while changing render size and top camera scale I got a green 10416 again - it seems that Du likes to be 0.010416. (My shader quite happily displays 10415 and 10417 if I set the value manually, so I don't think my shader's causing this preference for 10416)

Edited by user Monday, May 9, 2016 3:00:44 AM(UTC)  | Reason: Not specified

3dcheapskate attached the following image(s):
test.jpg
Results.jpg
I'm still on Poser 9 and/or PP2014...
Users browsing this topic
Guest (4)
4 Pages<1234>
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

Notification

Icon
Error