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 - dgoyette

Pages: 1 ... 4 5 [6]
In addition, it looks like deleting a graph in Substance Designer, republishing the SBSAR, and then returning to Unity, crashes Unity. Here's what I did:
  • SBS has two graphs in it, G_01, and G_02. Published SBSAR, brought it into Unity.
  • Returned to Substance Designer, deleted G_02 from the substance. Republished SBSAR.
  • Returned to Unity. It immediately crashes.

I've repeated this a few times, always the same result. I've attached the Unity crash file.

This is using the latest version of Substance Designer, along with the latest patch release of Unity 2018.2

I have an SBS file that contains multiple graphs. I'll call them G_01, G_02. If I publish an SBSAR and bring it into Unity, I see the two graphs, and corresponding materials. All good. However, if I return to Substance Designer and add a new graph to the the substance (let's call it G_03), and republish the SBSAR, I can't get Unity to show me G_03. I've tried reimporting the SBSAR in Unity, and refreshing everything, but aside from deleting the SBSAR and adding it to the project again, I can't get "G_03" to show up in Unity.

Substance Integrations - Unity - Re: SBSAR build size
 on: August 02, 2018, 01:10:34 am 
Thanks for the update. Perhaps the biggest issue with the current state of things is that these textures don't do any kind of compression. I generally have Crunch compression enabled on the one-off textures I generate from Substance Painter, but I can't do the same thing with my SBSARs.

For now I'll hold off on any dramatic changes to my workflow, in hopes that this will be addressed in the next few months. Otherwise it's probably a dealbreaker for using the plugin. (I think that 80% of my build size is SBSARs right now).

Substance Integrations - Unity - Re: SBSAR build size
 on: July 27, 2018, 11:52:40 pm 
Thanks. As far as I know, all (or most) of the SBSARs are procedural, and take up very little space on disk. For example, my "EnergyResearchStripedWall.sbsar" is only 5KB on the disk, but is 42.7 MB in my build.

The "paint_matte.sbsar" substance is 3KB on disk, and 21 MB in my build. This is an SBSAR I got from Substance Source, so I don't have control over its settings, but it doesn't appear to be using an underlying bitmap.

Is there possibly a build option I've accidentally enabled that pre-generated SBSAR output textures as includes them in the build, rather than waiting to generate the textures at runtime?

Substance Integrations - Unity - SBSAR build size
 on: July 27, 2018, 09:26:57 pm 
Is there anything that can be done within Unity to reduce the build size of SBSAR files? I've started using crunch compression for my textures, which leaves pretty much all my SBSARs as the big contributors to build size. None of the settings I tried changing in the Unity Inspector for the SBSAR had any impact on the build size.

If there isn't a way to dramatically reduce these sizes, I'll most likely abandon using SBSARs within Unity itself, and just export textures from substance designer.

Here's an example from my build log. Thanks:

Code: [Select]
Used Assets and files from the Resources folder, sorted by uncompressed size:
 85.3 mb 5.5% Assets/Materials/Substance/Gravia/Decals/Dirt/BasicDirtGenerator.sbsar
 42.7 mb 2.7% Assets/Materials/Substance/Gravia/Areas/EnergyResearch/EnergyResearchStripedWall.sbsar
 26.7 mb 1.7% Assets/Materials/Substance/Gravia/Decals/PreRiftFizzleMark/PreRiftFizzleMark.sbsar
 26.7 mb 1.7% Assets/Materials/Substance/Gravia/Decals/Explosions/ExplosionDirt/ExplosionDirt01.sbsar
 26.7 mb 1.7% Assets/Materials/Substance/3rdParty/concrete_011.sbsar
 21.3 mb 1.4% Assets/Materials/Substance/3rdParty/metal_grill_triangle_scales.sbsar
 21.3 mb 1.4% Assets/Materials/Substance/Gravia/Areas/P&L/Warehouse/PLWarehouseWallTransition.sbsar
 21.3 mb 1.4% Assets/Materials/Substance/3rdParty/paint_matte.sbsar
 21.3 mb 1.4% Assets/Materials/Substance/Gravia/Areas/P&L/Warehouse/PLWarehouseUpperWall.sbsar
 21.3 mb 1.4% Assets/Materials/Substance/Gravia/Areas/P&L/Warehouse/PLWarehouseLowerWall.sbsar
 21.3 mb 1.4% Assets/Materials/Substance/3rdParty/rusted_painted_metal.sbsar
 21.3 mb 1.4% Assets/Materials/Substance/3rdParty/paint_satin.sbsar
 21.3 mb 1.4% Assets/Materials/Substance/3rdParty/paint_glossy.sbsar
 21.3 mb 1.4% Assets/Materials/Substance/3rdParty/concrete_scratch.sbsar

In my project I have a few Substances that I've set to Cutout or Transparent. I just cloned by repo to a new directory to test some stuff out, and I found that the Rendering Mode on the materials was reset back to Opaque for all Substances.

I'm setting the Rendering Mode directly on the generated material, since there doesn't seem to be an option to set it anywhere else.

With the new plugin in 2018.1, I don't see any way to rename a graph/material. With the sbsar selected, I can add additional graphs, but they're suffixed with "_1", etc, and I can't change the name. I don't see any other way to rename a material.



I've been continuing to work on this issue, to hopefully determine a specific cause, and it appears that this happens when the .NET Version (Edit -> Project Settings -> Player -> Other Settings -> Scripting Runtime Version) is set to 4.6 instead of 3.5.

