In https://docs.substance3d.com/spdoc/gpu-drivers-crash-with-long-computations-128745489.html, one of the suggestions is "Disabling the TDR completely -> Set "TdrLevel" to 0 ( not recommended )". Even if it says "not recommended" this suggestion cannot be safely done in a PC running DX12 applications. For DX11 application TdeLevel=0 effectively is the same as an infinite timeout, however with DX12 you also get page faults which go through the TDR handling mechanism. When these are triggered, it will cause an unrecoverable PC hang. A number of substance painter users in our production had followed this advice and it took us a number of weeks to track the source of the issue down.

If you have ever created a SBSAR material for Painter you may have noticed that the experience of using it in Designer and in Painter is pretty different. There is a bunch of specificities in Painter you have to know in order to make it work as you wish – when possible – and once that done you discover that the UI of your material is not exactly what you had at the beginning in Designer.

Not only this is disturbing (after all it is the same material that is manipulated) but as a material designer it requires quite a lot more work to adapt your material also for Painter than if the SBSAR features where fully supported and the UI components behaved consistently. At the end of the journey, in a production context, the impact of having to develop and maintain a material for both applications is, well, “substantial”.

In order to streamline the workflow between Designer and Painter as well as the use of materials in Painter we think these 2 points have to be reached:

• A full support of the SBSAR file format in Painter: Everything that can be set up in Substance Designer in a graph to define it behavior and its UI, and that is supported by SBSAR, should be available in Painter.
• A similar experience between Painter and Designer when the user interacts with a material UI: Since SD 2018.2 there is a similar look and feel between both applications, with the introduction of similar graphics components for the parameter sliders in particular. The actions available on these components are unfortunately still quite different and this goes beyond the question of aesthetics or behavior, there are also some strong functional limitations that prevent the user to tweak the material the same way she could do on the same SBSAR in SD.

In terms of functionalities it means:

Most important points:
• Full support of parameter specificities: The configuration of a parameter defined in SD should also work in SP. This concerns in particular:
- the min and max of a slider: When not clamped, the min and max parameters of a slider define its initial range. It should still be possible to enter values out of this range and the slider should adapt its range as SD does.
- the clamp mode: Whether a parameter range is clamped or not should be supported. Currently all parameter ranges are clamped and that is a huge limitation.
- the display of the number of decimals: Parameter values are currently clamped to 10e-2. That is also a huge limitation. Painter sliders should behave like the ones in SD, where user can use a custom number of decimals and the display adapts itself to it.
- the step: the step defined for a slider should be respected. To do so a consistent decimals display should be introduced first.
- the initial value.

• Visibility attribute should be supported for image inputs: if an input has a condition that makes it hidden, it should not be visible in the Properties panel. Not having this currently prevents attempts to do a consistent UI for materials using contextual parameters visibility.

Important points:
• Reset parameters to their initial values :
The initial value of a parameter is extremely important in the design of a well-balanced material. It should then be possible:
- to reset each individual parameter (by a new item in the existing right click menu for example)
- to reset the whole material (as in SD)
- to see at a single glance if a parameter has been modified from its initial value or not. Note that this is something that is not currently available in the UI of SD either but some thoughts should be done there too in order to improve visual user feedback. In practice a fix could be as simple as using a Bold font to display the value of a modified parameter instead of a regular font to easily identify it as such.

• Material attributes visible in the tooltips of the shelf elements:
There can be a lot of materials and graphs in the shelf and artists often don't know them by heart so they need to be able to read information about them in order to choose the one to pick. Currently this is possible when a graph has been added into the Parameters panel (which is great but is another need because it is a bit too late for the picking workflow). So all the attributes of a graph should also be visible in the tooltip displayed on top of the thumbnails in the shelf. This includes in particular the description, author, category, tags but also ideally its upload date.

Also important but longer to do:

• Nested and external presets should be supported in SP:
In SD there are 2 ways to create presets for materials, both are interesting and none is supported in SP. Nested presets allow the material author to provide a set of variations the texture artists (in Painter, Designer or even in a game engine) can use. External presets are a great addition to this, they can be used for example by Art directors or team leads to provide indications or references to texture artists. This would be very efficient to get these references directly into Painter. It would also considerably extend the life of our materials for a cost that is considerably lower that modifying the material itself. Currently there is no real viable turnaround for this.

The expected behaviors in Painter are:
- Being able to see the list of the nested presets of a material instanced in a material slot of the Parameters panel and apply the selected one
- Being able to load an external preset file (.sbsprs) on a material instanced in a material slot of the Parameters panel. Note that there is no dependency to preserve to this file, it is just the application of a set of values.
- Being able to save a preset file from the configuration of a material instanced in a material slot of the Parameters panel.

Thank you very much for your understanding of the difficulties we are currently facing and for your attention to these requests to try to solve them.

When I instance a material or smart material and have the blending mode on the original set to anything other than it's default I have to change the blending mode of each channel in every textureset I have it instanced to, because the instances have their blending modes set to default again. For instance, If I instance a material whose basecolor I want to be multiplied over what is below, I set the blending mode to multiply. But when I instance this material to any other textureset, It comes in as normal and then I have to go through all texturesets and put it's blending mode to multiply by hand. That is a lot of unnecessary work.

In the latest version (2018), you removed the little "+" and "-" buttons from the slider controls, for things like UV Scale, UV Offset, etc. I used those all the time in previous versions to "nudge" textures into place with very fine control (2 decimal places). Please add them back. Ideally with a preferences setting to specify how many decimal places of accuracy.

It's now very cumbersome to have to constantly click the mouse in the numeric field and enter values manually over and over to get things just right, and just dragging the new slider doesn't offer enough control.

And also, please change the new numeric field highlighting color. When you do have to type in a value manually, it's hard to see what you have selected with a dark gray highlight on a slightly darker dark gray background.