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 ... 28
We can add something that bakes the sbsar and its constituent outputs out to texture files, replacing the connections in the Slate material editor.

In Maya, the 'Substance to <...>' system is significantly more powerful. It can work on image files, from say Painter or Player, and not just the respective Substance graph node. It also has the ability to generate these from the Hypershade, where you can connect your own shader graph if there's a shader we don't support for example, and generate your own 'Substance to ...' tailored to your own needs.

There are various filtering modes that 3ds Max handles, I'll need to look further into what they are.

Bit depth can be overridden based on the sbsar output, some aren't representable in 3ds Max, notably 16 bit floats.

Yes, the mixmaps for the most part should be unnecessary, there may be a care or two they'll stay. There is an approximation for metalness affecting certain inputs to the Corona material. Since the new shader has two modes, one as PBR metal/rough and the other as PBR spec/gloss, we would never need to do that again, as we could determine the usage based on the outputs available and so would never be connecting a metal/rough sbsar to a spec/gloss shader, like we are now. We would pick the metal/rough mode for an sbsar with that, and toggle to spec/gloss if we don't find the suitable outputs for metal/rough.

What is meant by that it will change, is that it will for both Spec/Gloss and Metal/Rough workflows, as we will only retain functionality for the legacy shader moving for versions previous to Corona 7. For all that and beyond, the workflow script will only generate the new material type. The new shader supports both workflows, so things such as the 1/IOR approximation for metalness will not remain. It was not intended as a rhetorical response, and if taken so, then I would like to correct that and explain its meaning as pertaining to an actual change in behavior of the script.

It will take time and experimentation to catalog all the existing setup and its difference as compared to standard bitmaps.

As of now, we set the gamma correction internally in the output bitmap to 2.2 for base color, diffuse, specular and emissive maps, as determined by the default channel usage set in Substance Designer. All others have the gamma set to linear, or left as the default. So depending on what doesn't quite match, either an application of 2.2 in a color correction node, or an application of 0.4545, at 1.0 / 2.2, to invert the curve application, might need to be applied to handle the color transformation. What I will need to see is whether this actually does anything for internal rendering, or whether it is what's causing a further curve to be applied on the bake output function.

The ones set to linear are bump, roughness, metallic, height, opacity and glossiness, so any remaining maps outside of those channel usages and the color ones mentioned prior are set to whatever the default gamma is for a bitmap in 3ds Max.

I understand the question then. Most of the visual parity is going to be difference in gamma curve application, and perhaps sampling filter. I don't have an exact answer, which we would need to properly have for that documentation, and will need to perform an investigation to have that correct. I'll forward this to the demo art team and see if they can publish something like this, and update our shader docs online.

I think it'll be much easier to create this documentation as we recreate the Substance to Corona converter for Corona 7 though. All that's going to need redone, as whatever we have now is going to be replaced with a metal/rough workflow in the standard case, and probably a more direct spec/gloss workflow if we can identify that the material doesn't have the right outputs for metal/rough. In either case, for the new shader, it's going to change.

You heard correctly, I made the mistake of not associating an email chain with this and that's my mistake.

We are actually in conversation with them about aligning Substance with it, which I've now caught up on and read since the previous post. We're aligning on general export and workflow for Painter mainly right now, but we will be able to work with their team to ensure we've got the proper workflow for the 3ds Max integration with their new shader model while we're doing that.

It does look like it will break compatibility, especially if the legacy node object is not available anymore. So we'll want to address this and have it ready while we're aligning with it on everything else. I do have their shader specification, so we should be able to work with that.

I'm going to work with the demo art team and with the Corona team, to make sure we have a proper representation. Since we'll be redesigning how the workflow works, we can handle imports from our other software and have documentation on how that script works and what it's doing, and to try to match it to explanation of what to do with outputs from our main software. Since you're interested in ensuring that being the case, this would be a natural opportunity to ensure our documentation, workflow script and all are aligned.

We could just allow a finalization step to 'commit' the graph node out to image files, if that would be helpful. That would be much simpler than attempting to match it with Player.

There is some similar code written already for the other shader compatibility script we had to do, so I can investigate repurposing some of that to do that functionality.

If the height position is set to 1.0, then that's the default value for the material. We might be able to set the VRay displacement multiplier different in the Substance to VRay script, but the scaling can sometimes be different based on the material. You may also be able to fix it by changing that value to something more appropriate, instead of the height position on the sbsar.

Does it render if you try it? If it does, then I think we'll just need to add a new shader workflow option for it. Otherwise, we'll have to do more.

It looks like this is meant to replace the old Corona shader in entirety. Do you know if the legacy shader still works for now at least, or is the workflow script completely broken?

We're going to need to make sure it still creates the legacy one if the older Corona Renderer is installed, and makes the new one beyond a certain version.

You need to make sure the plugin is enabled in the plugin manager for that to work. In the future, I guess we'll make the toolbar automatically load that when that button is pressed.

Clear the one in your Houdini install and replace it with the one from the Substance plugin, not the one from the C:\Program Files\Allegorithmic\....

The current plugin should have 8.0.3, not 7.0.0. What's happening, is it's loading the one from Houdini first, because the houdini engine integration has a copy of that file too.

Not as of now. I'll try to get to it sometime this week if I can. I'm working with our QA to make sure we can repro it first.

Copy the substance_linker.dll from the maya plugin install into the Houdini install to update that file.

We're working with SideFX to get it properly resolved.

Interesting, I'm not quite certain what is doing I'll talk our QA about filing a bug for it. It could be how we're doing sampling/filtering, but I'm not quite sure.

You're using the old plugin, which won't support newer sbsar files, as the Substance Engine is older. As long as you're using Maya 2017 or newer, you can download the newer plugin off of our website, which should support the files you get off of Source.

You should be able to migrate any previous scenes that used the old plugin to the new one as well, there are utilities for that.

We used to have it working to some degree, but it wasn't functional in the right way and caused significant issues when running 3ds Max batch, so it had to be removed. So we'll have to redo it and add it back in. It's something we're looking at though.

Pages: [1] 2 3 ... 28