I create a test project that contained only one SBSAR, installed the SubstanceUpdater asset, and found that it correctly generated the .transfer file. I repeated the process, this time changing the .NET version to 4.6 (which is the version I'm using in my real project) and found that the resulting .transfer file was empty. Switching back to .NET 3.5 results in correct generation of the files.

I don't see anything on the upgrade instructions that indicates the .NET version is a consideration, so maybe this isn't happening to everyone. But for me this appears to be the issue. Downgrading a project to 3.5 is a hassle, but it's possible a workaround for anyone else in this situation.

Any chance for an official response on this though?

The issue of empty .transfer files appears to be caused by `XML.Encode(asset, reflectionPath);`  The asset has data in it, but the Encode call is returning an empty string:

Short version: The process to upgrade my 2017.4 project to Unity 2018.1 is generating almost entirely empty ".transfer" files for my substances.

I'm trying to upgrade my project from Unity 2017.4 to Unity 2018.1, and I'm following the process described here:

I'm performing the steps within the Unity 2017.4 project, which I will be later opening in Unity 2018. After the upgrade completes, I see that it has created one ".transfer" file for each of my SBSAR files. However, of the 50+ SBSAR files I have, all but one of those ".transfer" files is completely empty. The files have no content. There is a single ".transfer" file that has some content, but the XML in the file is incomplete. The file is 86 lines long, and it ends in the following:


Note that the closing <Texture> tag is cut off in the file.

It's difficult to pin down whether any meaningful errors are occurring during this process, because my console log is full of thousands of cases of the following (which started after installing the Substance Updater package):

FileNotFoundException: Could not load file or assembly 'Substance.Game, Version=, Culture=neutral, PublicKeyToken=null' or one of its dependencies.
UnityEditor.EditorApplication.Internal_CallUpdateFunctions () (at C:/buildslave/unity/build/Editor/Mono/EditorApplication.cs:127)

However, I do see these two errors as well:

Assertion failed: Assertion failed on expression: 'exception != SCRIPTING_NULL'
Couldn't extract exception string from exception (another exception of class 'ArgumentException' was thrown while processing the stack trace)

Those are appearing often.

So, is there some known reason why the ".transfer" files would be empty? Or why one of them wasn't empty, but was incomplete?

Possibly related, the moment I confirm that I want to do the update, I immediately see the dialog that states "All substances have been updated successfully." However, at that point nothing is done, and Unity will churn for a minute or two before the files are generated.

If I use polygon fill, and I drag a lasoo/box selection with it, it selects faces behind the visible faces. For example, if I try to select a few faces on one side of a cylinder, it will select any faces on the other side that are behind the faces I'm selecting. This makes the lasoo selection hard to use. Is there a mode where the selection will only include visible faces, and not everything in behind the selection?



Thanks, Gary. Ultimately the issue appears to be that I should have been using the "Standard" shader, not the "Standard (Roughness Setup)" shader. The difference seems to be pretty significant. As you said, SP's default export preset creates a MetallicSmoothness texture, which places the Glossiness's grayscale value into the texture's Alpha channel. When using the Standard shader, it gives the option to base Smoothness on the Alpha channel of the Metallic texture. Upon switching to the Standard shader, things look good now.

However, I'm still confused about why Unity has a Smoothness slider even when using the Metallic Alpha for Smoothness. It seems that putting this to "1" results in correct settings, but I'm curious if there are other approaches.

I still don't understand why I can't get "Standard (Roughess Setup)" to work. In that case, I create a dedicated Roughness texture, and use either Roughness or Glossiness grayscale for its value. It never looks right in Unity. It's either inverted (when using Roughness) or it's blown out (when using Smoothness). Anyway, I'll just use the Standard shader, but it would be useful to know what to export for a dedicated Roughness texture, if I want to use Roughness setup.

Please look into your forum software. I just typed up a detailed reply to a post, which took a while as I was jumping back to SP to verify results. By the time I hit Submit, I had apparently timed out, redirecting me to the login screen again, and clearing my reply. It's like the ancient days of the web where you feel you need to ctrl-C before hitting submit in case the software does something that wipes your response. Please look into this.

I was hoping someone might be able to post a screenshot of what they're using for export settings to Unity PBR Metallic workflow. I've played around with this for a while, and the results in Unity just don't look right. Specifically, it feels like the roughness in inverted (what's shiny in SP is dull in Unity, and vice versa). I've included a screenshot of my export settings, and I was hoping someone might be able to post a screenshot of their export settings so I know what's wrong with mine.

I'm using Unity's standard metallic shader.

(Note: If I use Roughness for Roughness, my model is basically entirely black in Unity, which is why I'm using Glossiness, which looks more correct.)



I started using Substance Painter this week, and I have a couple of usability questions.

I'm finding it difficult to be precise. I was painting a model with a large circular surface. I wanted to paint some concentric circles onto this surface. However, there doesn't appear to be any coordinates or snapping when using a brush, which means I can't be sure I'm starting from the spot each time.

Next I tried using stencils as a way to simplify this. However, there's also no locking or snjapping with stencils (I need to position the stencil perfectly manually), and more frustrating, if I move the stencil or the model, or zoom, or pan, I have to go back and manually do it over again. This positioning also gets reset if I close and reopen the project. Is there any locking or snapping I'm not aware of?



Pages: 1 ... 4 5 [6]