Unity bridge suggestions/feedback

chris_63502790

Long time Unity dev here... been using the bridge for a bit, a few issues that would really help make imported models look better or performant.
 

1. Unity does not do well with hundreds of materials per model. Sometimes the asset bridge iterates through the model being exported to unity and creates hundreds of materials for a prop/model. It would be very helpful for performance reasons in a production environment, if the asset bridge could realize the same material is being copied over and over and just reference the 1 material rather than creating multiple copies of the same material over and over.
2. Emissive maps are often not generated or the settings for the emissive are wrong in the IrayUberMetal shader. Emission strength, EmissionExposureWeight are often set to 1 or 0 which doesn't cause Unity HDRP to actually create the emissive effect on materials. 
3. Sliders for adjusting the Metallic/Specular/Height/Normal floats for the IrayUber shaders would be fantastic, trying to adjust the float numbers manually can be a bit of a pain at times.
4. Hair looks less than awesome when exporting to Unity HDRP 7.x, Unity has a LTS (long term support) build for HDRP 10.x (v2020.3.17f1) which now includes a native Hair & Eye shader for HDRP. The hair shader is much better than the IrayUber shader. Maybe consider an option to use the native HDRP shaders for Unity rather than the IrayUber ones.
5. Now the most important one....A lot of fidelity is lost on exporting models from Daz to Unity, specifically it looks like in the wireframe handling for faces. My guess is that the export is doing wireframe reduction (?) or some other type of mesh base operation which causes a significant loss in model fidelity. So, here's what artists do in workflow for game design in production, we actually use 2 models, one for closeup cinematics/cutscences, and another model for gameplay. The cutscene models are close up and have a much higher tris count. This is fine because, when doing cutscenes, we're not loading a huge unity scene, so the higher tris count is fine and performant in most cases. LODs are typically not used in cutscenes. In gameplay, lower tris models are used since the camera is some distance away. With Daz, model exports are losing a lot of HD face details. I think a lot of it depends on the model, since some of the daz models use layered normal maps to create additional detail and some increased wirewrame tris. My recomendation would be to do what Character Creator does, give us the option on the export tris count (ie max, etc). Let us decide how much you're cutting off the export.
6. Geoshells, Geoshells, Geoshells.... this is a nightmare for any pipeline workflow, whether exporting to Unity, Unreal, or Charactor Creator. Please, for the love that all that is holy, do something about Geoshell exports. My recomendation would be a material baking process to remap and bake the entire thing on export for 4096k textures for HDRP, yes 4k. 
7. Add an option to export all the texture files to Unity. A lot of the Daz assets have multiple texture maps for small changes to the look of an asset, a color change from red to blue for example. The export doesn't pick up these extra textures in the folder for the asset, so we have to a) find the texture in daz, b) copy it over to unity manually. It could be great if there was a little checkbox to copy all the textures in the daz asset folder for that model over Unity in like a "SourceTexture" or Misc folder. 
8. Instances!!!! In Daz, assets have instances, when exporting it over, there's no mesh for the instance. I get that his is helping Daz to be performant and it doesn't really exist in Daz, but it breaks a model when exporting it to unity and it's additional work for developers to locate the original object that was instanced and duplicate/place it where it belongs. Again, maybe a checkbox that copies that mesh source and creates it on export at the x,y,z cordinate where the instance is supposed to be. I get it might not be "exact" for every Daz asset, but at least it's something that might save us some time in the workflow.
9. Make it paid gateway so you can maintain it, it kind of sucks to offer this bridge and then sort of leave it like a ghost town without frequent updates. I know that if this were consistently maintained, I'd gladly pay for it to be improved over time.

Update us, communicate with us, release improvements & updates please, please, please.

danielbui78

chris_63502790 said:

Long time Unity dev here... been using the bridge for a bit, a few issues that would really help make imported models look better or performant.

Hi,

I can't speak on behalf of Daz or the Daz Bridges team, but I will point out that the group working on the Daz Bridges is small, and that they are responsible for all the bridges; not just DazToUnity: https://www.daz3d.com/forums/discussion/469326/daz-bridge-support-is-here/p1. ; I agree with you that frequent communication and updates is always a good thing, but in my humble opinion, the updates and communication from the Daz Bridge team has been better than most major software companies, especially for a family of products that was announced less than 12 months ago.

With regards to your specific itemized issues, I can give you some of my thoughts and possible solutions based on my work with the Bridge source code over the past few months:

