Fixes and optimizations for geometry shells
Issue #1020
closed
On import “Single Principled” is not assigning the correct textures to a geograft (dicktator on a G8M in this case), it automatically assigns the same texture as the torso. Trying to manually change what image is being used in the “image texture“ node has no effect. The node reads a different file name, but the image texture does not update in the viewport. For cycles or Eevee. Changing the UVmap in the “Object Data Properties“ tab also doesn’t fix the issue. The proper UVmap is applied, however, it is still using the torso texture.
I fully assume I am the idiot, but I’ve given up on trying to figure it out. Things work as they should with BSDF. I just like “Single Principled” as less complexity in the shader can help keep render times down. This is with version 1.6.2 downloaded on 5/31/2022. The version I downloaded on 4-30-2022 was not having this issue.
Comments (42)
-
repo owner
-
Or you can try the geometry node shell that should import both the figure and the shell with its own separate geometry and material. That should work with single principled.
I didn’t test node shells yet.
-
reporter
@Thomas Larson Ohhhhhh… duh. That makes total sense.
@Alessandro Padovani I haven’t messed with them either. Was kind one of the things I wanted to eventually play with. Guess now’s the time lol.
-
daz studio 4.15.0.30, blender 3.1.2, diffeomorphic 1.6.2.1023
This is related to
#862.I did a quick test on g8f with futalicious and it seems there are odd things. Unless I miss something.
- the node shell is not alpha mapped
- the node shell has no uv maps, thus the uv maps are not found in the shell materials
- merge materials doesn’t work with the node shell
steps:
- set geometry nodes for shells in the global settings
- import the test scene futa.duf with the single principled option, that’s g8f with futalicious
- merge rigs, then merge geografts with geometry nodes
- hide everything from rendering, but the futalicious shell
- render, the shell is not alpha mapped
-
- attached futa.duf
test scene for geometry nodes
-
update. SOLUTION
After playing around a little, the issue seems resolved if I delete the material selections from the shell. That is, deleting the selections everything works fine. So it seems the selections are both unuseful and harmful for some reason. No idea why, may be @Midnight can explain.
-
repo owner
It would be easy to remove the lines that create the material section nodes, but we better wait for Midnight’s opinion first.
-
I’m curious too to hear from @Midnight but it seems I can’t address him with the @. While we wait a couple of other minor notes.
1. SHELL SHADOWS
I see shadows are disabled for geometry shells. I agree this is generally convenient, but in daz studio the shells do cast shadows, so we may have it as an option. There’s a hidden parameter in daz for shell shadows but it seems it doesn't work and shadows are always casted.
2. SHELL OFFSET
Technically to multiply a scalar by a vector it is more appropriate the scale operator.
-
repo owner
Removing the material selection does not work well with the dust shell using in Midnight’s original post
#862. Without and with material selection below. The normal map nodes are red because the Base Female UVs are missing, but that does not seem to be a problem in this case.
-
Yes I was talking of geografts. Regular shells need the material selection, geografts don’t. That is, once we merge the geograft, both with a “destructive” merge or using geometry nodes, then we need to remove the selections from the shell.
As a side note it would be useful to have the “merge materials” tool working with geonode shells too. Since now it doesn’t. That’s point 3 above.
-
-
As another minor note, the input names in the geonode shell could be better. That is, the shell can be used both for props and figures so it’s not necessary a figure. Also we don’t need to name the material inputs, they’re already assigned to the shell materials. That is, the input name in blender denotes the input type, not its instanced value.
So more meaningful names would be as below.
-
update. BUG EXPLANATION
I may have understood why there’s a difference with the material selection. The issue is that when we merge geografts the shell geometry goes from the geograft to the merged figure. This follows what daz studio does, but then with the actual setup we don’t hide the non-geograft mesh from the shell as daz studio does.
A possible optimization is to stay with the geograft for the shell geometry. This doesn’t need the material selectors and reduces the geometry feeded to the shell, thus with better performances. Other than working fine while the actual setup doesn’t.
Also in daz studio a single shell can be shared among different geografts, that’s the case with the Meipe’s headlights for example, this case is not actually supported. So below it’s the setup for a new test scene futa-hl.duf, that’s G8F with futalicious plus headlights. Please note that the shell offset is done as a last pass after merging the geografts.
edit. note. important.
Nope, using the geograft for the shell geometry instead of the merged figure will not work in animation. So this optimization is not possible. We still can delete the material selectors to get the opacity right though. And headlights needs to be fixed as well.
-
- attached futa-hl.duf
test scene for geometry nodes
-
repo owner
In the last commit the links from the material selection nodes are removed when merging geografts, and the input name has been changed. The names of the material input sockets are kept, since I think it is clearer when the name indicates which material is involved.
Fixing the headlight shell was not so easy. I made some change which generated two separate nodes modifiers, but only one became visibilble.
-
Commit 5dd1be3 doesn’t work fine.
I made a new test scene futa-hl-2.duf where futalicious and headlights are together with a standard shell for legs and arms.
1. The standard shell should be transparent where shell materials are not defined, instead it uses the figure materials thus overwriting the other shells. To fix this we have to introduce a “invisible“ material. In this case I used a nor node to invert the material selection, don’t know if there’s a better way.
Please note that this is not necessary for geografts since the geograft shell will cover the whole geograft.
Please note that this may seem not necessary if there’s a single standard shell. But it is necessary. The difference is that if we don’t fix the opacity then the shell will use the figure materials instead of the invisible material, thus the shell will be displayed instead of the underlying figure. This may seem the same if the shell is close to the surface but the figure is not displayed this way, the shell always covers the whole figure that’s not what daz studio does.
2. The headlight shell doesn’t work, because the “Headlight L“ geograft misses the “Headlights UVs 2“ uv map that is assigned only to “Headlight R“.
Below there’s the shells rendered with the fixes above.
edit. p.s. I don’t agree on leaving the material names in the group input since it really clutters things down. And it is not necessary we can see the assigned materials in the modifiers tab. Other than making little sense for the input names as explained above. But this is minor I can live with it.
-
- attached futa-hl-2.duf
test scene for geometry nodes
-
update. OPTIMIZATION.
One possible optimization is to delete the extra geometry instead of using a invisible material. Please note that daz studio uses invisible materials so this will not be the same thing but will produce the same result in rendering and it’s a good optimization for geometry shells.
We may consider this optimization for geografts as well. Below it’s an example for futalicious. Again I used some boolean nodes to invert the selection I don’t know if there’s a better way. For booleans I strongly suggest to close the nodes to reduce the clutter.
edit. note. important. Please note that if we could merge the geograft materials with the “merge materials“ tool before generating the shell, then the selection would be much easier and optimized.
edit. note. important. Please note that for geografts, if we can find a way to feed only the geograft mesh to the geometry node then this will be even better. Instead of feeding the merged figure then deleting the extra geometry.
-
Getting multiple geonode modifiers to work with each other is beyond my understanding, sorry. They may be evaluated in the wrong order, so that the geoshell object is trying to replace the materials before the geograft actually adds them? UVs aren’t well supported in general either. I think you need a Blender dev to explain implementation details at this point.
But there is one solution you can try:
- Hide the figure.
- Add a cube as a new object and add a geonode modifier to it.
- Delete the group input and use an Object Info node to output the figure’s geometry.
- Add all the geografts (as nested node groups) to the figure’s geometry.
- Then add the geoshells (as more nested node groups) with a Joint Geometry node.
Rather than multiple geonodes trying to coexist, you now have a dummy object that combines all the geometry into one. And you know exactly what order they’re all evaluated in, removing any ambiguity. There’s also other helpful aspects to this, like being able to route geometry through its own subsurf node but control all of the subdivision levels with one integer value node. Unfortunately many modifiers don’t have geonode equivalents yet, but geonodes is still a work in progress.
I think it’s more helpful to treat geonodes as belonging inside one single node tree, rather than spreading them around to multiple separate objects with unclear dependencies. I don’t think they’re meant to work that way.
-
I don’t see how the evaluation order will play any role in this. I mean it doesn’t matter in this case each shell is independent from the others the only thing that matters for rendering is the shell offset. But your idea of merging all the shells in a single geometry node may be interesting and possibly add some more optimization.
-
Evaluation order matters for material replacement. If the geoshell is evaluated first then the material it’s replacing on the base mesh may not exist or may get overwritten when the geograft is evaluated.
-
- changed title to Fixes and optimizations for geometry shells
Sorry William to take over your discussion but I believe your original post is irrelevant now. This is just practical.
-
@Midnight Nope, we don’t change the merged mesh that we feed to the shells. That is, geoshells don’t change anything on the base mesh, at least in the actual implementation. So the evaluation order doesn’t matter, each shell is independent.
-
@Alessando
The evaluation of geoshells may be independent, but how do you know the merged mesh is being evaluated before them?
Every object’s modifier stack is evaluated first, then its geometry is made available for other geometry nodes to use. On a global application level, it’s not clear which object gets evaluated first, which is a problem when it comes to juggling geometry node modifiers.
-
Because the one and only modifier stack is on the figure, the shells don’t get modifiers.
Then I agree this is not a grant that the figure will be evaluated first, but it seems to happen so. I guess a dependency graph is built somehow so things work fine. At least in my tests I don’t have any issue.
-
Last time I tried it, the geoshell object got a modifier that replicated the base figure’s geometry. That avoided both the posing lag usually involved with geometry nodes and also fixed some issues with UVs and materials.
When did it change and why?
-
Don’t know .. 1023 is the first version I tested geoshells with, may be Thomas can tell. Or it could be on purpose to avoid issues with the evaluation order as you noted.
-
repo owner
I have tried to implement the ideas here, but now the shells become completely invisible instead. But the whole geometry nodes thing remains experimental. For production work I would definitely not use them yet, neither for shells nor merging geografts.
-
Thomas, as for commit 4e29cb7 it seems I wasn’t clear enough to explain the overall picture. The material filters are only necessary for the merged mesh, of course the geograft mesh doesn’t get extra materials to filter out. So for example for futalicious we have a setup for the geograft mesh and a setup for the merged mesh as shown below.
Same for the other shells.
Again if we could have an option to merge the materials then the selection would be easier.
Below it’s the shell before merging geografts.
Below it’s the shell after merging geografts.
edit. note. VERY IMPORTANT PLEASE READ. It’s probably better to delete the extra geometry before setting the offset, this way there’s much less computation to do.
edit. note. p.s. As for the geometry nodes being experimental I agree the material method is much more efficient. But the geometry nodes open up new features that are not possible with the material method. For example we can have offset geometry, single principled materials, and possibly the daz face groups visibility that’s not possible with the material method.
So overall the material method is much more optimized and “blender friendly“ and works fine for the most common cases. But to mimic the full features of the daz shells we need to use nodes.
-
update. important. ABOUT MATERIAL SELECTION
In the examples above I didn’t use the material selection for the set material nodes in the geografts. This happens to work fine. The reason is that geografts tend to use the same material for all the geograft parts. Indeed we could use a single set material node instead of the set material chain and it would work fine the same.
This is not possible when we have different materials for the different parts, in this case we need the material selection. As in the example below for the G8F Shell where we suppose that arms and legs have different materials, though it’s not the case with our duf example where they are both the same red material.
Indeed it would be useful to always merge the materials with geometry shells. This way it is clear what materials are different and we can use them as selectors. Otherwise it’s quite a confusion of what is needed and what is not.
-
repo owner
The last commit seems to work for simple shells, but mixing shells is too complex. As Midnight said, it is the shell object that gets the modifier, and multiple shells may target the same mesh.
I don’t understand the point with changing the node tree when geografts are merged. Geografts make little sense on the own, so if they look strange before they are merged does not matter that much. Besides, generating a new node tree is straightforward, but editing an existing one is messy, so I want to avoid that.
-
Here’s a character with a “simple shell” that I just imported. But do you notice anything unusual about her?
She’s a cube.
Going forward I think we should reevaluate how we approach things. Geometry nodes lets us easily copy geometry from one object to another regardless of vertex count. We should stop thinking of the figure we import and pose as the figure we’re going to render, and start thinking of it as a data source. We work on it, but then we instance its data into a dummy object (like a default cube) using geometry nodes:
Thomas said it’s easy to add nodes but editing node trees is tricky, but I think to get into the “everything nodes” mindset we might instead move towards a node-based workflow. The exporter creates modular “blocks” that we, the users, are in charge of putting into the node tree of our dummy object. By limiting everything to one node tree and treating our objects as data sources we instance from, we avoid the sort of kinds of issues seen in this thread. With the nonlinear nature, we can instance geografts and merge them with our figure in any way we want, and then we can instance geoshells after that (avoiding dependecy issues), and then we can use the exporter to create material replacement nodes after the geoshells (so we know the materials we’re replacing already exist).
Geometry nodes is still a work in progress and it can’t do everything yet. So I don’t think this’ll fully replace “the old way” yet. But this is the future of the program and we’ll all need to get used to it sooner or later, so why not start now?
I haven’t had a change to test this beyond this simple demonstration. But when I start doing character renders again I will be using this method and then I can more fully explain the upsides and the downsides.
-
Thomas, commit 526d98a works fine apart headlights.
You can keep the delete geometry node always connected if it’s a problem to connect/disconnect. It just won’t have any effect when the geograft is not merged so it’s a unnecessary step in this case, but it doesn’t harm.
As for headlights, the issue seems to be we can’t have multiple geometry nodes on the modifier stack. Otherwise only the last geometry node is evaluated, because the last one “overwrites“ the previous ones with the geometry output. That is, each shell must have one single geometry node. So when multiple geografts share the same shell we have to include their parts and materials in the same geometry node. Unless there’s some trick with output attributes and internal dependencies that personally I don’t know how to use.
Below it’s the setup for headlights where I merged the two geografts in the same geometry node for the shell. Basically the setup is the same but we have to include the materials from all the geografts in the same shell, instead of just one geograft. The only drawback is the shell will only work fine once the geografts are merged. But since geografts are supposed to be merged to work then this shouldn’t be a big issue.
It is also possible to remove the object info from the input as Midnight suggests, and/or merge all the shells in a single geometry node. But this doesn’t seem to get any advantage that I can see. Again the only limitation seems to be that we have to use one single geometry node per shell.
note. Then again an option to merge the materials for geoshells will greatly simplify/optimize the setups. Also closing the booleans would be nice. And when there are only two materials we could use a nor instead of or + not.
-
repo owner
Shells that affect several geometries now become multiple objects in Blender. Hence there are two headlight shell objects, left being the child of right. This is not exactly what DS does, but was easier to handle and should work too.
I noticed that there was a lot of unused shell materials. Both the futa shell and the headlight shell contained all futa and headlight materials. This doesn’t seem useful at all, so I removed the unused slots.
The Merge Materials button now ignores objects with shells. Before all futa materials where merged into Rectum, which wasn’t good since the futa shell stopped working.
-
Thomas, it is not that you can’t merge materials in the shells. You can merge materials in the shells, but also you have to merge materials in the geografts the same way.
For example for futalicious the materials in the shell can be merged in two materials “rectum“ and “torso-front“. Then the same merging must be done in the geograft. Below it’s the setup that I did merging materials by hand.
Please note that the materials in the geograft are all the same, but we can’t merge all of them into one because this way we lose the selection for the shell materials. This is why we have to “copy“ the shell merging into the geograft.
edit. note. I don’t know how you merge materials via script, to merge by hand I select all the materials to merge in edit mode, then assign to the selection the material I want to replace with. So it’s a simple selection by material, and you can use the material names to do the same in the shell and the geograft. If this can be useful.
As for the unused materials those are imported from the daz scene because the “shell-fix“ utility by Meipe works with the shell visibility by face groups, not by surface. So the extra materials are not hidden and are imported. I agree it makes sense to delete materials that don’t have any geometry assigned.
As for using multiple shells when the same shell is assigned to multiple geografts, I agree this is a viable solution. It also has the advantage that the shell works fine before and after merging the geografts. Though personally I prefer my solution above with a single shell that’s more optimized.
That said, commit d00011c works fine, the above comments are possible optimizations. So Thomas let me know if you want to try them or I’ll mark as resolved.
-
repo owner
Single vs multiple shells: I agree that a single shell may be better, but multiple objects were easier to implement within the existing code. Since the current setup works ok and it is rather unusual anyway, I will stick with it.
Merging materials if both the base and shell materials match: Yes, it is doable but I don’t think it is really worth the effort.
-
Just to be precise. It’s not a “if”, the geograft and shell materials will always match because the shell is an instance of the geograft. As if the effort is worth you decide but it simplifies the setup a lot, and since we already have “merge materials“ for the standard shells it would be expected for the geometry shells too.
Let me know if this comment changed your mind, if not I’ll close this one.
-
repo owner
The base and geograft materials match, but they are not ordered in the same way, at least not after they have been imported into Blender. Here is the list of futa and futa shell materials. To figure out which materials correspond to each other requires analyzing the geometry node tree, which I don’t want to do. We also have the risk that the user has manipulated the materials in Blender.
-
I’m not sure to follow. I mean in the geometry node we already connect the graft and shell materials, this means we do know which materials correspond to each other, otherwise we couldn’t connect them. Don’t we ?
Not to push but just to help if this is the reason why you can’t make it.
-
repo owner
OK, the information is there, but it is not so easy as matching the n:th base material with the n:th shell material which I thought first. One has to analyze the node tree to find the matches. That can be done, but I don’t think it is worth the effort. I mean, it is not an error to keep several identical materials, but it is an error to merge materials if the base materials are equal but the shell materials are not.
-
repo owner
Merging materials for a genesis character doesn’t usually reduce the number of materials that much; ears are merged with face and mouth with teeth for G8F, and that’s it. It is more important for some clothes and props, that can have lots of identical materials. But clothes and props don’t have geografts (or very rarely), so the problem does not arise for them.
-
- changed status to closed
Thank you for the explanation. I'm closing this. We did the fix part but not the optimization part due to difficulties in the implementation.
- Log in to comment
The materials of this geograft consists of two parts: the base material of the torso + the geograft-specific shell material. The Single Principled ignores the shell. If you want to include it, you should select Principled instead.