Morph curves - following a mesh deformation

(ilemaitre) #1

Hello everyone,
It’s my first time on this forum and after having struggled for a good couple of weeks to find a solution (and failed), you guys might be my saviors!

Here is the situation:
First, I have a closed brep, composed of planar surfaces.
Then, I have two meshes:

  • the original one, obtained from meshing the closed brep. The mesh faces are thus planar (normally).
  • the deformed one, which was obtained by moving the vertices of the first one. This way, both meshes have the same number of faces but most importantly, the faces’ indices are matching. Meaning that face 3 of mesh 2 is exactly the deformation of face 3 of mesh 1.

I have then generated a number of curves on the surfaces of the closed brep. They were generated with metaball isocurves, so precision might be a bit off where the different planar curves seem to touch.
(I was able to find a C# script that allowed me to perform a join by playing on the tolerance used by the ‘join’ function. However, joining in this way might have me loose the planarity of the different sections of the curves, so I don’t think this should be used.)

To have the curves be ‘projected’ in some way from the 1st mesh to the 2nd deformed one. Mathematically, I’d like to have the isomorphism that was applied to the mesh, applied to the curves.

I was carefull not to remesh anything (though it would give me better looking results) when deforming the mesh, to keep the face indexing as explained before. My idea was:
For each face of the 1 mesh, get the portions of curves that are within its boundaries.
Then remapping these portions onto the corresponding face of the deformed mesh.
Ideally, the planarity of the original portions on the faces of the undeformed mesh should garanty the continuity of the portions once remapped on the deformed mesh.

So … I’m pretty much out of ideas and I’ve trying every angle I could think of to tackle the problem but I’m not getting any further these last few days.

When I do my deformation, and then also try to do some dynamic relaxation with Kangaroo but without remeshing, I haven’t had much luck … If someone wants to take a look, I left this part in the GH script. Any help on that part will be greatly appreciated too :slight_smile:

Here are some photos and the GH file and corresponding rhino file.
The meshing and deformation process are included. The red groups are the WIP … The relevant elements for the PB are in the green group.

ForForum_Dance Pavilion.3dm (244.5 KB) (87.3 KB)

(Pfotiad0) #2

Well … first things first:

Isolate the issue and just imagine that you have a quad mesh face (or a tri face) with some curves. Then imagine that you deform one vertex (per step). This is what you’ll get: (116.8 KB)

Now … the only thing missing is an approach to do that interactively (i.e. deforming mesh vertices by just picking them) and thus morphing curves that belong to the affected faces (prior - after). This (including history of your actions: recall a given deformation at any given state etc etc) is impossible without code.

(ilemaitre) #3

Wow, thanks a lot!

I didn’t know about this type of morph, nor that you could manipulate it like that in code! It took me a little time but I’ve managed it ! I don’t know C# but I wrote everything in Python (mostly using Rhino objects directly), works just as fine !
The dynamic part I had trouble with is fixed too by the way, I managed that on my own :slight_smile:

Many thanks again!

(Pfotiad0) #4

See attached as well:

Mesh_ModifyVertex_And_ClassifySections_V1.3dm (748.5 KB) (140.6 KB)

The interactive (BTW: this IS the core of the matter: the 99.999% of the whole case) part is not implemented since there’s a question about what exactly to implement: EITHER the cause of your curves on faces is present (i.e. various breps “cutting” the mesh [in fact the brep from it]) OR you have them by some miracle in place (and cutters are MIA) and you want them to “follow” each vertex deformation per cycle (This means that you must classify your curves on a per face basis and apply the morph only to ones related with the affected faces - see 2nd C#).

For the core of the matter: each time that someting in GH executes it yields volatile data in the sense that they are “destroyed” in the next cycle. You need to store them as persistent in some (or more) parameter(s) and extract the related data as input for the next cycle prior it executes. Is very simple (at least with code) … but if you think about it is a bit more complicated if you want to keep track on all of your variants etc etc (meaning using trees and the likes).

PS: A variant of the 1st C# could answer your other recent thread: just get rid of the static [i.e. a-cyclic] aspect of GH , learn how to interactively do things [i.e. fuse you with the computer] … and off you go.

(ilemaitre) #5

Hi Peter and thanks again for the answers.

Maybe I had a poor choice of words: when saying dynamic, I was thinking about kangaroo: the deformed mesh had to undergo a dynamic relaxation, for a more physically-correct representation. But as I analysed meshes more and more, it appeared that the errors I encountered were due to the mesh being a tiny bit wrecked (non manifold edges and 0-area faces). Once this was fixed (with a more delicate approach with code), the problem went away :slight_smile:

The other problem I am encountering is not exactly the technical “how” of moving the faces, I had already managed to write down some code doing so (though more error-prone than yours, I’ll admit :sweat_smile:). The face classification I had made as well.
My real problem would be more (refering to the 2nd post of this night): “how to choose which vertex of the mesh to move, and where to move it to in order to reach the goal, without wrecking the mesh ?”
(Fit deformed mesh to its original Brep shape)
I have been trying considerations such as looking the faces that are not contained in one of the surfaces of the base shape brep and keeping an update list of that throughout the script, then considering faces where only one vertex had to be moved (ie already 2 vertices on a same surface and the 3rd one on another surface), etc. not very successful.
At least not totally: for a good number of faces fixed, I get a few number of completely broken (and without any means of fixing them as the tolology of the mesh looses itself when it gets broken).

But a solution you seem to offer would be to do it manually (since my already attained result is humanly workable) and move the vertices one by one, taking care myself of moving them in order not to wreck the mesh. The “getting rid of the static aspect of GH”.
However, for this part I have not understood how it could work, with the example scripts you posted :confused:

Would you have any further explanations, or suggested paths ?
Many thanks !

EDIT: I will just go and edit the mesh manually in Rhino with a little PointsOn actually, much simple and could have saved me a couple of days work …
Still interested in the interactive aspect however!

(Pfotiad0) #6

Because no interactive solution is implemented. I’ll provide a simple C# based example on that matter soon with regard modifying mesh vertices (and assuming that tthe “cutters” are present).

In the mean time think: assume that you have a blob with 666 faces and you want to do something on each one (or in some) based on specific aesthetic (or other) criteria - per face. How to do it? One way is to use 666 sliders … the other is the interactive thingy.

Or assume that you have a 2d grid (in x/y) of 666 points and you want to modify the Z on a per point basis etc etc. In other words the essence of contemporary engineering: mix manual with computer assisted work (and keep track of what you are doing).