1. Unity does not do well with hundreds of materials per model. Sometimes the asset bridge iterates through the model being exported to unity and creates hundreds of materials for a prop/model. It would be very helpful for performance reasons in a production environment, if the asset bridge could realize the same material is being copied over and over and just reference the 1 material rather than creating multiple copies of the same material over and over.

Agreed.  I already have plans to create a material lookup table and merge equivalent materials during the Unity material creation process.

2. Emissive maps are often not generated or the settings for the emissive are wrong in the IrayUberMetal shader. Emission strength, EmissionExposureWeight are often set to 1 or 0 which doesn't cause Unity HDRP to actually create the emissive effect on materials. 

Thanks for reporting this.  I just looked at the "Emission Color" processing code and confirm that this is a bug.  The EmissionStrength and EmissionExposureWeight shader parameters are not being set for IrayUber materials during the Unity material creation process.  I will try to make a hotfix for this in the Unofficial DTU project and then make a pull request upstream to the official DazToUnity github repository as soon as I can.

3. Sliders for adjusting the Metallic/Specular/Height/Normal floats for the IrayUber shaders would be fantastic, trying to adjust the float numbers manually can be a bit of a pain at times.

I agree as well.  You can very easily make this improvement yourself by right-clicking a material, selecting "Edit Shader...", then finding the desired parameter, such as "Metallic", and then finding the "Mode" dropdown and changing it from "Default" to "Slider".  Then click "Save Asset".  I'll put this on my todo list, but I will probably take me some time, as I already have about 2-3 months of work mapped out.  If you would like to submit your changes, that would be awesome -- but please submit .shadergraph files made with Unity 2019, since they don't seem to be backward compatible.

4. Hair looks less than awesome when exporting to Unity HDRP 7.x, Unity has a LTS (long term support) build for HDRP 10.x (v2020.3.17f1) which now includes a native Hair & Eye shader for HDRP. The hair shader is much better than the IrayUber shader. Maybe consider an option to use the native HDRP shaders for Unity rather than the IrayUber ones.

Already on my todo list, as well as support for dForce strand based hair.

5. Now the most important one....A lot of fidelity is lost on exporting models from Daz to Unity, specifically it looks like in the wireframe handling for faces. My guess is that the export is doing wireframe reduction (?) or some other type of mesh base operation which causes a significant loss in model fidelity. So, here's what artists do in workflow for game design in production, we actually use 2 models, one for closeup cinematics/cutscences, and another model for gameplay. The cutscene models are close up and have a much higher tris count. This is fine because, when doing cutscenes, we're not loading a huge unity scene, so the higher tris count is fine and performant in most cases. LODs are typically not used in cutscenes. In gameplay, lower tris models are used since the camera is some distance away. With Daz, model exports are losing a lot of HD face details. I think a lot of it depends on the model, since some of the daz models use layered normal maps to create additional detail and some increased wirewrame tris. My recomendation would be to do what Character Creator does, give us the option on the export tris count (ie max, etc). Let us decide how much you're cutting off the export.

I'm not sure 100% what you mean by wireframe handling, but I think you might be talking about "mesh resolution" or "subdivision level".  Most current Daz3D assets are modelled using Subdivision Surface technology (just do an internet search for "Subdivision Surfaces" for more info).  Currently, the DazToUnity bridge can only effectively export figures at Subdivision Level 0, aka no subdivisions (base mesh).  Usually, Daz Studio renders figures in the viewport at subdivision level 1 or 2 by default.  So that mesh resolution difference from 0 to 1 or 2 subdivision levels may be what you are describing as loss of fidelity.  Although you can specify higher levels of subdivision in the DazToUnity Bridge options, these levels are not fully supported because the extra vertices generated do not have corresponding bone weights calculated for them yet.  There is a solution for the DazToUnreal Bridge using opensubdiv to calculate the missing boneweights.  This is also on my todo list.

EDIT: Just to be clarify: the Bridge currently does not perform any polygon reduction (sometimes also called mesh decimation) or otherwise reduce the number of triangles in a mesh below the base mesh resolution.  It is just outputting the base resolution without the enhanced subdivision detail that is by default enabled in the viewport and render windows of DazStudio.

6. Geoshells, Geoshells, Geoshells.... this is a nightmare for any pipeline workflow, whether exporting to Unity, Unreal, or Charactor Creator. Please, for the love that all that is holy, do something about Geoshell exports. My recomendation would be a material baking process to remap and bake the entire thing on export for 4096k textures for HDRP, yes 4k. 

