Bug: Persistent On Mesh Snap not working with 3D Face Tool

I’ve tried repeating and I’m not seeing anything to suggest other than Persistent on Mesh not working with the 3DFace. This is in both Single face and Multiple Face modes of 3DFace. Seems fine in 6.27.20147.8371, 26/05/2020, example is in 7.0.20147.12475, 26/05/2020. OnMesh tooltip disappears after the first pick.

Whilst on the topic, maybe it would be good to extend persistent options to SubDs too, for ‘draw on’ options as well. (take a vote on whether a SubD is a surface (extract surface) or a mesh…) - actually, I see it works as a polysurface already which is cool.

Also, Cursor Tooltip > Command Prompt disappear after orbiting the camera. Maybe that’s by design. But the command prompt tooltip remains after orbiting if it has another tooltip alongside, such as ‘point’.

Do you see the same behavior in other working display modes?
Have you customized this display mode?

We need the specifics so we can duplicate the problem here.

Hi,

Repeated in Shaded mode. It’s not to do with display modes at all. The tooltip shows the persistent snap disappearing and no longer being taken into account for successive picks of 3DFace.

Technically I suppose it’s a regression since it’s fine in v6. I aven’t managed to get any permutation of 3DFace working (output, mode)

I’m getting the same behavior in V6 and V7.
When I first turn on the Persistent On Mesh Osnap, I choose a mesh.
As I draw my curve, the tooltip shows.
When I finish the curve and start over I do not see the tooltip unless I turn on Persistent On Mesh again.

I do not see a regression.
That said, I never use these tools.

What am I missing?

Yeah - the curve shows how it should work. That’s why I posted two examples; with a tool where it works, and one where it doesn’t.

Then run the 3DFace tool. Use the Persistent On Mesh. Select a Mesh. Only the first point will register On Mesh, making it not so persistent.

This is the clearest I can make it. Behaviour in Rhino 6 then Rhino WIP, of the 3DFace tool. (the latest build, (7.0.20147.12475, 26/05/2020)).

Interestingly, the OnMesh re-set works like a POnMesh.
And choosing PonMesh does not perform its function, it seems an error.

Exactly. PonMesh is working like a one shot. But not in Rhino6. And with 3DFace, but curve tools seem okay.

https://mcneel.myjetbrains.com/youtrack/issue/RH-58879

1 Like

I know, but it can be repeated several times, it will turn out as PonMesh. :slightly_smiling_face:

Hopefully it can just be fixed to it’s state in Rhino 6 :stuck_out_tongue:

Thanks @John_Brock

No idea. A lot of code has changed in V7 that users will never be aware of.

This is one I’m still aware of. I think it would be really important to get this working still. As a side note for the report, this also doesn’t work on Polysurfaces, when you’re drawing a 3DFace. So the PersistentOnSrf/Polysrf, is actually just persistent for one pick…

Please post a small example file and details.

Example with persistent on Polysurface and Persistent on Surface. First pick is fine and recognises the surface. Then it dies for all further picks. Ideally, the persistent snap would work and then apply to all faces made in a single turn of the 3DFace command (such as pulling an adjacent face with From Edge). I think it’s important for trying to combine the two geometry types.

As noted by the title, it’s also not Persistent with meshes. Simple manual retopo is impossible if you want draw topology.

But that’s not a Surface or a Mesh.
That’s a SubD.

I retotpo is your goal, you can mesh the part then use the snap to mesh with subd faces-

BUT… unless you need a specific patch layout- quadremesh can get home in a lot of circumstances.

A SubD is accepted as valid input for the first point. That’s shown in the video clear as day. A SubD is recognised as a surface in many commands. There’s a NURBS surface we can get at underneath as we all know here.

It’s here below in black and white. Polyline, persistent on polysurface snap. This accepts the SubD limit surface beneath.

For sure. So long as we agree that it’s a bug and that my observation is indeed correct, it’s all good with me.

I would not call this a bug for two reasons:

  • The osnaps were not designed with SubDs in mind
  • SubD is still under active development.

@theoutside is the SubD guy here. I suspect this feature enhancement will be added to the list.

1 Like

Yeah that’s true. We can split the difference at it’s ‘incomplete’ then, let’s say, since as I’ve shown the snaps are well respected already such as in the polyline example. But it is a problem inside 3DFace anyway.

1 Like