MDL normal/position brick -- any way to rotate?

Oso3D

So both the Normal and Position brick are tantalizing... but they are based on normals. So, basically, everything is rotated 45 degrees from vertical.

Any easy way to shift the coordinate system to get results aligned with the scene vertical?

 

hphoenix

Will,

Not sure what you are trying to describe doing here.  The surface normal in MDL is exactly that.  The perpendicular direction from the surface at the point in question (on that surface geometry.)  The normal won't be 'rotated' within an MDL shader, as it's just the raw geometry based normal calculated (LERPed across the polygon from it's vertex normals.)

There are plenty of geometric and vector math operations available in MDL, but I need to understand what you are trying to accomplish....

 

Oso3D

Ok, baffling.

 

So I'm using the Normal brick (Bricks > Functions > MDL > state > Normal) and pulling out the Y component (Float3 [I] with val 1)

This is piped to Cutout Opacity.

 

Ok, great. Except no matter what I do, the blasted output makes this weird shadow copy on the reverse side. Which is weird, because there are no values I can directly put to Cutout Opacity that creates the same effect.

I've tried to use Clamp, if/then statements, all sorts of stuff to ensure that the only output values are 0-1. Buuuut nope.

If I square the result, I can turn the shadow into a regular opaque value, which seemed to me like there might be an imaginary component or... something, but nothing seems to work.

Like, if I pipe 'is the normal Y value less than 0?' to cutout, I get the expected 'black/0' on the upper half, 'white/1' on the lower half. That logic is solid. Then I try to make a conditional so that if it's less than 0, use direct value 0.

And the shadow appears anyway. Which it shouldn't. Whaaaaaaaat

 

Anyone have a clue why this might be?

Example output attached.

 

Oso3D

Or, more simply, what range of values is Normal -> Float3 [I] (integer 1) actually returning?

It looks SORT of like +1 to -1, but I suspect there's something else going on. Like maybe the result is Float2 or something weird.

Is there a way to force it to return a float value?

 

hphoenix

Okay.  A normal is simply a vector with a magnitude of 1.0 that points directly AWAY from the surface (at that point on the surface.)

So any given axis can vary from -1.0 to +1.0.  But the square root of the sum of the squares of all three components WILL total 1.0  (this is what we refer to as a 'normalized' vector)

So what is happening is that for any normal.y value , the ones that point 'downward' will have a negative value, and you are getting a cutout opacity that is outside 'valid' ranges.  I'm actually suprised it isn't clamped by Iray itself.  To force it to be non-negative, you'd want to either manually clamp the value (so that any value less than 0 is set to zero) or you could 'shift' it, by adding 1.0 to it, then dividing by 2 (moving the range from [-1.0,1.0] to [0.0, 1.0])

Normals should NOT be cast to integers.....they'll almost always be zero.  A normal is a float3, so what you want is to use an accessor to get a float from a float3.  In Shader Mixer, this is a "Float3 Get Y" brick (Bricks->Functions->MDL->Built-Ins->Types->Accessors->Float3->Float3 Get Y).  That brick takes a Point type, which is what the df::state:Normal outputs.  

As for the component value, You could use abs() to force it to be positive (inverting the sign of the negative values), you can clamp it, you can shift it, etc.  Just make sure your output range is valid for the input of your cutout opacity brick.

Oso3D

Get Y doesn't work, it crashes Daz Studio. Float3 [I] (val 1) works. I tried both of the suggestions you mentioned, which are very sensible approaches; they also don't work. Right now I'm going to try using squaring and logic to Frankenstein a solution. I do feel vindicated that my hunch that it was 'i' turns out to be correct...

hphoenix

If Float3GetY is crashing studio (outside of JUST this particular shader you are working on), PLEASE submit a bug report.  Might want to test Float3GetX and Float3GetZ as well.  Those are straight MDL (and should compile down to Float3[index] with index filled in.  If Shader Mixer is crashing on those, something is definitely WRONG.

Edit:  Just tested a quick check in 4.8, and they definitely crash it there.

Oso3D

Waaaaait a minute. It suddenly occurs to me... maybe that shadow is the backside of the INSIDE of the sphere... guh.

Ok, now how the heck do I manage that one. Hrm.

 

Oso3D

So now I need a way to distinguish inside surface from outside surface. Any ideas?

Edit: Oh duh! I can just use iray decals instead of geoshell! DUH DUH DUH

Problem solved.

 

hphoenix

You could also set the material to thin_walled, then assign the same material_surface to the backface....