I agree that the best solution may be baking... but it is not as simple as just simple L.I.E. texture baking.  Please note that Geoshells do something that regular L.I.E. textures simply can not do: they can map textures onto the underlying mesh using a completely different set of geometry, topology, UV coordinates, normal vectors, etc.  This allows geoshells to apply fine texture details efficiently onto areas that would normally suffer from texture stretching, deformations or seams if applied using the underlying mesh alone.  That means that in order to bake the geoshell onto the underlying mesh, you need to project the texture information from one coordinate space onto the textures of a different coordinate space, and that means all the advantages of the geoshell are lost; potentially causing a lot of awful looking textures.  So if the underlying mesh uses a 4K texture, the baked texture using this theoretical geoshell projection algorithm might need 16K to achieve the same quality.  So there are lots of things to consider and, unfortunately, none of the proper solutions that I'm aware of are mathematically, logistically or financially simple.  My current planned workaround would be to optionally exclude them from export, also on my todo list.

7. Add an option to export all the texture files to Unity. A lot of the Daz assets have multiple texture maps for small changes to the look of an asset, a color change from red to blue for example. The export doesn't pick up these extra textures in the folder for the asset, so we have to a) find the texture in daz, b) copy it over to unity manually. It could be great if there was a little checkbox to copy all the textures in the daz asset folder for that model over Unity in like a "SourceTexture" or Misc folder. 

If I understand correctly, you want to be able to select a figure from the viewport for export, then have the option to export all the make-up variations, eye-color variations, etc. at one time.  Instead of selecting the figure from the viewport, it might be possible to do create a function to do something similar by directly specifying the Product Package to export, ex: select the Victoria 8.1 Product off the "Smart Content" panel and export all the texture set variations from that, rather than selecting a figure from the viewport.  The problem is this: since modern Daz figures are made to be vertex order / morph and often UV compatible with other figures within its generation, I don't know if there is a 100% accurate way to do a reverse lookup on the active texture applied to a material and trace it back to the Product Package to which it belongs.  Unfortunately, exporting from the Product Package would require code that processes and converts the asset library data rather than processing and converting the active scenegraph data.  I could possibly make a script-based solution that reads the asset library data for a selected Product Package and instantiates all combinations of texture sets onto as many active figures as needed and then batch export all of them into Unity using the DazToUnity Bridge.  I will consider putting this on my todo list, but it isn't something I can do this year.

8. Instances!!!! In Daz, assets have instances, when exporting it over, there's no mesh for the instance. I get that his is helping Daz to be performant and it doesn't really exist in Daz, but it breaks a model when exporting it to unity and it's additional work for developers to locate the original object that was instanced and duplicate/place it where it belongs. Again, maybe a checkbox that copies that mesh source and creates it on export at the x,y,z cordinate where the instance is supposed to be. I get it might not be "exact" for every Daz asset, but at least it's something that might save us some time in the workflow.

Already on my todo list.  But if anyone wants to contribute this as a script, that would be much appreciated by myself and the community!

9. Make it paid gateway so you can maintain it, it kind of sucks to offer this bridge and then sort of leave it like a ghost town without frequent updates. I know that if this were consistently maintained, I'd gladly pay for it to be improved over time.

I think Daz3D has already committed itself to making the Daz Bridges completely free and open source.  In my opinion, that decision is much better for the community longterm.  However, I do appreciate the need for the existence of a premium or VIP subscription support service for game studios or other businesses which need time-critical help.  I think offering a yearly developer subscription plan that includes priority support separate from the forums, PC+ discount pricing and the interactive licenses for $5 or $10 would be a very big hit.

I took a look at the Enterprise licensing plans and they are actually very competitive, when you factor in the included interactive licenses and number of seats.  If they included VIP support, maybe that could be an option for you.  If you need higher quality integration with Unity Engine, you may want to try the Unity Asset Store Tafi products.

Hope this helps.  Good luck with your projects.

Also, you may want to consider trying the Unofficial DTU Bridge if you haven't already done so.  I've added a number of bugfixes and quality of life improvements for HDRP, as well as URP and Built-in RenderPipelline support.

https://www.daz3d.com/forums/discussion/494626/unofficial-updates-for-daztounity-bridge-urp-built-in-pbrskin-anims-dforce

chris_63502790

Thanks for taking the time to reply! Much appreciated. I'm so happy to hear that improvements are coming, even if a ways down the line, progress is a good thing, even in small measures!