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 ... 20
It might have a less standard image encoding, such as something with 16-bit.

I'll take a look at it.

Can you clarify what is meant by this^ For example, are you considering a case in which shader parameters from a Corona Material modify a connected Substance?

In the Maya plugin, you can republish the sbsar from designer and reload it without losing any of the current input values or keyframes, excepting any inputs/outputs that have been deleted..

The substance to corona maxscript handles neither anisotropry outputs nor ambient occlusion outputs as of now, as can be seen in the script:


So that would be a further feature add to take advantage of the corona material. A further change that is also very important will be to further refine the workflow scripts to use the output usage instead of the output name.

I'm uncertain as to whether the default there is something with the display or something with how it's loaded. Since it does correctly reset, it may be on the display side currently. We will have to look at that. If you can upload the sbsar, that will be easier to test with as we know the problem parameters there.

As for reloading, the plugin has, since initial release, not handled reflecting the existing inputs back to a reloaded sbsar file. However, when I wrote the Maya 2.x series plugin, I did accomplish having a non-destructive reload, so I think we will want to handle this sort of mutation of values in a similar manner. It will be more complicated to do it in 3ds Max because of how attributes are implemented in the program, but it can and should be done. It is how a reload is expected to work.

What would be nice as well, is to see if the workflow script code generation feature can be ported from the Maya plugin to the 3ds Max plugin. It would both be more powerful to the userbase and would be better for the longevity of the plugin, as it's easier to use that to react as the various renderers change over time.

Will take a look and file a further bug.

We are going to first want to make some further infrastructure changes, as to be able to have a faster release cycle, like we can have with the Maya plugin or also now the Modo plugin. With those changes, we will have smaller, more frequent updates moving forward as compared to the past larger releases.

We have two options available to finalize the issue, each that will take time to complete. We've talked to Autodesk about what the solutions are, as they have had to deal with it as well.

I think we've close to decided which one to go with, but the decision has no clear winner between the two. Each will have negative consequences.

11,000 is the page views, so it cannot be taken as a hard metric of people viewing.

Permanent links to 2.1.0:

Maya 2017:

Maya 2018:

Maya 2019:

Maya 2020:

Maya LT 2018:

Maya LT 2019:

Maya LT 2020:

Permanent links to 2.0.1 (initial release):

Maya 2018:

Maya 2019:

Maya LT 2018:

Maya LT 2019:

Permanent links to 2.0.3:

Maya 2018:

Maya 2019:

Maya 2020:

Maya LT 2018:

Maya LT 2019:

Maya LT 2020:

I did manage to repro this, for some reason it doesn't like loading the GPU engine with Maya 2018 when started that way. It oddly doesn't happen on 2017, 2019, 2020, etc., so I'll check it out later for the next release. As there's already another small patch release planned for next week, we can look at fixing it for that.

I'll have to look at if somehow it just isn't loading, or whether something is messing up the filepath somehow.

As a workaround until then, is it possible to set the Fusion UI flag through environment variables in the Maya.env file?

As for the light/dark theme, that is something each team would need to look at, and would be better proposed in their respective forums as a request. It's easier for them to keep track of it if directly sent to them rather than through indirection.

Yes, I see what's wrong. This should be fixed soon.

I think it isn't just the hardware, but MacOS. I don't remember what version of MacOS that newer OpenGL was supported on, but for the longest time OpenGL 2 was the only thing supported.

The GPU engine requires at least OpenGL 3, possibly OpenGL 4, so it may just not be able to work without an upgrade to the OS or machine at this point.

The OpenGL 2 version of the Substance Engine has been deprecated for a while now, since before the 2.0 plugin release I think.

I did change the path to 2018, I forgot to edit it after copying the path I was looking at.

I haven't seen this before, but it may have to do with the GPU engine failing to load on that old of hardware. Does Maya give you a crash report dialog? There should be a callstack in there which would be helpful.

Which version of the plugin are you using?

If using a newer plugin, you can try manually switching to the CPU engine, the plugin config file will be at ~/Library/Preferences/maya/2018/substance/substance.cfg
Then set EngineType to 1.

Hello everyone,

Today we have released the 2.3.2 version of the plugin, which is mostly a bugfix release on top of 2.3.1.

2.3.2 Release:
  • Updated Substance Engines to 7.2.9
  • Fixed issue with rendering with Redshift/VRay crashing in 3ds Max 2018, 2019 and 2020
  • Debug assert errors will no longer appear
  • Substance2 node now correctly has the scripting interfaces for iMultipleOutputChannelsWithValues
  • The Substance source entry on the menu will now open the Substance Launcher to the Source tab if it is installed
  • Substance materials should now update correctly when working with the Corona renderer
  • Substance outputs are no longer temporarily replaced with images when used with VRay Next
  • Render compatibility dialog removed from automatically apppearing. It is still available in the settings dialog if needed
  • Fixed possible issue with exporting an fbx while substance material is applied in 3ds Max 2021

Known Issues:
  • In 3ds Max 2018, exporting an fbx with a Substance material attached to the object will crash in the fbxmax.dlu plugin. We are currently talking with Autodesk to see if there is something on our end that can be done or whether it is a limitation of the older release of the fbx integration. The previous workaround was unreliable and was removed. This does not occur in 3ds Max 2019 or newer.

This version is released for 3ds Max 2018, 2019, 2020 and 2021. The 2021 version can be downloaded in the stickied post with links, and the website should be updated as soon as possible to have a button for it.

Galen Helfter

The 2.7.3 version was released today, and has a package for Modo 14.

Those issues will be resolved in the next release, which should be today or tomorrow.

The current plugin release for 3ds Max 2021 is the same version that was published earlier, although the crash mentioned will not happen in 3ds Max 2021, as that uses python 3 and has different code there because of that.

I do not know if Vray Next has been published for 3ds Max 2021 yet though.

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