Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2025 Daz Productions Inc. All Rights Reserved.
Comments
I hope too to be incorrect and frankly I didn't study much this new SBS 5.5 release. But seeing that several plugins are being developed for 3D apps and they all support SBSAR directly (i.e. the full SBS shader natively), makes me doubt how the MDL authoring is actually going to be useable directly in other applications.
Well there was discussion a while ago on the Substance boards about other rendering environments that used IRay that didn't support substances directly, DAZ in particular was mentioned. Someone from Allegorithmic said that they would look to provide a way to bring the work from developing in Substance directly through mdl's to said environments.
Substance has been able to export mdl code I thought. The thing that did specifically get mentioned was exposing variables. How that does or doesn't play out I couldn't say yet as I also haven't had time to research 5.5 yet. What my understand is though is that the mdl code should be fully functional in an IRay environment so that would mean there should be no unaccounted for dependancies at least.
Well this video just came out and is addressing SD 5.5 where it looks like they are specifically addressing those questions.
On a related note, I've noticed them referring to SD as 'the first mdl authoring environment' along with discussion about how mdl's are becomming the new 'standard' for material definition in the graphics industry (my paraphrasing.) So I'm interpreting between this and the video that they are looking to provide a universal mdl solution with or without plugins.
I was kind of hoping we might get some admin attention here.
I think the MDL file I created is fine, but Studio is having a problem digesting it.
I guess I am opening a ticket.
Keep us up to date on what you find.
So I went and asked over at Allegorithmic and the generic sorta answer I got was that the created MDL might well call Allegorithmic's own custom MDL files. Which is not necessarily a problem, unless of course I want to distribute my custom MDL. Do I then need to include their MDLs when I bring my over to Studio and want to distribute it?
Seems... silly. Isn't Nvidia MDL basically self contained? Aren't all the libraries you need built into the language? Seems like one ought to be able to build one without relying on custom anything (up to a point of course).
You can if you write your own distribution functions, and aren't simply setting parameters for ones that somebody else has written.
- Greg
Greg that seems like a complete sentence, but... I'm missing something vital. I think its the "write your own distribution functions" part that has me confused.
I think it would be a good exercise (for all of us) to discuss a concrete example. Perhaps you could post some actual MDL code so we can be talking about something specific and see exactly what's being referenced, etc.?
- Greg
There is an example covering exactly this in the video I posted above.
It effectively means that the advantage of using SD is having a node based environment rather then typing code out and having relatively instant feedback, but one has to watch out for any Substance specific nodes and basically recreate them from scratch when needed.
Will have to wait until I get home to do that.
Unhappy with the ticket I opened and its lack of resolution.
Allegorithmic says "maybe its a bug in Studio".
DAZ says "the problem is with the MDL file".
I really dislike sitting between vendors whose products I have bought and having them point fingers at each other and give 1/4 answers to direct questions.
Allegorithmic says their MDL files are not doing much and that is not likely they are involved, but even when adding their resource path into Shader Mixer, the MDL file fails to compile and all DAZ support is willing to do is point to lines in the release build's log file that point to things that are "not delcared", but won't say if that's because of the version of MDL in the release version or because they are unique calls to something outside of the core Nvidia MDL.
Here's the import declarations from the MDL, perhaps someone here can tell me if these are standard or custom:
import ::anno::author;
import ::anno::copyright_notice;
import ::anno::description;
import ::anno::display_name;
import ::anno::unused;
import ::base::rotation_translation_scale;
import ::base::tangent_space_normal_texture;
import ::base::texture_coordinate_info;
import ::base::transform_coordinate;
import ::df::diffuse_reflection_bsdf;
import ::df::directional_factor;
import ::df::fresnel_layer;
import ::df::microfacet_ggx_smith_bsdf;
import ::df::scatter_mode;
import ::df::weighted_layer;
import ::state::normal;
import ::state::texture_coordinate;
import ::state::texture_tangent_u;
import ::state::texture_tangent_v;
import ::tex::gamma_mode;
import ::tex::wrap_mode;
Or perhaps you could point out that I have a glaring misapprehension of how this works... because that is entirely possible, this being my first real foray into this.
In my limited experience with MDL, I've always seen just the entire module(s) imported. That being said, something like this would be completely typical:
mdl 1.2;
import df::*;
import state::*;
import base::*;
import tex::*;
import anno::*;
If any particular call you subsequently make returns undeclared, then I would assume it doesn't exist as called in the version of the module imported.
- Greg