HD convention ?

[Alessandro Padovani]

4.2.0.2249

One limit with the HD exporter is there’s actually no way to distinguish between subdivided and HD objects, this leads to use the multires modifier for both. Ideally we want to export subdivision as subdivision and HD as multires, since there’s no HD details to bake in subdivision, and also because multires may fail and it’s much more expensive. Not to mention that exporting subdivision as HD requires anyway to bake the HD mesh, tremendously slow at high levels and perfectly unuseful in this case.

The ideal solution would be to check for dhdm files, if the object gets one then we export as HD, otherwise as subdivision. But I’m not sure this is possible for the exporter.

One alternative is to get a “convention”, that if we want a object to be exported as HD then we add the HD suffix to the object name, otherwise the object will be exported as subdivision aka base resolution with a subd modifier. The HD convention is anyway mostly used in daz already.

Let us know what you think.

notes. It would be better to make this an option in the global settings, not to force users to deal with HD names. Also if we use the HD convention then of course there’s no need to add the HD suffix in blender since it’s already in the daz name.

[Alessandro Padovani]

p.s. workaround. One possible workaround right now, is to set all objects that we don’t want as HD to base resolution in daz studio, then add a subd modifier in blender.

[Alessandro Padovani]

p.p.s. single exporter ? Also with the HD convention we don’t need a separate HD exporter, as the exporter will export subdivision or HD depending on the name, so a single exporter is fine. But to have this as an option we can keep the two exporters. Or perhaps add HD options to a single exporter, instead of the global setting.

single exporter with options:

• base res: export everything as base resolution, same as the actual non HD exporter
• HD: export everything as HD, same as the actual HD exporter
• HD names: export as HD only objects with the “HD” name suffix

‌

[Thomas Larsson]

This sounds like a good idea if it is possible to find out if there is a dhdm file from the DS API. I will be away next week but will have a look after that.

[Thomas Larsson]

Unfortunately, I didn’t find anything in the DS API that returns the name of the dhdm file, or even if a dhdm file exists. I can find it in the dsf files that define the morphs - the entry is called “hd_url”. Presumably one has to go over all currently used morphs to see if any of them has a hd_url.

To rely on naming conventions doesn’t seem like a good idea to me.

I’m rather agnostic about having a single export script.

‌

[Alessandro Padovani]

The only workaround we have now is to set everything non-HD as base resolution in daz studio, then add a subd modifier by hand in blender. To this behaviour the HD naming convention would be a great benefit since this way the exporter can understand what we want HD and what not. Provided the user is aware and willing.

But feel free to close as wontfix if you’re not interested, we can go on with the manual workaround.

[Thomas Larsson]

OK, OK. The HD export script now launches up to three popups: whether to export HD at all, to only export HD for figures with labels that end with “HD”, and to export the HD UVs. If nothing is broken we should be able to drop the dedicated non-HD exporter.

‌

[Alessandro Padovani]

Thank you so much. On a couple quick tests commit 2ab090a seems to work great, but I’ll do more extensive tests and let you know.

A couple minor notes.

options. Of course it would be better to have a combo box for the options, rather than three dialogs. Though I understand this requires to look at the daz api how combo boxes are done, so not trivial to do.

names. With the HD convention it is unnecessary and a bit awkward that all names end with HD on the blender side. We can leave the daz names which already have the HD suffix when needed. Otherwise even non-HDs end up with the HD suffix that’s odd.

‌

[Alessandro Padovani]

Commit 1ae7376.

options. The option dialog is fixed thank you.

names. The names don’t need the HD suffix if there’s not a multires modifier. This is confusing. If this is necessary for some reason, then as a last step you could remove the HD suffix to all meshes which don’t have a multires modifier. That’s what the user would do by hand to fix this.

collections. Since base resolution and HD meshes can often be mixed within the same figure, it makes little sense to have a separate collection for HD, we can use a single collection where HD and non HD items are together, the HD suffix already identifies HD items. Personally I always merge the HD and non HD collections. Or we may have a option for that in the global settings.

bug. G9 eyes. If we export them as HD, the G9 eyes unsubdivision is wrong. In daz studio we have a 1 level subdivision for the eyes, while in blender we get a 2 level unsubdivision. This is probably due to we using “rebuild subdivision“ which rebuilds all possible subdivisions. Instead we should use “unsubdivide“ for the viewport subdivision level in daz studio. The reason is simple, some meshes may be unsubdivided further because their topolgy allows that, but we don’t want to, we want the subdivision level in daz studio so to match the base mesh.

Test scene included.

  # unsubdivide
  for the viewport subdivision level in daz studio
    unsubdivide

‌

[Alessandro Padovani]

test scene for G9 with HD convention

steps:

1. in daz studio save as HD convention
2. import in blender

‌

[Thomas Larsson]

The “HD” is stripped from the end of the base mesh name. The HD object thus has a single “HD” in the name.

Objects without HD data are not duplicated anymore. Thus the same object belongs to both the base and hd collections. Exception: Geografts are duplicated, because we want to be able to merge geografts to both the base and HD meshes, and merging grafts consumes the graft object.

