2
$\begingroup$

I've been trying to develop a camera based shader where half of the area of an object is in one color and the other half of is in another. It has to function the same way after a deformation, which is where the issue is. I've drawn some sketches to demonstrate what I'm imagining: theory The rotations in this image would happen as deformations, not as object rotations.

In the associated blend file I've put my best attempts and a mockup of how this would work: 3

4

2

The issue with this mockup is that I've had to create a separate material and a ghost camera to go along with it. This is no good because I'd like to have just one material that I can put on any shape.

Since I'd like to use this for characters it might be better to to base it on the UV map instead of the normals? They already have a direction built into them. Like so: 5 I also tried this theory with Greater Than/Less Than nodes but I can't figure out the mathematics for it.

Improve this question
$\endgroup$
4
  • 1
    $\begingroup$ Not sure if I'll be able to give exact answer, but: seems like "camera based" is a wrong lead. If object space and camera remain the same, rotating a sphere should have no effect. Seems like you just want to bake a world space normal map at rest position, then take its red component remapped from [-1;1] to [0;1]. It's close to what you're doing in the "old normals" shader. $\endgroup$
    – chedap
    Commented Feb 2, 2023 at 16:29
  • $\begingroup$ I'm not sure on the title either but I am sure I want the camera/viewpoint to influence the effect. In my sketch, if you compare the front view and side view of either object you'll see that they are the same. This is because the effect would adapt to the new view angle, comparable to a fresnel effect. $\endgroup$
    – Brockoli Bruce
    Commented Feb 2, 2023 at 17:24
  • 1
    $\begingroup$ 1) why does the color become flat on the first image? 2) By "The rotations in this image would happen as deformations, not as object rotations." do you mean the rotations would happen in Edit Mode or via a modifier, and therefore the shader wouldn't have the access to the rotations value? 3) Based on the mockups it seems what you're after is that the shading follows the camera (the shader coordinate space rotates together with the camera), but only in regards to Z rotation - do I get it right? $\endgroup$
    – Markus von Broady
    Commented Feb 4, 2023 at 23:46
  • $\begingroup$ 1) The "flat" tag was just to indicate that that's the bottom flat plane of the cylinder. 2) Via a modifier like an armature deform, like it is in the mockup. 3) Yes, that's right! Though that would be the relative Z rotation for the faces. $\endgroup$
    – Brockoli Bruce
    Commented Feb 5, 2023 at 7:29

3 Answers 3

Reset to default
2
+50
$\begingroup$

To be frank, I'm not sure I understood your problem enough, but I believe if anything I have something to contribute:

video

This example is controlled with 2 material slots, but in application it should be controlled by setting vertex colors to the vector along which the effect should be applied. This vector would go into the 'dot product'

Unfortunately, you can't 'protect' normals by storing them, because that breaks the correlation between position and normal.

nodegraph

Improve this answer
$\endgroup$
1
  • $\begingroup$ Every effort is appreciated! I recreated this with one material and added in the colors to indicate the directions like you said, it does work smoothly. So with this, all that's needed would be a way to automatically enter the current direction per point/face, right? $\endgroup$
    – Brockoli Bruce
    Commented Feb 5, 2023 at 7:50
1
$\begingroup$

Is this what you had in mind? vec_transform
I'm not sure what "hollow" is supposed to mean. A sphere from top down is split just the same as it is from the front.
Note that this requires verts to be split at sharp edges (like your cylinder already was). I thought storing face corner normals would work, but it doesn't (faces end up faceted). There's probably a solution, but I'm inexperienced with GeoNodes.

For more camera-based normal transform stuff, you could look up questions about recreating MatCap in Eevee/Cycles.

Improve this answer
$\endgroup$
6
  • $\begingroup$ My bad, the "hollow" tag was there by accident, I removed it in the image. Your technique works more smoothly than what I have and works well for the default rotations, but does not work quite like I'm imagining for the rotated meshes. However you have given me some insight on how to explain this better, I'll update the question. $\endgroup$
    – Brockoli Bruce
    Commented Feb 3, 2023 at 5:59
  • 1
    $\begingroup$ You should clarify how exactly my attempt differs from your expectations. Is the issue in view direction vs angle of incidence? Or do you actually want shading controlled by a third "projector" object, rather than the current view / render camera? $\endgroup$
    – chedap
    Commented Feb 3, 2023 at 9:52
  • 1
    $\begingroup$ Regarding your UV suggestion: that's the idea behind tangent-space normal maps. Think about how taking the U coordinate would(n't) work on the poles. For seamless behavior, they are mapped onto geometry tangents. A Normal Map node with flat color as input will simply output geometry normals. But we already have those, the only issue is that we need them in their past, pre-deformed state. So UVs would only be relevant for us if we were baking a world-space normal map instead of storing vertex normals through GeoNodes. It would serve the same purpose. $\endgroup$
    – chedap
    Commented Feb 3, 2023 at 9:52
  • $\begingroup$ The poles are a concern. I think in my scenario it's best for the effect not to work there, meaning it should be 50% like it is in the mockup. I've updated the mockup in the file, I imagine the effect as you see it there. As you can see with the rotated/deformed shapes the effect works differently from your version, because in the mockup the effect stays aimed towards the camera. When applying your method to the rotated shapes the effect turns away (up and around) when dollying the camera horizontally around the objects. $\endgroup$
    – Brockoli Bruce
    Commented Feb 3, 2023 at 12:14
  • 1
    $\begingroup$ Sorry, I still don't get it. To me it just seems like the mockup variant breaks the desired behavior by distorting the output for any camera angle that isn't level with the object. While in mine, the deformed geometry always matches the non-deformed, except for new rotation. I don't see any difference from mockup gifs. Some of this may help, but I doubt I can do much else here. $\endgroup$
    – chedap
    Commented Feb 4, 2023 at 11:43
1
$\begingroup$

By building upon sybog64's great suggestion I was able to figure out a way. The only thing that was missing from it was a way to enter the shape's directions (not the normals) into the "Dot Product" node. Here's how I've added this:

Since we can't easily access the bone data from within Geometry Nodes (yet) I added in a small plane inside each shape and attached it to the respective bones:

1

The normal data from this plane is then transferred to all nearest points:

2

This data is then fed into sybog64's shader:

3

Which results in the desired shader:

4

This works very well, though it would be even better if we could simply use the bone data somehow and avoid using the Sample Nearest node, which doesn't work as well when the shapes get too close to eachother.

Improve this answer
$\endgroup$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .