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.

The idea was coined by user Retry on the forum here:

https://forum.substance3d.com/index.php/topic,30094.0

The request is to faciltate the ability to check the work immediately on a different screen with a different camera. The most obvious example is being able to paint in the 2D view (UV view) and seeing the 3D view update; preferably on different monitors as well. As Retry's example outlines, painting on the Cintiq and seeing 3D viewport updates on the second monitor.

An example from Mari, it allows you to view your work simultaneously from different angles practically immediately after "baking" the paint strokes. This makes for a very smooth experience when dealing with shot-based texturing.

We have in our project structure mirror directories between our source assets (Substance painter, designer, photoshop, 3dsmax, etc) and our assets used bu our game engine (.png, .tiff, fbx, etc)

We would love to improve our studio workflow by having a SP plugin automatically exporting textures in the correct mirror path.
The Javascript is great, but is lacking those two very simple and basic functions:

alg.fileIO.CreateDirectory(path) to simply create a directory.
and alg.mapexport.SetExportPath(path) to change the current project export path.

Those are quite basic and would without a doubt be quite easy and quick to implement. It would be great if they could be added to the API in a future update.

Substance Painters UV viewport is 1X1 texturespace.

So when working with non square textures you need to stretch the UV to cover 1X1 space.

Due to this Painter works from a stretched UV and that will stretch the textures placed on it.

A good example on problems you can get is when your trying to add a checker pattern to a UV'd sleeve on a shirt, in a bent arm position. Its a complicated shape, with folds and with a bend in the middle. So not always possible to keep it orientated horizontal or vertical.

Because of this your not going to get the same clean checkerpattern all over the arm. It will be distorted, due to shape but also heavily distorted just because of the UV ratio.

Would be sooo golden if Substance support 1X2/2X1 ratio textures all the way. Viewport, generators and masks etc.

Hi guys.
Please release this patch ASAP!

We do not have the ability to remap textures that plug into channel input slots. But this is critical to the texturing workflow!

Any channel or port, such as color, roughness and so on, that can accept a texture should have the ability to offer remapping controls for that texture.

We need spline based remapping as in the Adobe Photoshop Curves adjustment. The levels controller is terrible.

Good examples to reference include the 3ds max has a node called "Output".

This way we can source 1 texture, plug it into a texture slot and remap the image just for that input slot.

This is incredibly important!