better geografts ?

[Alessandro Padovani]

There's some request on the daz forum for better geografts support. Now I'm not an expert at all on the subject so I just followed a tutorial and made up a simple test. Scene attached. Beware that the tutorial below, though it gives a good overview, contains errors that I worked around.

https://www.youtube.com/watch?v=Zm-QCFKowCw

Now, unless I miss something, it seems that merge rigs doesn't work with geografts. That is, if I try to merge the geograft rig it gets deleted.

As far as I can understand a geograft is by all means a figure by itself, the same as an outfit. It may have its own materials, uv maps, morphs, bones, and even wear a geoshell. So I feel it should be loaded as an outfit.

Plus a geograft gets the special ability to graft to another figure. Now the plugin merges the the graft geometry in the finalize section, while daz studio just hides the figure graft area so that the geograft may fit in fine. This preserves the use of morphs since the geometry is not changed. May it be it's a good idea to do the same ?

Again I'm just thinking aloud, not an expert at all, may be I'm just misunderstanding things.

‌

[Alessandro Padovani]

There's another issue with geografts that I can report here. If I add a geoshell to my simple test it seems it's not handled correctly. Again scene included that's geograft-r2.

Below the example. I added the tail geograft to the G1F. Then I added a shell to the G1F where the shell visibility is limited to the tail. This seems to be common practice for a geograft shell. The reason behind this is that there is no way to add grafting faces to a shell. So to avoid artifacts in the grafting area we have to add a shell to the figure instead.

Now in the example above the plugin doesn't create the shell for the geograft, that has visibility on. It instead creates the shells for the figure materials, that have visibility off.

‌

That's it. So far I got two issues with geografts that I hope can be fixed. Please Thomas let me know if you are interested at all to improve the geografts features, otherwise I'll not proceed further if your plans are elsewere.

1. Merge rigs doesn't work.
2. Figure shells don't work as expected.

‌

[Thomas Larsson]

For Merge Rigs, a geograft is just another piece of clothing, and the bones appear on the clothes bone layer, by default layer 3. The bones are there, but for some strange reason the bone layer checkbox is not marked. Maybe an update problem in B2.8x, it worked in B2.79.

‌

[Alessandro Padovani]

Thank you Thomas indeed I can find the bones in layer three I was fooled by the missing checkbox. Is there any chance to fix the geoshell ?

[Alessandro Padovani]

As for layer three if I add then remove a bone by hand then the checkbox appears there, so this may be a workaround.

Does the plugin add the bones in edit mode ?

‌

[APA]

I have found the materials on geograft products generally handled better than this test case. Not perfect, but better.

In the products I have used, a trans map is used on the shell to blend the shell material with the underlying geograft material. Without this trans map, as in the test, and hence no ‘mixing’ of materials required, perhaps the plug in is not recognising the situation correctly. You would expect to see the material from the geoshell and nothing from the underlying geograft here of course, whereas we see the geograft material only.

I also note that in geograft products I have used, the geograft and the geoshell usually have different UV maps with different names. The test seems to have them use the same UV map, which also may be throwing the plugin off.

[Alessandro Padovani]

@APA Actually I am reverse enginnering some very common commercial geografts and finding out what doesn’t work with the plugin. Then since we have to provide a tests case for Thomas to work on, the issue has to be implemented in this test case. Now the issue I am focusing on in the example above is when there’s a full body geoshell that the plugin doesn’t handle correctly.

Then it is true that I simplified the shell with no transmap and no extra uvmap. But the specific issue I’m after doesn’t require them. Please feel free to modify and improve my example if you find it useful. Any help is welcome.

[Thomas Larsson]

Should work now.

The fix involves a rearrangement of the code that handles channels, which was previously repeated and spread out over several files. This should make the codebase simpler and more robust, but it is a rather basic change and it may have repercussions that I haven’t thought about.

[Alessandro Padovani]

Commit dc31714 seems to work great with no issues, apart the missing checkbox in layer three.

As for commit aa0fc95 I get the following error when I try to use a commercial product, eg. the futalicious referenced in #37. No errors arise in my example though.

