Code halp? Normals making SHADOW DEMONS or something
Oso3D
Posts: 15,085
in The Commons
So I have cool code that can produce stuff on the tops of other stuff. Basically, Normals are piped to Cutout so that the layer is opaque at the top but transparent everywhere else.
Buuuut I keep getting this weird Upside Down effect; there is this black shadow dimension appearing.
Which doesn't make sense. The code should only be returning a result between 0 and 1. I've tried using Abs, squaring it, doing all sorts of weird stuff, but... it keeps stubbornly sending out DEMON SNOW.
Anyone have a clue where to start poking?
The top bit of this image looks right. The bottom bit has me shouting and scaring the dog.
What the what.png
1000 x 1000 - 801K

Comments
Does that weird effect seem to 'move' as you rotate the camera in the viewport? I had a weird issue when I was testing some custom textures on DAZ's spheres too, in that a texture would literally overlap onto itself. I believe it may have something to do with how DAZ unwraps its spherical primitives... not sure though. The only way I got around it was to use a cube or plane primitive.
I hope that helps? :)
I don't know anything about the code you're using, Will. However, I did notice the black at the bottom of the sphere is a mirror image of the snow on the top. Seems like that should tell you something, though I have no idea what... Also, have you tried using another shape? Something that isn't closed, like one of your mountains"?
Still happening. However, it occurs to me that giving geo shells a slight nudge upward eliminates the problem in the vast majority of cases. Sooo... hey, that works.
Perhaps somebody could help more if you posted the relevant MDL code, or the relevant bricks/connections you're using in Shader Mixer. Also, keep in mind that there are different kinds of normals (tangent space, etc.). This may, or may not, be playing a part - it's hard to tell without more info.
- Greg
Here's the relevant shader. (It's going to be part of a free pack, so hey)
Basically, there's two 'terrain edge' inputs, upper and lower, defining the transition from opaque to transparent on the Normal Y value (which ranges 1 to -1)
Clamp the Normal Y output to that min/max.
Subtract the minimum. (So the value should be, at this point, a minimum of 0)
Divide by the difference between max and min.
The result should be a range of values between 0 and 1, with anything below a certain threshold just flattened to 0, and anything above to 1.
And it works fine until you get into the mirrorverse part at the bottom.
I have no clue why.
Just to confirm, this is what I'm getting when I apply it to a blank spherical primitive...
edit: I actually can't open the shader in Shader Mixer, it's asking for another file format?
Uuuh. Hmm.
How about this?
https://dl.dropboxusercontent.com/u/803826/Snow Cover.dbm
I actually managed to figure out how to import it into Shader Mixer -- took me a while to remember it too! -- but this works too, thanks!
I tested it further, and... not sure if it's something on my end, but I'm not getting the Shadow Realm underneath. However, it clears any material that's already present, which is something you don't want it to do, I presume...
edit: More data: applying it to a geoshell makes it an opaque white sphere...? I hope this helps :)
Got a chuckle when I tried to open the DUF. After getting the "Error opening file" message, I checked the log only to see the following:
2016-56-01 08:56:54.773 *** Scene Cleared ***
2016-56-01 08:56:54.778 Error reading file, see log for more details.
I think DS is messin with me lol.
Anyway, I opened up your dbm file, and after looking at it, my initial thoughts are as follows (FWIW):
1. For a standard sphere, tangent space normals are always facing away/outward from the surface, so this component of the vector is always positive. The tangent space normal is the same for the top of the sphere as the bottom of the sphere, even though they are facing opposite directions. Are you sure that the normal value you are getting is the tangent space, or is it adjusted for the particular geometry it's applied to? At the bottom of the sphere, the tangent space normal is still "positive" (facing away/out), but in object or world space, it is facing down.
2. I think you may be assuming that the "Y" component you are getting is the component facing away/out, but it's not (for normal maps encoded in RGB). The 3rd component is the one pointing straight up relative to the mesh.
Sorry I don't have more time, but I hope this helps (again, FWIW).
- Greg
I actually want the component for pointing up -- I'm trying to get an effect where the tops of things are filtered relative to sides (snowcaps, etc).
Mind you, I'm finding the shadow effect doesn't come up in the vast majority of cases, and in other cases the fact it goes on a geoshell offers a simple fix (IE: increasing Y a little)
mtl: Yeah, I should have specified that this is for geoshells on stuff, and replacing material is intended -- it's a procedural shader. (You CAN keep some image maps if needed)
I would agree with this too. Applying the shader to a cube-shape is one way to see this effect very clearly.
@timmins.william ahhh okay. I wonder why my geo-shell test didn't work then, hmm.
Actually, I don't think that comment I made was relevant as the normal brick you are using is not returning the rgb from a normal map. Sorry about that - it was early and I hadn't had enough coffee yet lol.
I think what we need to do is find out exactly what the vector being returned by the normal brick, though - specifically, what space (tangent, texture, world, object, etc.).
- Greg
What's confusing me is that I keep using Clamp to force a value between 0 and 1... and clearly that isn't working.
Is there a way to force a possibly float2/3/?? to be float1?
So when I reversed things by taking the result and doing 1-Value, which SHOULD return 0-1, I get the shadow effect.
What I'm confused about is what would cause cutout to return blackness; if I turn off limits and set cutout opacity to -1000 or something, it's just... transparent. But somehow... maybe there's something about the mapping brick that kills bad results that are being exposed by piping directly to cutout opacity. hrm
Edit: Nope. If I hand -1000 direct value to cutout opacity, it's simply just transparent. Hrm .What would make it act shadowy?
I'm not sure if there are truncation/rounding bricks in the Shader Mixer, but you can use that to force floats, perhaps? Modulus works too, if the brick exists...
I thought that perhaps it was an imaginary number, tried squaring it. Still same result.
Maybe it's an infinite number, so used 'isfinite' check to assume 0 if it's not finite. Nope.