"Convert to Mesh" Modifier
Simple suggestion:
A Modifier that converts Text, Curve / Nurbs, and Meta objects to mesh Non-Destructively
(That is - A modifier version of the "Convert to Mesh" function)
To allow mesh modifiers to change underlying curve or text
(Additional from feedback below - Thanks):
This suggestion allows all modifiers to be allowed on any object. If any modifier requires a mesh, and the object it's placed on is not a mesh at this point in the stack, then a red warning in the modifier such as " This modifier requires a mesh " should show, and the modifier has no effect. Place a Convert to Mesh modifier above it and then it will work.
EDIT Please set this one as resolved as Geometry Nodes can now do this.
19 Comments
Everything needs to be a non destructive modifier in my opinion. Hopefully everything nodes will come to the rescue and free us from the hell that is destructive linear workflow.
This can be set as Resolved / Implemented (By Geometry Nodes)
Do you know about any tutorial or documentation how to apply Geometry nodes to Text objects to make them behave like meshes (e.g. suitable for boolean operations) with non-destructive editing?
This can be solved if we are allowed to use a mesh object boolean union modifier with Text/Curve object as reference. It would let us continue a non destructive workflow with all available mesh modifiers.
* @Henrik Goldsack * That's perhaps a little backwards.
To boolean you need another object for the interaction. What if you wanted to remesh a meta-object? You would need to create a dummy mesh, Union it to the Metaball, then remesh the result.
The intent is much clearer if you just Convert to Mesh, then Remesh.. Is it not?
* @ammusionist * I suggest using the boolean modifier on a separate mesh object to avoid UI confusion/clutter.
Lets say you have have surface/text/curve object. It has a limited set of modifiers.
Then you add the new remesh modifier. Does the list suddenly get access to all mesh modifiers, like displace? What if you then move the remesh modifier below displace modifier in the stack? Will you be denied from doing that? What if you remove remesh modifier? Do you remove all other modifiers that depend on it?
You need to describe how your remesh modifier should work in the ui.
I suggested using a dummy mesh with boolean, to avoid this UI conflict, so there is a clear difference between object types. Boolean operation will remesh the model, no need for a "Remesh/Convert to mesh" modifier.
In any case, I hope "Everything nodes" project will bring an alternative to the modifier stack and allow more complex non destructive methods.
* @Henrik Goldsack * I find your approach more complex than mine (Add more geometry to re-purpose Boolean ?) I may have confused you by referring to the "Remesh" modifier above.
Each Modifier should have its own distinct purpose, and this is a new purpose, so a new modifier is indicated.
You do, however, raise an interesting question, about availability of mesh modifiers.
I envisage if a modifier requires a mesh, and the object it's placed on is not a mesh at this point in the stack, then a red warning in the modifier such as " This modifier requires a mesh " should show, and the modifier has no effect. Place a Convert to Mesh modifier above it and then it will work.
Then all modifiers could be available for all objects. I will update my proposal to this effect.
I have little hope that I will see a new modifier for this purpose in 2.80, but it would be great if this suggestion ends up as a node in the new Modifier Nodes model!
* @ammusionist * Another UI issue is that a text/surface/etc object does not have the interface for vertex groups/uv maps/autosmoothing of normals etc. Some modifiers are depending on access to these settings.
So even with a dedicated "Convert to mesh" modifier, it should only be accessible on a dummy mesh object with a reference to non mesh object. I don't think the UI modifications are worth it for one modifier.
I agree that its not intuitive using a boolean modifier for that purpose. But it is already there. And it opens for more options such as intersect/difference with a mesh object and metaballs/surfaces.
Geometry Nodes do not fix this since they don't support 2D curves. See: blender.community/c/rightclickselect/mqNE/
I see no point. Make copy, convert, edit, save states with KTX mesh versions addon.
I would very much love this. Softimage had this natively and it was so very very useful.
What exactly would you gain by having such a modifier?
You can already use some modifiers on text objects and they're already implicitly converted to a mesh when you do so. That doesn't give you the ability to edit the components of the derived mesh, though. That would require something like an Edit Mesh modifier to do any of that... and that's a much bigger task.
* @Jason van Gumster * Thanks for the question. It would allow all of the mesh based modifiers to be used against a Text, Curve, or Meta based object.
* @Jason van Gumster * From my own personal workflow, I have an object I export for 3D Printing that contains a boolean text-derived mesh. If I want to change the text for a different print I have to delete the mesh, use a hidden text object to make the new caption, then change to a mesh (Keeping original for next time); re-mesh; boolean and export again.
Kind of wish I could just change the text !
* @ammusionist * So what you're primarily interested in is the ability to use more modifiers on text objects without manually converting, right?
* @Jason van Gumster * Correct. Like all modifier stacks, you would need to apply them before more sophisticated mesh manipulation.
* @Jason van Gumster * I'm not sure it is a big task at all to be fair. It's basically just creating an applied version of the modifier stack, storing it in memory/disc and then pointing to it. Very easy coding.
* @tibbyninja *
I look forward to seeing your patch, then. ;)
* @Jason van Gumster * I haven't coded in C++ in 25 years...mostly just enterprise applications recently plus some VEX, python, Hscript, and maxscript.
I really hope to get involved with blender coding in the future.....but I can confirm pointers are a very basic coding principle ;)