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 - Matthew Vitalone

Pages: [1] 2
It would help out our workflow a lot if we could use data generated in our custom shader as the source channel for Displacement in Substance Painter.  We do all of our heightmap blending in our custom shader rather than in the Stack.  Since we are using a layered shader, we don't have height map data in the layer stacks.  Right now it appears the only places you can feed the Displacement is from the Height or Displacement stacks.  For Displacement to match our shader we need more flexibility in feeding the Displacement Source Channel.

I feel that with UE5 coming and the introduction of Nanite, the Displacement support in Substance Painter is going to become very important.


Yeah I ended up trying to store the data in project settings.  However it's definitely not straightforward, as a alg.project.setttings call from my shaders custom_ui.qml file sets data that is not available when alg.project.settings is called independently from my custom exporter.  I ended up having to also store all my data in an external JSON file so that two different Javascript contexts could both access it.  Additionally it's quite fragile as the data is tied to either shaderID or shader name, both of which can change and leave messy data behind.  Being able to attach it to the actual shader object would be much cleaner, but doesn't appear possible currently. 

Hi, I'm trying to store a "layer_name" variable for a custom layered shader.  I tried using a sampler2d parameter to store the name in since that is the only GLSL data type that can contain string data.  That works, but the shader seems to be trying to load the non-existant texture and it is causing huge performance issues.  It goes from 60fps to 20fps when I store the data this way.  I also tried to just store the name as an extra parameter on the Materials array objects, and I can read it fine, but I can't find any way to set that extra parameter from within Painter.  The only parameter that it seems you can set from Javascript on the shader is the "value" parameter.  Is there another way I can store string values in the shader file and have them be editable by the user?

Ever since version 6.1.1 where this fix went in:
[Python] PYTHONPATH env var is not taken into account
Painter won't load at my studio unless we wipe out our PYTHONPATH environment variable.  All of our other art tools rely on that so we can't do that.  We can't upgrade past 6.1.0 because of this. 
Is there any guidance on how to get Painter to play nice with our existing PYTHONPATH variable?

I'm having the same issue.  Removing my PythonPath env variable fixed it for me as well.  Unfortunately I have a bunch of other apps that require that so I have to downgrade to a previous version until this issue is resolved.

Actually I tried the old workaround and it does work on Painter 2020.  Load times seem close to what they were in 2019.2.  Still slower than I was hoping for, but much better than what I was seeing in 2019.3.  It fails to return the shader parameters, without the workaround, which it didn't on 2019.2.

Tested out Painter 2020 and this issue still remains.  I was hoping additional updates to QML or your internal functions might have resolved this but that doesn't appear to be the case.  This is still a huge problem for us that prevents us from upgrading beyond Painter 2019.2.

Substance PainterSubstance Painter - Scripting - Re: QML changes in 2019.3
 on: February 25, 2020, 11:47:09 pm 
So far I seem to be getting similar results with your workaround as I was with my promise/then workaround.  It does succeed in loading, but it just takes MUCH longer than it did in 2019.2.  If I open the same file in both 2019.2 and 2019.3, switching between two texture sets (which causes the shader custom UI to re-generate) can go from about 2-3 seconds to update to 400 seconds to update.

Substance PainterSubstance Painter - Scripting - Re: QML changes in 2019.3
 on: February 10, 2020, 07:25:52 pm 
Just pinging this again.  Because the issue is not file length, inlining code doesn't get us up and running.  We're still unable to use 2019.3 currently.

Substance PainterSubstance Painter - Scripting - Re: QML changes in 2019.3
 on: February 04, 2020, 03:04:04 am 
Hi Fabrice,
I narrowed down the cause somewhat.  It's not the length of the file that is making it fail, it's the time it takes for alg.shaders.materials() to return.  Below I've added a new version of displayShaderParameters() that will make the custom ui qml I sent you load.
The main difference I see between 2019.2 and 2019.3 is that this load time has gotten much longer.  There also seems to be an issue when you load the custom ui qml a second time.  I put a timer on how long alg.shaders.materials() takes to return and print it to the log.  On a scene with just a sphere loaded, my custom material, and no extra data added it takes 3.5 seconds to load initially.  if I then reload that file, it takes 62.3 seconds to return.  I tried to compare to 2019.2 but it doesn't load the version of the custom ui that waits for alg.shaders.materials() to return.  I know it is much faster since I didn't need to do any of these Promise/Resolve tricks to get it to load.  We are using NVIDIA graphics cards over here (RTX 2080, Intel Xeon 3.6GHZ, and 128GB ram)

function displayShaderParameters(shaderId) {
    try {
      // Retrieve the list of each shader parameters with its full description for each one

      // get Materials.  We do this via Promise as it can take a long time to return
      var materials = {};
      let materialsPromise = new Promise(resolve => resolve(alg.shaders.materials(shaderId)));
      currentTime =;
            materials = result;
            var timeElapsed = - currentTime;
  "alg.shaders.materials() returned in: " + timeElapsed/1000.0 + " seconds.")

           var parameters = alg.shaders.parameters(shaderId);
           var model = {};
          for (var i in materials) {
              model[materials.description.label] = {'material': materials, 'parameters': []};

          // For each parameter, connect it to a QML component inside the
          // common parameters group or a material parameters group
          for (var i in parameters) {
              var parameter = parameters;
              if (parameter in materials) continue;
              var group = "group" in parameter.description? : "";
              if (group in model) {
              else {

          // Order parameters by the order of declaration in the shader
          for(var i in model) {
              model.parameters.sort(function(a,b) { return a.indexInShader-b.indexInShader })
          materialsModel = Object.keys(model).map(function(v) { return model[v] })
              .sort(function(a,b) { return a.material.indexInShader-b.material.indexInShader });
          displayedMaterial = materialsModel[0].material.description.label;
        error => alg.log.error(error)
    catch(e) {

Substance PainterSubstance Painter - Scripting - Re: QML changes in 2019.3
 on: January 21, 2020, 07:36:51 pm 
Yes.  Is there a private link I can send them to?  I can't share them publicly.

Substance PainterSubstance Painter - Scripting - Re: QML changes in 2019.3
 on: January 18, 2020, 02:50:04 am 
Okay I've narrowed down the different results I get in 2019.2 versus 2019.3 and it's very weird.  On 2019.2 my custom shader and custom qml ui both work correctly.  On 2019.3 my shader loads without error but my custom UI fails to load any of the parameters.
I reverted my shader back to an older version and in 2019.3 the custom UI started working again.  Then I started merging in data from the newest version of the shader piece by piece and reloading to see when the UI would break.  Once I get to a file length of 2525 lines of code in the shader, I get this error in the log "[Plugin - customUI/cloud_chamb...] Cannot read property 'description' of null" and the parameters don't load into the custom UI. 
If I remove one line so the length is 2524, it works correctly.  I'm testing with the extra lines just being simple comments "\\" to make sure it's not related to the code itself, and if I add one more past 2524, all parameters fail to load into a custom UI.

shaders.shaderInstancesToObject worked. 

hmm looks like shaders.shaderInstancesToObject might provide enough info if I parse through it.

I'm writing a Custom Exporter and would like to be able to reference data from the shader that is assigned to each Texture Set.  I'm simulating textures rendering at different resolutions in my shader, and I want to read that value so I can export the texture at the resolution that was simulated.  Is there any way to get a link from the TextureSet to the shaderID that is assigned to it?

Pages: [1] 2