Prism Morphing

[Ben44 (Ben)]

Hi Everyone. I’ve had a series of components I’ve developed for a while now and thought it would be great to share them out widely. These are based on/build upon the widely used twisted box morphing components, seeking to expand what we can do to alternative shapes (a prism).

They work in roughly the same way - input a reference prism, a reference geometry, and a target prism - and receive a morphed geometry:

Why do this? Well in my experience I’ve found many designers like to create lattices and other sets of twisted boxes from base meshes, either extruding, or tweening, or whatever. The issue with this, is it limits us to quad meshes.

With this tool, I’m hoping to give people a chance to play with other mesh types. For example a grid made entirely of Tris can become:

More exciting - this let’s us MUCH more easily create lattice structures which are conformal to their intended shape. Where in the past if you wanted to mesh an irregular shape with quads, something would have to be weird - either a lot of distortion, or some clipping of the mesh.

In this case, we can mix quads and tris and get some really nice lattices which conform to the shape. Here’s a really quick demo I made of a midsole, showing how you can be quad driven and maintain uniformity by including tris.

^prisms are in red

Anyway. I’m finishing up my first round of the toolbox and am looking for some feedback. Please let me know what you think! Looking forward to releasing it soon.

[Volker_Rakow]

Does it actually do prisms or just tris?

[Ben44 (Ben)]

Not sure I understand the question exactly.

Technically, what’s happening is we’re splitting all the prisms into tris along the w coordinate and remapping to the new design space.

But the input is a new data type “prism” (vs a box or twisted box). I have a few components to create these, ranging from

A basic construct component:

to stuff you’d see in pufferfish like a prism tween meshes component

and a few more

I guess the way I’m thinking about this is that it’s an alternative method for unit cell population, since I very rarely see anyone use anything besides crystallon or pufferfish. ideally, I’d like for them to have equivalent components so they can be used together. I’ll plan to release something in the next few days and hopefully people can try it out. I’m mostly just looking to solicit advice and feedback, since I think this is pretty useful

[Volker_Rakow]

@Ben44

Technically, what’s happening is we’re splitting all the prisms into tris along the w coordinate and remapping to the new design space.

This won’t have the same effect as morphing a regular polygonal prism of other base point counts to their twisted counterpart. It is already possible, if unwieldy, to do tris mapping with a degenerate box in Grasshopper. But keep on working on it. Excited to see your result.

[Ben44 (Ben)]

@Volker_Rakow

a regular polygonal prism of other base point counts

Other than 3? You mean an ngon with an arbitrary number of vertices? so not a tri?

@Volker_Rakow

It is already possible, if unwieldy, to do tris mapping with a degenerate box in Grasshopper.

Note. Although in my testing I do not get the expected mapping. Maybe I am doing something wrong?

With degenerate boxes:

With new prism component:

[DanielPiker]

There’s a prism morph class that uses generalised barycentric coordinates to smoothly morph between ngon prisms without triangulating as part of this component

Geometry/mesh into one continuous surface to populate bubbled hexagons along the surface