Traceback (most recent call last):
  ..
  File "C:\Users\Alessandro\AppData\Roaming\Blender Foundation\Blender\2.82\scripts\addons\import-daz\files.py", line 282, in parseAssetFile
    return asset.parse(struct)
  File "C:\Users\Alessandro\AppData\Roaming\Blender Foundation\Blender\2.82\scripts\addons\import-daz\files.py", line 74, in parse
    asset = self.parseTypedAsset(gstruct, Geometry)
  File "C:\Users\Alessandro\AppData\Roaming\Blender Foundation\Blender\2.82\scripts\addons\import-daz\files.py", line 248, in parseTypedAsset
    asset.parse(struct)
  File "C:\Users\Alessandro\AppData\Roaming\Blender Foundation\Blender\2.82\scripts\addons\import-daz\geometry.py", line 227, in parse
    self.vertex_count = graft["vertex_count"]
KeyError: 'vertex_count'

location: <unknown location>:-1

‌

[Thomas Larsson]

Strange, I have also tested with issue #37 and don’t see that problem. Maybe we use different versions of the product. The latest commit should remove this crash, but if there is no info about the vertex count merging the geograft will probably not work.

[Alessandro Padovani]

Thank you Thomas for the fast fix. Commit af97e7f seems to work fine here. I can merge rigs then merge geografts without issues. I’d leave the issue open for a while just in case if someone needs to add something. But seems ok to me.

p.s. the missing checkbox in layer three is a little annoying ..

[Alessandro Padovani]

UPDATE. I didn’t notice this before but it seems commit af97e7f has issues when merging geografts. That is, the grafting area in the base figure is not removed thus causing artifacts when rendering. This is also visible in my tail example, as well as in commercial products. Below an example where I hid half of the tail in edit mode after merging the geograft to show the underlying geometry.

I don’t have commit dc31714 anymore since I deleted it so I can’t check back. But it seems to me that I didn’t have this issue with it.

‌

[Alessandro Padovani]

I managed to get back dc31714 by copy and paste of the sources in the commits section. I can confirm that dc31714 works fine. Below the same example where I merged the geograft and the underlying geometry is correctly deleted. So the issue is in commit af97e7f alone. It affects both my tail example and commercial products as well.

‌

[Thomas Larsson]

Sorry, stupid mistake. Should work now.

[Alessandro Padovani]

I have to resurrect my graphics workstation it seems windows update finally got to kill her .. going to test the commit tomorrow thank you Thomas for the fix !

[Alessandro Padovani]

It took a little longer than expected to bring her back from the windows update hell. Had to beat down a couple of major beasts .. Then at last tested commit c1b56bc and it seems to work fine for me. I did not test for graft hierarchies where I trust #37.

Marking as resolved.

[Alessandro Padovani]

I did some more tests.

It seems the shell and uv set is not imported for a geograft hierarchy. Below an example with the roasty addon referenced in #37. The roasty uvs v2 and the roasty shell is not imported into blender. The parent futalicious geograft works fine though. The issue only arises for the child roasty geograft.

‌

[Alessandro Padovani]

INFO UPDATE. In my tests I used the futalicious + roasty bundle v 3.2 that should be up to date. Then blender 2.82a and daz studio 4.12.0.86 that are the stable versions. Scene included if it can be useful.

[Alessandro Padovani]

roasty scene

[Alessandro Padovani]

As for commit 052a0c2 it works better, that is, both the futalicious and roasty uv maps and shells are imported correctly. But there’s an issue when we merge roasty with futalicious, that is, the futalicious uv map is lost with the merge, and only the roasty uv map remains.

Below a screenshot after the merge. There I also merged the armatures before, that works fine apart the missing checkmark in layer three.

‌

[Alessandro Padovani]

UPDATE. I also tried to use “merge uv layers” before merging the geografts to see if it can fix things, but I had no success. I’m not sure that I used it correctly in this case though.

[Alessandro Padovani]

Commit 0a7edaf seems to work fine, I was able to merge everything and didn't notice any issue on materials. Marking as resolved !

[Alessandro Padovani]

On a deeper check it seems the materials may benefit some cleanup if possible.

1. When importing daz materials a number of shells with mix shader zero are generated. This happens in surfaces where the shell is disabled in daz studio such as the torso surface. So it would be better to avoid generating these shells because they clutter up and carry no information. Though they cause no artifacts in rendering since they have mix zero so they’re not visible.

In the screenshot below I already merged everything but the zero shell is there from the beginning.

‌

2. When merging geografts it may happen that some materials are left with zero vertices because the relevant geometry is removed. This happens for example in the testicles surface when roasty is merged with futalicious. In this case the plugin doesn’t remove the material but it would be better to remove it since there’s no more geometry. Again no artifacts in rendering.

