Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Galen Helfter

Pages: 1 2 [3] 4 5 ... 28
If you have access to Autodesk Maya, you should be able to inspect the workflow options that the Substance plugin has in that. In that we have:

  • Ability to apply a workflow to a Substance material (sbsar)
  • Ability to apply the exact same workflow to a set of images
  • Generate a custom workflow via button, traversing the node graph forward of the substance graph node and saving it
  • Ability to apply these custom workflows to both sbsars and a set of image files, using the same interface as the ones provided

Personally, I would prefer we implement a data-driven node graph setup like we have there, so we can operate on workflows as data instead of linear scripts, as well as being able to generate new ones via traversal of the material graph.

So you want it to be able to operate on an array of image maps instead of only an sbsar file, like we have in Maya? We could provide documentation on what is being done, although the script is open to be inspected, but allowing it to operate on maps from Painter/Designer/Alchemist seems like the better overall solution.

It is possible to do this, as we have done that in the Maya plugin, but it will require some UI work to map usages as well as perhaps some reorganization of how the 'Substance to ...' workflow scripts operate. The system in the Maya plugin is much more sophisticated, so not all features from it can be brought over immediately.

I'm not certain on the exact gamma values added, I will need to look into that system to see exactly how it was originally constructed. I am not as familiar with that system, as the image baking and caching system has been unchanged since the original release.

I do not think that we are actively applying a gamma curve to anything, but I think that color maps (emissive, basecolor, diffuse, specular) will have an sRGB curve applied and cooked in, which then Max might reapply a curve back on top when loading it back in as a bitmap.

It looks like for some reason, a Qt widget was clobbering the input value for integer sliders when creating the slider widget. I should have a fix in for 2.4.2, we'll look at cutting a release after 2.4.1 to have some further changes like this.

Need to make some further changes on the UV tiling, have a few minor things to iron out with that before releasing 2.4.2.

Those scripts are useful for renderers that do not handle substance outputs and do not fire the pre/post render events. VRay GPU is really the only one that historically did this, and that may not be true with its more recent versions.

Even if we disable them, scenes could reference them, so we will probably always ship them and disable them to do nothing when the time comes.

I'll try to take a look at resetting parameters, but it will probably be in 2.4.2, as I want to release 2.4.1 after we finish testing final changes. If you can email me just the sbsar file without a scene, that will be more useful than a video.

I do now have tiling working and updating in interactive render, so I think we should have that working for the next release.

3ds Max only typically supports single output map nodes, so the Substance2 node, the original Substance node and other similar nodes, such as the OSL node, are actually implemented as a hidden 'cluster' of nodes, with the output selector nodes as sort of hidden nodes. These nodes are always there, even in the case of the normal and base color maps, it's only whether or not they're visible that changes.

The visibility of these can be toggled in the configuration options for the Slate Material Editor. Go to Options, then Preferences, then ensure that 'Hide Single Map Output Selectors' is toggled.

I think in some cases it doesn't like hiding them. There's nothing to do, they're always there, it's just whether you see them or not.

Octane doesn't take normal Maya image inputs, so I think you will have to export the outputs as maps and load them through the Octane image node. It's possible that we could make it work, but I think it would be a decent undertaking.

1. Should be solved by removing those scripts.
2. Should be in review and testing soon, I now have that working at least between renders. That should be in 2.4.1, which should be done when this clears testing.
3. Will need to look at still.

Looks like I have something promising for tiling, the initial estimation of what the issue was looks to be correct.

Substance Designer 2020.2.0 was released today. Materials created from that should already be compatible with this release of the Maya plugin.

This is about using procedural materials from Substance Designer in 3ds Max, so a bit lost on the Painter thing.

As for the topic of this, we've got builds we're working on for a 2.5.0 release of the plugin.

Not yet. We're trying to finalize the Redshift and Arnold interoperability first, then move on to further renderers after that.

For tiling? Not yet, but I'm going to finish it before the 2.4.1 release. It's the last thing we have planned to complete for that release.

For the crash, there is no fix on the plugin side that I know of, you need to remove those scripts from your render settings as per the instructions above. The concept of what they're doing looks like it will cause trouble. So they can't be fixed for that purpose, they can only not be run.

I think the link is just missing from the bottom, I'll talk to our web team to get that changed.

In the meantime, they are also here on the forum:,31210.0.html

Pages: 1 2 [3] 4 5 ... 28