Better Geoshell Procedure
Issue #862
resolved
UPDATED PROCEDURE:
I have successfully integrated full-body geoshells made of geometry nodes into my workflow.
First, create a default cube. In edit mode reset the UVs to helps see what you’re doing. Create five materials on this cube. One is just transparency, the others should corresponde to the four main body parts of a figure – assuming Genesis 8. You can create more for the ears, lips, fingernails, toenails, but it works just as well folding them into the important maps. As another good thing it seems we don’t need to use Attribute nodes on the materials either. They show up just fine without them.
Parent the cube to the armature. This isn’t totally necessary since the geoshell will appear wherever the figure is, but if the origin is too far away it will probably lead to float errors if it’s translated a distance.
In the original post I used the figure as the geoshell source but I now realize that’s not necessary. It’s actually harmful because it needs to be evaluated on the figure which slows performance. Instead we’ll use the cube as our geoshell which can be easily disabled if we don’t need it.
Add a geometry node to the cube and create this node network. It looks more complicated than it is.
We don’t care about the cube’s geometry so just leave it unconnected. Instead bring in the Genesis figure’s geometry, run it through a Set Position node, and multiply the normal by a scalar to push the geoshell away from the skin. The figure and the scalar are both exposed in the modifier stack for ease.
The nodes below that are material selection nodes chained together with boolean math nodes.
Run the geometry through a chain of Set material nodes. Plug the selection sets we made with the materials fed in from the modifier stack. You can assign the materials directly here if you want but I exposed them in the modifier stack to make them swappable easily. All the materials the geoshell shouldn’t affect (mainly the eyes) go into the final one with the cube’s transparency material.
Since the cube is very low-poly the geonodes evaluation is very fast. Posing is very quick, even in Workbench mode.
ORIGINAL POST:
To help with my workflow I decided to take the plunge into Geometry Nodes, and I quickly discovered that replicating geoshells is almost trivial.
Take the geometry input and split it in half. Run one end through a Set Position node, then join them back together. The Set Position node lets you move a mesh’s individual vertices according to the inputs. Take the normal attribute to move the vertices along their facing direction and run it through a Vector Math node to determine how far the shell should be offset, then plug that into the Set Position’s offset socket. Finally run the shell branch of the node tree through multiple Replace Material nodes, one for each material zone, to swap the materials out. The material lookup is global so they don’t even have to be assigned to the object.
This workflow needs more testing for efficiency and gotchas, but it works.
You can also expose the offset and the material zones in the modifier stack so this workflow is fully parameterized.
One caveat is that Geometry Nodes don’t play nice with UVs. When you do this the UVs will collapse and repeat the first pixel all over the object. This can be fixed by replacing the Texture Coordinate node in the Shader Editor with an Attribute node pointing to the UV Map. Although it seems like the same thing as a UV Map node, the UV Map node only works in Cycles. To use this in Eevee or Workbench, every material of the underlying geometry must use the Attribute node (until hopefully the devs fix it).
The ability to load geoshells from Duf files and put them onto the modifier stack with parameterized controls would IMO be a much more efficient solution than the pre-Blender 3.0 procedure of exporting them with the figure and cramming them into an already-convoluted node tree.
Since Geometry Nodes can also procedurally add and delete geometry (even on linked figures, which normally block mesh editing), I believe they can be used to create geografts without needing to merge them to the base mesh, though I’m not sure how yet.
Comments (41)
-
-
reporter
Have to disagree. If I’m doing sequential art and I want to make a character’s skin dirty or wet for one scene only I think it’s much more elegant to simply add a modifier to the stack, rather than have to open up the figure’s material settings and add more nodes, more drivers, more custom properties. Especially since you can’t do that with linked characters, but you can add a modifier to them.
I agree the older way should be kept as an option, though.
-
repo owner
Interesting. I have heard about geometry nodes but never digged deeper into the subject. The old way of adding nodes to the materials will not go away, because it
- Exists and is debugged.
- Is probably more efficient.
- Works with Blender 2.92 which officially supports Win 7.
But geometry nodes could be an option in the future. Thanks for letting us know.
-
Personally in this case I agree with everyone. The current way is more efficient and back compatible, then geometry nodes would open up new possibilities. I may add a few notes.
- In daz studio shells get a geometry so in some few cases the geometry is needed because it’s not only to layer materials. Though in most cases it is.
- As for refractive shells we use some tricks with the add shader to get them in blender that doesn’t always work perfect. Having a separate geometry shell would allow to simply use a refractive material with better results.
- As for geografts if there’s a way to graft them with geometry nodes without deleting the graft area, this will allow to load morphs before or after grafting without any special vertex table, thus improving performances if I understand correctly what Thomas did.
- On the other side, as Xin says, having unnecessary geometry just to layer materials does affect the rendering and vewport speed, other than memory. So the current way is more efficient.
- To reply M.A. about the dirty layer, the current workaround is to use the shell influence that is also keyframable so you can animate it. Though I understand to be able to add a shell just in the current scene may have its benefits.
edit. It is also interesting what M.A. reports about uv maps, I wonder if this has something to do with why we can’t see shells in the material preview.
-
reporter
I tested making non-destructive geografts and it works up to a point.
- Create a vertex group covering the graft area.
- Feed that into the geometry nodes modifier.
- Use the vertex group as the selection for a delete geometry node.
- Bring the geograft mesh in with the object info node and plug both into a join geometry node.
As long as both are parented to the same armature the geograft will be posed exactly the same as the area it replaces. But there’s no way to weld the vertices together that I could see so it has ugly shading seams all around it. There is a weld modifier that works okay if you put it right after the geometry nodes modifier and create another vertex group to limit its influence. But weld works by a distance threshold, so you need to micromanage it to make sure it’s big enough the seams don’t tear open but small enough that it doesn’t collapse the whole mesh. Also the viewport performance is absolutely terrible, though judging by the Blender 3.1 release notes that’s geometry nodes all over.
Apparently the Blender devs are porting over the weld modifier functionality into geometry nodes right now. A few releases down the line it may be possible to make non-destructive geografts but it’s only a kludge at the moment.
-
repo owner
The geograft mesh contains info about which vertices should be masked and welded, so that could be converted into vertex groups. The welding distance should not be a problem, because the vertices on the geograft boundary are moved to the exact location of the matching body vertices.
-
reporter
Geometry nodes only work on the mesh the modifier is actually attached to. The geograft’s mesh is duplicated and added to the figure’s mesh. The original geograft mesh needs to be hidden like how the importer treats environment instances.
-
reporter
I'm making a project that requires a character to swap makeup. Since makeup sits on the skin and not inside it it’s a perfect use case for geoshells, so I worked out a workflow to apply makeup nondestructively. This may also help with issues in the comments of
#857.The usual caveats about geometry nodes – terrible viewport performance, all materials need Attribute nodes, etc. – still apply.
As before you take the geometry and split it with one feeding into a Set Position node that offsets it from the skin before you join them back up. The material selection node holds the material the makeup should be applied to. The map range node inverts the selection (I couldn’t find an invert node like the shader editor has) and gets fed to a delete node which removes all the geometry except the surface we want to use. Then we feed the material’s selection into the material node to select which areas we want to assign the makeup to.
This works in both Cycles and Eevee. You need a dummy plane or cube to make the Daz materials before using them in geometry nodes. If using Eevee make sure to set the material’s alpha too or else it’ll just be black.
I used an offset of 0.001 for testing but the Cycles image shows it’s too far from the skin so a better value would be 0.00010 or 0.00005. As with all geometry nodes you can parameterize this by connecting sockets to the group input so they show up in the modifier stack. I kept them all inside the node tree to make it clear what’s happening.
Edit
You can invert a selection with the “boolean math” node, so the map range node isn’t necessary. You can also use the boolean math node to OR together different materials into one selection set.
-
The makeup is already “non destructive“ since it’s a separate node in the material setup.
-
reporter
It’s “nondestructive” in that it doesn’t require permanently editing your material setup. Once you create the skin material you don’t need to touch it again. You can insert a makeup node as needed even if it’s a linked figure.
-
You can keyframe the makeup fac if you need to switch off a makeup or change it during animation.
-
reporter
The issue is makeup is not skin so it shouldn’t be part of a skin shader. The Iray Uber shader is parameterized so it’s not hard to swap makeup textures inside Daz Studio but converting to Blender means hardcoding unnecessary textures into the material which means less robust and more cluttered, especially if you make sequential art and don’t know which makeup textures you want to use later.
-
What do you mean ? DAZ studio can’t animate materials as blender does so if you need to swap a makeup during animation you simply can’t. You need the “cluttered“ blender materials for that. Unless I misunderstand what you’re looking for.
-
reporter
I’m looking for the ability to add decals (like makeup) without adding unnecessary nodes to a figure’s skin shaders.
I can do it manually but it’d be more efficient if the Diffeomorphic bridge could load them from a Duf file.
-
I do not follow you here. Both decals and LIEs and makeups are material nodes in daz studio. So they are supported and added as material nodes in blender. They are not “unneccessary“. Then shells are optimized as material nodes to avoid the extra geometry, since they’re usually just a material layer in iray. Because iray can’t support layered materials so needs a geometry layer, while blender doesn’t.
Then Thomas added, on your idea that I second, the tool to load materials so you can mix and animate new makeups as well as anything else. By keyframing channels as explained above.
What are you complaining at precisely ? That is, what it is that you can’t do with the current implementation ?
-
reporter
Suppose you link a character into two separate files. If you want to have the figure with two different decals in either file you need to go into the source file and add two separate node groups.
Now suppose you’re making a webcomic or visual novel and you need to keep adding new ones until you have twenty, thirty, forty node groups in your skin shader, none of which are actually skin and therefore don’t belong in a skin shader.
It used to be that was the only way to do things. But geometry nodes added in 3.0 gives us a better way. We don’t need that pointless, unnecessary bloat anymore (unless we’re using legacy versions of Blender.) We can add decal shaders on a scene-by-scene basis and don’t need to make permanent edits to our source files.
-
Have you tried the new Asset Browser? it was designed for that. For example, you have a base material, then you create a new material from it and add layers to it, then you store it in the asset browser. Or you just create a new material altogether. Then you can drag and drop the material from the asset browser to whatever you want them applied to.
I think that workflow might suit your needs, and it’s way better on performance than having to evaluate geometry nodes and create new geometry. Using materials is the preferred option since you want a responsive viewport and you don’t want to consume so much memory for just a material layer.
-
reporter
Geometry nodes are modifiers. Just disable them in the viewport and leave them enabled in the render. There’s no performance hit for an inactive modifier.
-
@Midnight For this case I second Xin, using a set of materials seems the easy way to me rather than using geometry nodes. Then there are cases where geometry nodes are useful for new features as in your other suggestions.
That said personally I have nothing against other options to do things. That is for Thomas do decide of course.
-
repo owner
I think engetu once suggested that one could use a duplicate mesh for shells, because there are situations that cannot be handled well with material nodes. Unfortunately I cannot find his bug report, and I don’t remember exactly what the setup was, but using geometry nodes seems a lot more attractive than duplicating the mesh. However, material nodes will remain the default option, because it exists and is light-weight and works well in most cases. Something with geometry nodes may happen in the future, but I need to learn more about them first.
-
-
reporter
Something with geometry nodes may happen in the future, but I need to learn more about them first.
Yes, that’s why I’m documenting what I learn, to help with that.
Case in point, a geonodes setup replicating Aeon Soul’s Skin Effects. I only did the face and torso for expedience but the other material zones can be easily added with a few more nodes.
-
reporter
- edited description
-
reporter
- edited description
-
reporter
Today I had to create a geoshell that only affected the face. I found it was easier to just use a Material Selection node as the boolean for a Delete Geometry node and delete everything but the face. So that’s one way the workflow can be optimized.
-
repo owner
There is now an experimental implementation of shells with geometry nodes. It is controlled by the global option Shell Method. However, there are still at least two glaring defects:
- If the shell material is visible but transparent, the result is black. Presumably the shell is casting shadows, but I haven’t been able to remove that.
- Some UV layers are missing, e.g. for Golden Palace.
-
repo owner
- attached shells.duf
Here is an example where the shell is transparent and the legs become black.
-
reporter
The issue with your test scene is geonodes can destroy UV maps sometimes. The “black” is the first pixel of the texture repeating all over. If you need to use geonodes on a figure, all the figure’s shaders should have their Tetxure Coordinate and UV Map nodes replaced with Attribute nodes using the name of the UV map.
But I strongly recommend using the workflow in my first post where the geoshell is a cube parented to the armature.
- Since it’s not part of the figure, the figure’s UV maps are not affected like your test scene.
- Easy access to materials. In the test scene I had to create a cube just to inspect them. But using a cube, it can hold them all for ease of use.
- Easy access to geometry. If the geoshell is a separate object it can be easily selected and hidden with H, for instance, instead of going into the modifier stack.
- No posing lag. Since the figure doesn’t have a geonodes, there’s none of the lag associated with evaluating it on such a heavy figure.
I’ll look into getting it to work with geografts too.
-
reporter
I tested it with default Genesis 8 anatomical elements and a wet skin geoshell. UVs seemed to carried over fine. I changed the shaders to have Attribute nodes and geografted it with geometry nodes, but didn’t notice any issues.
-
repo owner
All issues should be fixed now, I think. The shell is an empty mesh rather than a cube, just as it is in DS.
-
reporter
Still some issues:
- Trying to load unmorphed straight from a Duf file doesn’t do anything.
-
Importing from a DBZ does work. The materials all have red warnings for their UV Maps. This doesn’t matter because when it joins part of the figure it’ll auto-associate to the correct UVs but it may confuse people into thinking something is wrong. Using an Attribute node instead of a UV Map node avoids this, and is the new “standardized” way to use materials with geonodes since Blender is shifting away from hardcoded datatypes like UVs.
-
The figure has ugly red skin in solid shaded mode. Just an aesthetic nitpick.
- The geoshall has multiple empty material slots. However ruynning the “Remove Empty Material Slots” command will delete all of them since none of the geograft is technically “using” them.
- Trying to import materials with the figure selected will also overwrite the geoshell’s matertials. I think it uses a simple name lookup? There should probably be logic to limit that to the selected figure only.
-
repo owner
Some of the issues have been addressed:
- UV set nodes are replaced by attribute nodes.
- Shells, and empty meshes in general, are now assigned the skin viewport color rather than the clothes color.
To avoid that shell materials are accidentally removed, the shell could be a hidden cone with sufficiently many sides, and assign each material to one of them. Or one could simply refrain from removing empty slots in this case. There are many pitfalls in Blender, and this plugin cannot prevent all of them.
-
reporter
The empty slots aren’t that big a deal honestly.
-
As for keeping the shell materials, doesn’t it work to set a fake user ?
-
reporter
Since the materials are assigned to a materials slot they won’t be deleted. It just looks unattractive to have a list of 16 material slots where half are blank.
-
repo owner
One can now load geografts and shells directly from the DS database, and geografts can be merged. However, geograft materials are grey (at least for GP), because to give them textures the copy materials script must be run in DS. The materials must thus be replaced by the torso material by hand in Blender.
The Advanced Setup > Mesh > Add Shell tool adds a geometry nodes modifier to the shell. The shell mesh must be active and the geograft selected, because apparently Blender does not allow an empty mesh to be selected. One should perhaps add some error checking so the number of materials match.
Do you have an example of a shell that generates empty material slots? I tested with GP2 and the file attached above, and all slots are filled in those cases. Slots should not be generated if visibility is turned off.
-
reporter
I tested it out and here’s what I see:
- I still think the geoshell should be a cube or plane instead of an empty mesh. It’s so much easier to examine the material that way. Otherwise you can’t debug it visually until you load it onto the figure which warps it and incurs shader compilation delay (in Eevee).
- The materials load but they all have “*.001” after their names instead of “-2” or “-3”. In cases there somebody might want multiple geoshells it may be more useful to have a prompt asking people to name the geoshell, and that name is automatically assigned to the geoshell and its materials.
- If there’s missing slots the material assignment is all wrong. The first few are fine but the “gap” causes issues. I haven’t figured yet out a way to check for null references inside geonodes so there’s no way to switch materials if a slot is empty. So empty slots must get a transparency material to avoid showing up as white.
For this and all my other expeirments I used this geoshell:
https://www.daz3d.com/skin-effects-dirt-for-genesis-3-and-8-females
-
repo owner
Empty material slots should be gone now.
The empty shell mesh is actually exactly the empty mesh specified in the duf file. So building the shell doesn’t involve any special code, but is exactly what it is in DS. If you want a visible representation of it, a new button that makes a palette was introduced recently. It’s called Make Material Set or something similar.
-
repo owner
Shells can be added both to geografts and the main body, and work reasonably well in simple cases. Multiple shells do not work well, but that is tricky in DS as well.
If we load geografts (specifically GP2) and shells directly from the DS database, the geograft materials are grey and the shell is not related to the geograft. To fix this there are two new tools in the Advanced Material section:
- Replace Node Trees: Replace the node trees of the selected geograft materials with a different node tree, e.g. the Torso tree. This does the same that GP2 Material Copy does in DS.
- Add Shell: Connects the shell mesh to the body or geograft by creating the geometry nodes modifier.
Merge Geografts switches the target for the shell modifiers from geograft to main body, to avoid a boundary between the shell and body. Seems to be some problems with UVs, will investigate more later.
Make Material Set has been renamed Make Palette. It was originally meant to store materials for the asset browser, but can also be used to visualize shell materials if you turn off the Mark As Asset option.
There are some performance issues. Shells seem ok, but merging geografts non-destructively seems very expensive.
I will write something about this in my blog once the dust has settled.
-
Just a couple notes if it may help.
1. As for “add shell“, in daz studio the geograft shell is always added to the figure, not to the geograft. That is, first the geograft is merged to the figure, and will share the same uv maps as the figure, and eventually copy the materials. Then the shell is added to the merged figure. The shell geometry is not merged, just overlayed, and will have its own uv maps and materials. Indeed the reason why we use shells in daz studio is because iray can’t layer materials/uv maps as blender does.
As for multiple shells we have to set the surfaces visibility and layer offset depending on what we want to render. That’s imported from daz studio if we use the shell in the daz scene, but will need the plugin tools if the shell is created in blender. We already have a “import daz material“
#857that may fit for shells too.2. Then “replace node trees“ may be renamed “copy material“ as a less technical and more user friendly name, that’s also the same as the geograft script in daz studio.
3. If the shell is created as geometry nodes it may be possible to add the visibility by “face groups” the same as daz studio, since the material shells can’t and will only have visibility by “surfaces“. We already use a hidden material to mimic the node visibility in daz studio
#516
-
- changed status to resolved
This is implemented and there are no news, please reopen if you have improvements.
Bugs can be addressed apart for better handling.
- Log in to comment
Good to know about this, but I think the current solution, using material nodes, is better. Having materials all over weird pieces of geometry that shouldn’t exist is not elegant and quickly gets ugly to handle. It can also lead to render issues on top of wasting memory. The daz way is quite sloppy, it’s yet another weird limitation of daz. I know of no software other than daz that layers materials like that.
So I hope the current solution is kept, no matter what Thomas decides to do.