edit. Then I also tried the merge materials tool but it seems it doesn’t remove the empty materials either.

‌

3. This is rather out of curiosity but could be a little improvement too. I’m wondering why the attribute node is used for extra uv maps instead of the uv map node. If there’s no specific reason to use the attribute node then the uv map node would be a more meaningful choice.

‌

[Thomas Larsson]

Issues 1 and 3 should be fixed, although the shell materials all become white when rendered. Not sure if that is intended. I will look into the merging issue tomorrow.

Probably the UV map node did not exist when the code was originally written, and the attribute node was the only alternative. But the UV map node at least exists in Blender 2.79, which is the oldest release that I try to support.

[Alessandro Padovani]

I’m not sure what you mean by “the shells become white”. Just tested commit 1264b32 and it seems perfect to me as far as materials are concerned. Since I use little morphs and rig as I do them myself I’ll leave testing those to more experienced users. Going to mark as resolved. Overall that’s a great job and improvement in my opinion thank you Thomas so much.

I plan to test other more complex geografts. Eventually I’ll reopen if issues arise so to keep everything in the same discussion.

[Alessandro Padovani]

Tested with plugin commit 4bfcf3e, blender 2.82a, daz studio 4.12.0.86

It seems there's an issue when multiple geografts from Meipe are used together. Below an example where I used futalicious together with headlights. In this case the nipples material gets two shells in blender.

Please note that to use multiple geografts from Meipe it is necessary to use the shell fix script. This script will set the opacity to zero in the shell for any material that's not used by the geograft. So we have two shells in daz studio, but the futalicious shell will only get its own materials as visible, and the same for the headlights shell.

I'm not sure why two shells are generated in blender, but I suspect it may be because both the futalicious and headlights materials are active in both shells, so the visible materials are identified only by the opacity attribute in this case. Or it may be because the same shell is used for two different geografts, headlight_L and headlight_R, so the plugin may get confused.

Below two screenshots where we see the two shells in blender, and the headlights shell in daz that has opacity zero for the futalicious materials. Scene included.

edit. Please note that futalicious alone works fine and headlights alone works fine. It is only when we use them together that the issue arises. That is, when there are two shells in daz studio. Also to fix the issue by hand is not a big deal, it is enough to delete the extra shells.

‌

‌

[Alessandro Padovani]

futalicious + headlights scene

[Alessandro Padovani]

Tested with plugin commit 4bfcf3e, blender 2.82a, daz studio 4.12.0.86

There is another case where merging geografts has issues. This time it’s the full monty geograft always by Meipe. In this case the monty geograft is an addon for futalicious the same as roasty. The difference is that roasty grafts inside futalicious so it doesn’t modify the graft faces for G8F. On the contrary monty grafts even on futalicious borders so when we merge monty with futalicious in blender some graft faces for G8F are lost and then futalicious can’t merge to G8F correctly.

In daz studio everything works fine because the graft faces are not deleted, so monty grafts to futalicious then futalicious grafts to G8F. I guess in blender we need a way to retain the graft properties when we merge multiple geografts and some graft faces are replaced.

Below the two screenshots I got to show the difference where I hid roasty and monty from futalicious to show the graft faces. Monty scene attached.

edit. Also monty has the same issue as headlights where in blender multiple shells are generated for the same material. In this case it’s even worse since monty uses two extra shells in daz studio so we get six shells in blender for the monty materials.

‌

‌

[Alessandro Padovani]

monty scene

[Thomas Larsson]

The superfluous shells should be gone now. Monty gets three shells, but that is right, I think. And now the shells are named, so you can actually tell which shell is which.

[Alessandro Padovani]

Commit e989980 is great. With named shells it is much easier to compare with daz. I agree three shells are fine for monty since they’re the same in daz studio.

There’s the issue with missing graft faces for monty that’s not fixed yet. Since the graft faces need to be the same as the base figure by definition, may be a possible fix would be to just avoid replacing them when we merge geografts. That’s a rough idea that needs to be verified though I don’t know if it may help.

[Thomas Larsson]

Should work now.

[Alessandro Padovani]

I tested many combinations of geografts and commit f1dab98 seems very reliable. I feel we reallly have something that works fine here. That's a great job thank you Thomas.

Marking as resolved.