Is there a foolproof way of allowing a basemesh in a geometry node setup to be visible, but not have it become of part of mesh operations when other modifiers are added to the modifier stack?
Details:
I have a couple geometry node setups that do not use the base mesh (mesh primitive with geometry node applied) in the mesh operations, but having the base mesh visible makes them easier to adjust (size, scale, rotation, location).
So I have a switch to the toggle visibility of the base mesh on/off (ie. plug the original geometry into a join geometry node at the end of the node tree) in each of the modifier setups.
Now let’s say I stack multiple modifiers on top of each other and each has its own toggle for base mesh visibility.
If I forget to toggle the visibility of the base mesh off, it becomes a part of the mesh calculations for any modifiers that are added to the stack. That’s normal…and the current solution is to not forget to toggle them off.
I’m wondering if there is some other way (an attribute, vertex grouping or something) to keep the base mesh from influencing or being influenced by any modifiers that are added below it?
…I’m willing to consider ideas, even if it means adding another modifier at the bottom of the stack that says “ignore the basemesh” or “ignore any mesh with these attributes…”).
Thanks as always! I appreciate your help or any insights you may have.
One thing that I’ve considered is combining these modifiers into a single geometry node setup, but they are not simple setups (particularly the group input options/settings) and I think they may hold more value being able to be used separately.
Afterthought: if there was some way to toggle input settings based on which branch of a setup is selected it would make things more “workable”, but I’m pretty sure that’s not currently possible (it would be nice if it was). The new collapsible panels options in Blender are super nice, but the downside is that all input options are always visible regardless of what input choices you’ve made. For example, if I choose “method 1” (of 3) to distribute points on a mesh, I want to only see the input settings for method 1 in the UI… not every method.
No it’s not possible by default, you have to come up with your own conventions to handle that. It’s hard to give you a precise solution without a concrete example, but that something I ran into in some projects.
Generally I add an attribute for the basemesh and in each modifier I separate it so I process only what I need and I can still use the basemesh if needed.
Doing that, you’ll need another modifier at the end of the stack that will get rid of it if needed.
Probably once you know there is no other way then it’s easier to come up with a workflow that fit your case But yeah it’s mainly about tagging geometry early and having a set of modifiers that “speaks” the same language by using the same attributes…
Well you cant reference the unmodified object itself in a single last gn setup in the stack, what would a be much nicer isolated solution ( if I got you right and you really want the geoms inputmesh), but if its really just for reference, why dont you simply go to edit mode while tweaking your nodes params. That will give you a ghosted version of your input mesh as “overlay”.
This is definitely outside-the-box thinking which I appreciate. I can see it working in some people’s cases, but in mine, I don’t want to alter the base mesh via mesh edits as it will then throw off whatever adjustments I make (scale, rotation, etc). But I do love the idea of the ghosted overlay and actually wish there was a setting for that. Thank you.
I didnt mean you shall edit your mesh. I thought what you want is about tweaking the nodes params and you want to see the inputmesh while you tweak them, thats what you can do in edit mode aswell. But if you want to edit the objects transform itself I think I didnt get what you are about to do.
Ahhh, I misunderstood! That makes sense. I appreciate the clarification. And also the reminder that this is possible!
For my purposes, I don’t think this is any “simpler” than remembering to toggle off the visibility of the basemesh in the group input settings, but I can see it as a valid solution in some cases!
Yeah ok sorry. If you still want to discuss it at least for me you’d need to describe it in more detail. Its still not clear to me, but maybe sozap got it better than me.
Still…
Well, it might not be what you want, but if you have eg three separate gn-setups you can leave all those setups separate and still embed them as each as a SINGLE NODE in a new additional GN nodesetup to have them combined aswell.
No dynamic param hiding isnt possible. So the only thing you can do is to group those values that belong eg to method3 in its own panel and collapse it if you are eg currently using method 2 instead. ( So for 3 combined methods you’d have 4 panels Shared-Values, Method1, Method2, Method3)
No worries. I’ll try to take some screenshots that explain it the next time I’m working on it.
This is a great idea and sounds much more efficient than what I was originally thinking of doing.
I’m still relatively new to building GN setups, so some of my methods are definitely sloppy vs efficient. So it’s good to be reminded of better ways of doing something.
That’s cool ! I’m not 100% sure but I think this is planned in the long term.
One of the goal of geometry nodes is to be able to replace current modifiers by GN setups, which asks for a lot of improvements in GN modifier’s UI. It’s a long way but I’m pretty sure making some context sensitive parameters is part of the solution to provide better UI/UX.
But yeah it’s mainly about tagging geometry early and having a set of modifiers that “speaks” the same language by using the same attributes…
I put in