There are still separate base and HD collections. Normally we want to see either the base or HD object, but not both at the same time. Collections makes it easy to exclude all base or HD objects at once.

I will have a look at the G9 eyes.

[Thomas Larsson]

The G9 eyes are fixed. It used to be impossible to unsubdivide the mesh unless the subdivisions had already been rebuilt,I think, but this doesn’t seem to happen anymore. I also checked in Blender 3.6 and unsubdividing the HD mesh work fine there too, and there is really no need to support anything older than that.

[Alessandro Padovani]

Commit d376f34.

names. This is fixed works great, thank you.

unsubdivision. Fixed, thank you. Works with 2.93 too. We may want to support 2.93 since it’s the last LTS release before the volumetric bug #1168. Also 2.93 LTS is dated June 2 2021 so not that old yet.

minor bug. names for warnings.

With the kat.duf scene the addon reports a warning: “geometry-2“ for invalid meshes and “dforce pixie cut mesh“ for meshes without faces. The name in the outliner for both is “dforce pixie cut“ and that should be used in the warning, otherwise the user is confused so the warning less useful.

‌

about collections. I believe there’s some confusion, yes we want separate HD and base collections if we “keep base meshes” in the global settings, otherwise two collections have no meaning as in the same figure there’s usually both HD and non HD meshes. That is, we want collections based on figures, not collections based on objects.

Anyway it is fairly easy to select all and merge collections if the user wants to, so this is a minor issue. Still it is confusing to have two collections if we don’t “keep base meshes“.

  # HD collection
  if "keep base meshes" in global settings
    do separate collections for HD and base figure
  else
    use a single collection

‌

[Thomas Larsson]

Now the base collection is removed if Keep Base Meshes is disabled. I also enabled HD export by default. This doesn’t cost anything for non-HD figures since the HD convention is also enabled by default, However, there are many HD figures that don’t use the HD convention, so we must tell users that they have to rename those characters. Or disable the HD convention option.

The dedicated HD export script has been removed.

[Thomas Larsson]

Now mesh names are taken from the corresponding figure instance. That is usually not the same as the object name, but it is usually more descriptive than just “geometry-1”. Error message are using the object names, and truncate the extra “ Mesh” at the end.

[CookItOff]

Testing out the new workflow, of removing the HD export and combining it with the normal export, but I can’t get the Multi-rez modifier to load instead a of sub-d, like previously with the HD export option. What could I possibly be missing?

I have all three HD checks enabled when exporting from Daz. And nothing looks to be new in the global settings.

Thanks

[Thomas Larsson]

There are now three possibilities:

• Export HD is off. This is the old export to Blender, without HD.
• Export HD is on and HD convention is off. This is the old export HD to Blender. Everything is exported as HD.
• Export HD is on and HD convention is on. Only figures that end in “HD” are exported as HD. This is the new default. Many figures already adhere to this convention, e.g. most modern HD figures sold by DAZ, I think. You can force HD export by changing the figure name.

‌

[CookItOff]

It’s working now! I cleared/removed everything associated to the old add-on DAZ and Blender and that seemed to do the trick.

Thanks for the breakdown of the new export settings and the follow up.

[CookItOff]

I can confirm the 3rd bullet point. The reason the first character I was trying was failing was that the creator had placed “HD” in the middle of the description. Erasing the last part and only HD at the end solved the issue on this character. Just to debug I had switched to Victoria 9 HD and of course that one worked. I think my original issue was bullet point 3.

Good to know. Thanks

‌

[Alessandro Padovani]

Commit 2fcd99e.

Did some more tests and everything seems to work fine. Your work is excellent thank you. If there’s nothing to add we may close as resolved.

@CookItOff The HD convention is not expected to work automatically, it is the user responsibility to name as HD the objects he wants. Though many daz figures follow this convention. The purpose of the new option is to avoid exporting as HD objects without HD details, which can be exported as subdivided, much faster and without multires.

[CookItOff]

@Alessandro got it, and thanks. I like the new approach y’all are going with this, giving control over which items I want to have the Multi-rez modifier.

Great work.

[Thomas Larsson]

I’m thinking of changing the defaults, so that both Export HD and HD convention are disabled. The point is that a casual user doesn’t know what the HD convention is, and might be confused when the HD data aren’t exported. What matters to myself is that HD data are not exported by mistake with the default settings.

[Alessandro Padovani]

As for the defaults I don’t have a strong opinion. I suppose exporting the base resolution is fine.

[Alessandro Padovani]

4.2.0.2264

bug. camera. The daz camera is missing if we don’t “keep base meshes“.

steps:

1. export kat.duf as HD
2. import without “keep base meshes“, the daz camera is missing

update. Also lights are missing if we add some in daz studio, while props are imported fine. I mean if we don’t “keep base meshes“.

[Thomas Larsson]

Fixed in last commit. I also changed the defaults and wrote a blog post about it.

[Alessandro Padovani]

Commit 982f655 works fine. Thank you for your work on this useful improvement, marking as resolved.