First to explain a bit how this new MorphToMesh component works- When you first place it on the canvas, it creates reference polygons, from triangle to octagon. These show you where to place your geometry. [image] You place any geometric objects you want to morph (curves, surfaces, breps, meshes etc) inside these. These geometry objects go into the G input of the component (it does not need to be in any particular order or data structure - the component figures out which geometry belongs t…

Here’s an example of how you can use this prism morph in a script

Cage edit command that can adapt to any form automatically

and here a (Rhino 8 only) example of the prism morph class I was mentioning above meshmorphexample.gh (15.9 KB) meshmorphexample2.gh (18.4 KB)

[Volker_Rakow]

@Ben44

With degenerate boxes:

With new prism component:

I see. Well, I thought it would work.

[Volker_Rakow]

Sorry, I am sure you love these kind of questions: after pulling MeshCageMorpher.gha to the Libraries folder and attempting to open meshmorphexample2.gh I get this:

[Ben44 (Ben)]

@Volker_Rakow Ha. I was dealing with the same thing. I updated for rh8:

meshmorphexample_rh8.gh (14.4 KB)

@DanielPiker -

I had never seen that before. Thank you for sharing. Back before chatgpt and Claude made all of this easy I spent probably a week figuring out how to construct prism morphing. Too bad it was already done

I suppose all I’m doing now is expanding a bit on how users might interact with prisms. Making dedicated components and containers.

[Volker_Rakow]

@Ben44

I suppose all I’m doing now is expanding a bit on how users might interact with prisms. Making dedicated components and containers.

Go for it! I think your use case:

@Ben44

will be mostly covered by Rhino 9’s Mesh Cage and MeshCageMorph2 components (what a horrendous name), but it stands to reason if there is a Triangle Mapping and Rectangle Mapping there should be a Tris Mapping counterpart to Box Mapping.

[DanielPiker]

Just adding a simpler example file. Also - in Rhino8 there’s no need to download the morph plugin as it is now a standard component.

prismmorphdemo.gh (30.3 KB)

[Volker_Rakow]

I am confused.

@DanielPiker

in Rhino8 there’s no need to download the morph plugin as it is now a standard component.

There is no “Morph” component in Rhino 8. I see now, that the MeshCageMorph2 component has wandered from Beta into Rhino8, but not the Mesh Cage component. What is the difference between Mesh Cage and MeshCageMorph2? Is it that MeshCageMorph2 uses closed meshes as reference and target meshes and Mesh Cage uses a “cage mesh”? If this is the difference, are both just standard meshes?

Still this is not the same as what is shown in the script. Which I don’t understand either. Here, a reference polyline maps to two (a targetInner and targetOuter) curves… If I have two target curves, why do I not need two source curves? Morph to Mesh I understand with its offset, but the script I can’t wrap my head around.

So very very confused.

[DanielPiker]

Sorry for the confusion.

In Rhino 8 there is a GH1 component (not a plugin) called MorphToMesh which morphs from reference polygons to prisms automatically created from each face or Ngon of a mesh as shown here and here. So you get a copy of the geometry in each cell of the mesh.

My script above shows how it is also possible to use this prism morphing directly from a script, so you control the individual prisms instead of them being automatically created from a mesh.

Like with box morph, the reference prism is always an extrusion of a flat polygon, and it defaults to one of unit height, which is why no reference input was needed in the script. You could add an input if you wanted, and apply the appropriate vertical scaling.

Mesh cage (and its earlier variants MeshCageMorph/MeshCageMorph2) is something entirely different, not so relevant to the discussion here about prisms, but to try and clear things up:

This morphs geometry from one mesh cage to another, where these meshes can have any topology, not just simple prisms.

Mesh Cage is now a standard component in GH1 in the WIP (not Rhino 8).

With this and all the variations previously shared in plugins, they take just a standard mesh for the reference and target. It is referred to as a cage because it was originally created as an alternative to the older Rhino Cage Morph.

These meshes should ideally be closed (it will not reject open meshes, and small holes usually aren’t a problem, but closed meshes will behave more predictably).

MeshCageMorph was the earliest version of the plugin, which works on a list of points.

MeshCageMorph2 was a later plugin, which works on any geometry including Breps and trimmed surfaces. However, the methods required for trimmed NURBS fitting prevent caching weights and make it very slow when the contents are things like meshes or SubDs where you can just move the control points.

Mesh Cage is the newer version in the WIP, which uses the faster method for meshes and SubDs, falling back to the slower fitted version for Breps.

[Volker_Rakow]

@DanielPiker thanks for taking the time.

What I understand from your explanation now, is that there is a method contained within Kangaroo utilities, that is used to drive the MorphtoMesh component and that can be accessed through a coding component to morph objects from a polyline to – not just a prism of that polyline, but – any non-linearly extruded “twisted” version of that polyline.

@DanielPiker

Like with box morph, the reference prism is always an extrusion of a flat polygon, and it defaults to one of unit height, which is why no reference input was needed in the script. You could add an input if you wanted, and apply the appropriate vertical scaling.

This was the missing piece of information or me. I assume you mean, that within the coding context of Box Morph, the reference prism is the extrusion of a rectangle in one unit of height, because for the casual user of Grasshopper (which I am), Box Morph is a component that when placed on the Grasshopper canvas is given a a reference box of a particular size, or does not work at all.

I’ve shied away from using MorphtoMesh because of an unfamiliarty with meshes and a confusion of what the tool-tip “Tri,Quad or Ngon mesh to morph to” on the Mesh input meant. (The typo of missing space after the comma behind “Tri” is not mine. It exists on the component) As far as I understood, Rhino meshes were only composed of tris and quads. I’m guessing now, that the N-gon faces of a mesh are searched for and interpreted by the MorphToMesh component and not some special type of mesh I have to create myself. That makes the referencing polygons of MorphToMesh odd though. What happens when there are faces with more than 8 sides? If MorpToMesh is scrutinizing a mesh for N-gons, can’t it discover and display only the relevant ones? Having to move my geometry to the reference polyline is cumbersome anyhow. It would be better if I could define reference prisms for my geometry “in situ” through some bounding prism component, and then provide the MorphToMesh with lists of bounding prisms and geometries to work with.

A prevalent scenario for which neither MorphToMesh or Mesh Cage is equipped to deal with is when you want to allocate geometries to the implicit cells between two open meshes of same typology. This occurs when you offset or shell a mesh:

Offset Waterman Meshes.gh (11.0 KB)

MorphToMesh handles this wrong because the resulting cells are not straight prisms.
Cage Mesh requires you to place all the geometries in a reference mesh that you would have to construct. I am not sure how I would deal with this task with the current native tools. A bunch of acrobatics, probably.

@DanielPiker

Mesh Cage is now a standard component in GH1 in the WIP (not Rhino 8). […] MeshCageMorph was the earliest version of the plugin, which works on a list of points. […] MeshCageMorph2 was a later plugin, which works on any geometry including Breps and trimmed surfaces.

I see. So all these plugins strewn about the forum in numerous threads are an evolution toward Mesh Cage, which is planned to be implemented in Rhino 9? Thanks for the clarification.

[DanielPiker]

@Volker_Rakow

MorphToMesh handles this wrong because the resulting cells are not straight prisms.

The target cells that MorphToMesh creates are not straight prisms, but tapered ones that match the edges of neighbouring cells, connecting a mesh to its offset, just like in your diagram.

However, I found a different issue with MorphToMesh - it currently works with either meshes of all Ngons(such as those from TriRemesh Dual output), or meshes of quads and tris, but I forgot to consider the case of mixed Ngons, quads and tris. I’ll get this fixed, but on reflection I do think that probably the more useful and flexible way going forward is keeping the n-sided prism morph as a separate thing, then doing the matching with other components.

Here’s an example of this for your Waterman example:

watermanmorph.gh (24.4 KB)

[Volker_Rakow]

@DanielPiker

The target cells that MorphToMesh creates are not straight prisms, but tapered ones that match the edges of neighbouring cells, connecting a mesh to its offset, just like in your diagram.

Ah, I see… Well. That’s egg on my face isn’t it? I don’t know why I assumed that MorphToMesh mapped to straight prisms. Certainly, if I had read the tooltip description of the Offset input and noticed it was an offset of the mesh’s vertices and not its faces, it would have given me a moment’s pause. On the other hand, you’ve been describing the cells that MorphToMesh maps to as “prisms”, which, if they are tapered to match neighbouring offsets of the mesh, they are not. Prisms are two congruent, parallel polygonal bases connected by parallelograms. But this may be you playing fast and loose with terminology and me taking things too literally in an attempt to understand things.

@DanielPiker

Here’s an example of this for your Waterman example:

Thank you for this. I assume the intention was to show how MorphToMesh can be used to solve my Waterman polyhedron example until the issue with mixed Ngons, quads and tris cropped up… So at least some good came of my confusion?

Looking at the result of the morphing, I noticed that the outer faces did not match up. Then I remembered that you explained, that the mapping begins with reference prisms that are 1 unit high, while the solids being morphed were extrusions of 2 units height. This returns me to the issue of scaling: neither by any available description of the MorphToMesh component or a naive intution of average Grasshopper user is it apparent how this works. Maybe a start would be to display prisms instead of polygon bases so the user can inuit “from this space to the cells of the offsetted mesh”. I, for some reason, thought that the geometry placed over the polygon bases would be morphed from their bounding height to the cells of the offsetted mesh. Providing reference prims instead of polygon bases would also give targets for “Prism Morphing” if this ever becomes a thing. Not that I think that this is better than being able to give MorphTo Mesh a list of reference prisms and geometries as described in my post above, but I’m sure you have your own idea of how thing should work best.

Just generally, MorphToMesh is suffering from trying to do too much at once. You want to bring geometry to reference base polygons, but have little control of how to match the two. You might have different geometries you want to map from prisms the same type to different faces of the same mesh, but have no ability to. The target cells (“twisted” prisms) of the offsetted mesh are a vertex offsetted mesh, although you might have wanted to morph to a edge offsetted or face offsetted mesh. Better to break these steps down.

[DanielPiker]

Hi Volker, sorry for the delayed follow up - I was away for a while.

“MorphToMesh is suffering from trying to do too much at once”

I agree with this, and was trying to express the same thing when I wrote

“on reflection I do think the more useful and flexible way going forward is keeping the n-sided prism morph as a separate thing, then doing the matching with other components.”

While it’s nice in theory to have a single component that does the whole job, in reality it became too inflexible.

So what I’m thinking going forward is to make the prism morph similar to the script in my last example a standard component. It’s still possible to use this to do all the face-side count matching that MorphToMesh does with a fairly simple definition, and easier to apply in more varied cases (such as choosing from multiple geometries for the same side-count, and allowing side counts of >8).

I also agree that if we’re being strict with terminology, this is a mapping from prisms to twisted prisms, much like how the ‘Box Morph’ component is a mapping from a box to a twisted box.

I can also change it to take a reference prism instead of always assuming unit height.

[Volker_Rakow]

@DanielPiker,

Thank you for taking the time to both read and respond to my posts.

@DanielPiker

So what I’m thinking going forward is to make the prism morph similar to the script in my last example a standard component. It’s still possible to use this to do all the face-side count matching that MorphToMesh does with a fairly simple definition, and easier to apply in more varied cases (such as choosing from multiple geometries for the same side-count, and allowing side counts of >8).

It is still not clear to me what it is that you intend to do by this description. From the sounds of it, you plan to off-shore the “prism morphing” function, maintaining the two target polylines as target inputs and changing the source polyline to a prism?.. And then do what with MorphToMesh?

---

At the risk of belabouring the point: there is already an established convention in Grasshopper of how mappings and morphs are done. Whether it is Box Morph, Triangle Mapping, or Sporph, you always begin with a “source” geometry, then set a “target” geometry, and finally provide the geometry that is to be mapped or morphed from the space of the source to the target geometry. The source and target geometries are of the same type, and give the mapping or morph its name.

How the source and target geometries are defined lives wholly outside of the the actual morphing. But this also means that you have to define new “prism” and “twisted prism” types on which Prism Morph can act because you do not want to be defining polygons for a prism morph. It is a “Prism Morph”… the user will expect to morph between prisms.

Think about how this is done with Box Morph. Some source boxes are defined through the surface primitive tools (Box 2Pt, Domain Box, etc… but most importantly Bounding Box). Then target boxes are defined. These target boxes can be regular boxes, created in the same way the source boxes were. Or they can be “twisted” boxes, created explicitly via the Twisted Box component or by using one of the more advanced components that creates twisted boxes from surfaces, such as Blend Box or Surface Box.

With the source and target boxes defined, Box Morph then takes geometry and morphs from the source to target geometries.

A Prism Morph needs to function in the same way not because of my opinion, but for the sake of consistency in an established paradigm. Users rely on this to intuit how to use the program. If they have used Box Morph but never Prism Morph, then they can rely on what they’ve already learned with Box Morph to understand how Prism Morph works.

This also answers the question of what the current MorphToMesh should be. It should be a component that creates twisted prisms from a mesh. Like how Blend Box or Surface Box creates twisted boxes from a surface.

---

I’m sorry if you already understand all of this and what I’ve written comes off as a rant. I just felt a need to be explicit in what I mean.

I hope you have a good day! I don’t plan to bother you with this again.