Soft Selection based on angle of neighboring faces?

Deprecated Stoke MX v2.x Beta Discussion
1

(Originally posted on the Genome board - move here!)

Hello,

Is there a way to drive a soft selection based on the angle of neighboring faces?

I’m thinking that each face normal is compared to every face with which it shares an edge/vert - Then using a curve you could ‘tweak’ which angle values that you want 100% selected vs. a soft selection falloff for the angles that you want les selected.

I’m thinking this would need to be some kind of selection loop? Let me know if this seems like a possibility with Genome.

Thanks!
Bob Dyce

2

Here is my quick attempt to do this.
GNM_SoftSelByFaceAngle_Max2013_v001.zip (40.6 KB)
I used a Vertex iteration with a FaceByVertex loop inside where I collect one minus the Dot Products of the Vertex Normal with each face’s normal into a single value, and then use that as the Selection after passing the value through a scaling factor and an optional Curve control.

When two normals are parallel, the Dot Product is 1.0, so 1-1 is 0 = no selection. If any of the face normals of the surrounding faces of the vertex is a bit or a lot off, the Dot Product will reflect that. Right now I am using the Absolute of the Dot Product which is not exactly right (DotProduct of -1 means the faces are pointing in opposite directions). Feel free to improve. When the angle between the normals is very tiny (e.g. after adding a TurboSmooth it might get difficult to get selection values close to 1.0), you can boost the selection using the Strength scale value.

In Genome 1.1, you can now expose a checkbox to turn a node on or off. So I have done that to make the Curve optional.

Note that the LoopChannel: FaceNormal inside the loop node needs a FromWorld conversion because it is now in World Space by default. It used to be Object Space before. This is As Designed since the mesh could be not only the current mesh, but any external mesh, and we have to keep that consistent.

3

Right on!

So I’ve updated my license and installed Stoke.

It throws plugin DLL errors when I launch max (Duplicate id). I noticed that while I can add a Genome Modifier, I cannot launch the magma editor.
Should I be launching the magma editor through stoke now?

Thanks,
Bob Dyce

4

Genome is now in the Stoke DLO. You must remove your old Genome from the plugin.ini file (or use Genome’s uninstall).
Quite possibly the old Genome loaded first and then collided with the Stoke 2 plugin which has the same ID.

5

Got it - I just removed the genome folder and everything is working perfectly! Thanks.

The Curve selection modifier works great - and simpler than I thought it would be.

Thank you!
Bob Dyce

6

Bobo - Something odd I noticed:

If I save out the flow you created, then take a different piece of geometry, add a genome mod and load up the flow, it does not work. It seems that the FaceLoopByVertex node is broken. When I go into ‘Edit LOOP body’, the part of the flow that should be in the loop body is missing. I tried to pasting in the nodes from your flow right into the new loop body, and hooked eveything up, but it still throws errors.

Strangely, if i just copy and paste the genome modifier from the geometry to the other, it works fine. Saving the flow and reapplying to new genome mod seems to break it. Any ideas?

Thanks,
Bob Dyce

7

Yeah, Tobbe discovered this problem the other day. It is a bug and is fixed internally. Attached are the fixed scripts. Please let me know if they fix the problem (just replace the scripts in the …\Thinkbox\Stoke MX\Scripts\ folder)
Stoke_Scripts_Update_20140404.zip (33.6 KB)

8

I replaced the scripts, re-saved out the flow, applied the new flow to new geometry but it still does not work.
It looks like the nodes within the loop body are there. In the main flow, FaceLoopByVertex is red has and claims it has an issue with Accumulator 1 being unconnected. It was not connected in your original version.

B

9

This looks like a different bug. Thanks for the report!
You can solve this easily by connecting an InputValue node before saving to provide the start up value of the Accumulator.

In my original flow, I used the ability of a Loop node to define custom default values (see the Default>> button in the Loop’s UI). There you can set it to 0, 0.0, [0,0,0] or quat 0 0 0 0. But that default data is not being saved currently (my bad), and is thus not loading. But if you connect a 0.0 node to the socket, it will save and load.

I will fix the saving bug, in the mean time, just connect an explicit value to the Accumulator.

10

Turns out the code was more or less there, but the order of execution in the Loop’s recreation was a bit wrong.
I just moved the setting of default values to happen later on and it fixed it.
Stoke_Scripts_Update_20140404b.zip (33.6 KB)