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 - ben.black

Pages: [1]
1
Thanks for your response NevTD! To provide a little more context (in the event that this is seen by Adobe staff), here is why I asked. I work at a company that manages a large amount of assets created in several different DCC applications, supported by several different render engines. The common thread with all of them is that the texturing is done exclusively in Substance Suite. What is needed is ONE environment used for rendering to proof these assets. Several combinations of DCC applications and render engines produce differences in appearance- there is no easy way to calibrate them in such a way that the same asset could be rendered with any of these app/render engine combinations interchangeably, and will come out looking the same. What better place to find that continuity than leveraging the IRay render engine that ships with  Substance Suite? For larger scale operations, it just seemed likely that if the Iray render engine exists in Painter and Designer, some way would be provided within the SAT for generation of these renders, so that you are certain that what is seen by the creator of the asset can be reliably reproduced by those on the receiving end. For now, it appears as though the solution you mentioned is the only option. I appreciate the detailed response- thanks again!

2
I just watched a video on YouTube entitled "Substance Designer 5.3: Using the Nvidia iRay Renderer" that walks you through how to use Substance Designer to render a textured asset. I've heard it said that the Automation Toolkit can reproduce almost all processes that could be done using Designer- is it possible to automate renders of an object with textures applied using the Substance Automation Toolkit? For instance, say that I had an fbx with a model and camera contained within it, an hdr image to light it, as well as all the file textures needed to apply to the model. Would I be able to combine these elements and generate a render of the model against a white background? Most importantly I'm curious if it can be done, but would also really appreciate it if there are any videos, articles or resources that may be out there that shows anyone doing this. Thanks in advance for any insight you can provide!

3
Substance PainterSubstance Painter - Scripting - Re: Export layers as .spsm
 on: September 20, 2018, 06:11:54 pm 
From my standpoint, the need for generating a smart material file is more about recovering past work than it is looking towards the future. My company would like to extract previously made materials from potentially thousands of Painter files, but it appears for now at least that there is no good solution through scripting. I'd be interested if anyone out there has been faced with a similar task, and how they might have approached it. Through the current API, I see that I can get a full listing of layers/folders present in a file, as well as blending modes. Using the two in combination I can sort of roughly determine separate materials. The main challenge now is finding a way to separate them into individual units as we attempt to populate an internal library with previously created materials.

4
Substance PainterSubstance Painter - Scripting - Export layers as .spsm
 on: September 18, 2018, 12:53:37 am 
Is it possible through scripting to specify any number of layers from a painter document and export them as a ".spsm" file?

5
That was it Jay- "Create a texture set per UDIM tile"! It makes sense why Painter would work this way, although I didn't make the connection that it would override the naming I'd set up in Modo. Thank you so much for your help with this- really very cool of you to take the time you have with this thread. Hopefully I can return the favor for someone else as my experience continues to build.

6
Again, thanks for responding Jay. I just wanted to add to this thread to bump it back up to the top of the forum listings, as I have not found a solution yet to this problem. If anyone reading this has been able to successfully get names from their Modo FBX meshes to actually carry over in the naming of their texture sets... well, I would love to hear a confirmation that it is even possible. I would assume it is, but the most obvious methods I've outlined in my previous posts do not appear to work and this apparent limitation is a little hard to accept. Thanks in advance for anyone who might have the answer!

7
So close! First off "Ctrl + Alt + right mouse clicking on it" is *GOLD*. Not sure why I never found that but this will help me moving forward tremendously- thanks so much for including that! The only remaining thing is best described by this image from the documentation:

 

I realize that the naming for the Texture Sets cannot be changed inside of Substance Painter, as it is derived from the mesh that is imported. In that screenshot you see SP Texture Sets that are not named "1001, 1002..." and so on but instead are named "gun" or "legs"- they are described in the text beneath as being named according to their Material IDs "created during mesh creation". When I imported the new mesh with the two missing objects, it appeared as though whatever mechanism inside of Modo determines Material IDS is reordering the names as they appear in Painter, and as a result they are blowing up the existing texture assignments. My thought was that if I explicitly was able to name these materials in Modo to what they were in the original Painter file (the 10017, 100113, etc) this would override what is currently happening, and as a result the existing textures I'd painted would be assigned properly despite adding these new elements into my mesh file. Does that make sense? I can see from the documentation that there is a way to add custom names, but what I'm not seeing is a Modo-specific way of going about this. So are you saying that this cannot be done with Modo? In other words- say I was creating a completely new project and wanted to have my texture sets named "arm" and "head". Is there a way to accomplish this using a mesh exported from Modo? It appears as though you can accomplish this with at least one program, otherwise the above picture is very confusing. Again, thank you for taking the time to provide these responses- I'm stuggling to get to the bottom of this and am afraid I have not arrived at the answers on my own despite my efforts.

8
Hi Jay-

Thank you so much for taking the time to respond to my post- I appreciate it! I'm not sure if it's because of the new SP 2.5 update or not (might this be a bug?), but I'm still not understanding my original question as it concerns Texture Set naming within Substance Painter. As a test I made a sphere and a cube, assigning a unique texture to each, and placing the UVS in the 1001 and 1002 tiles respectively as you outlined in your response. This was composed in a single UV map, and a single layer for the geometry. I exported in two different formats for the test- OBJ and FBX 2013. In both cases the imports were successful, but the texture sets came in as "1001" and "1002", despite uniquely naming the two material groups AND the actual materials inside them. I should add that I am using Modo 10.2v1.

It is important for me to understand how this works, because I created a character and fully textured it, while absentmindedly forgetting to add two critical elements in the FBX file. As fate would have it, I noticed said two elements were missing only after finishing the textures for all of the other elements. I read a number of threads about adding elements to your Mesh file subsequently via "Edit>Project Configuration". Mentioned in these posts was that it was critical to retain the names of the materials for existing elements so Painter knew where to distribute them on the new mesh being imported. Even though I just simply added the missing elements, being sure to properly UV them and add new materials to each, I did not alter anything with the other existing elements. When I brought in the new FBX, the textures were jacked on easily over half of the elements I'd already fully textured. Clearly there was a reordering of the material names. Ultimately I wanted to render this out with Iray, but I do not want to have to re-texture everything again in order to do so.  Another downside to this texture set naming problem is that with 20+ different elements it becomes an excrutiating process of turning on and off layers when i want to target any element to focus on, as the numerically named texture sets make differentiation impossible.

Has anyone else experienced this problem with texture set naming? I've spent many hours trying many different ways to affect the naming within Painter and nothing seems to work. I'm not sure if I'm battling a bug or if I'm just ignorant of some critical factor in this process. A simple "name this in Modo and the Texture Set name in Painter will correspond" is essentially what I'm looking for. Again, thanks for taking the time to respond to my post.

9
I am looking for some clarification as to how the naming of texture sets in Painter is affected by objects imported from Modo. Even though all of my Material Groups in Modo have unique names, when imported into Painter they would appear as strings of numbers like "100117" or "10013". All of the objects in the FBX I exported from Modo had their own UV set, positioned in the first UDIM tile (1001). Clearly the names are coming from this first tile number with added digits counting up from 1 for as many different objects were in the file. As it concerns Modo, where is Painter specifically pulling the names for the texture sets? Is there some kind of setting in the FBX I/O options that needs to be on for these to be read properly? I also tried naming the material inside of the Material Group (that by default is named "Material") but this didn't work either. I tried opening the Modo generated FBX in Maya and the separate objects and their materials were in the file with their assigned names. Any insight you can give would be most appreciated!

Pages: [1]