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

Pages: [1] 2
if your ambient occlusion is black, this will also happen.  To test this, create a uniform color. make it white. Right-click-drag it onto the 3D viewport and pick AO.  If the issue goes way, then you know it was the AO all along.

Attached is the node I created for myself to make life easy.

1. You could use a tile generator to make the tile pattern.  Use the random options under color to get various shades of gray.
2.  blend pattern one and two, using a blend node.  Plug the tile pattern into the mask of the blend node.
3.  insert a node between the tile pattern and the mask to isolate part of the greyscale pattern.  I'd use a node like "historgram select".

4.  The main issue here is -> Patterns with gradients are problematic for generating a mask, so for the tile generator pick square instead of brick, then scale the pattern (under the size options) to create the grout area.

Yes, you can do this.
1. Make sure the parent graph has the parameter you want to share. To the right of the parameter you want to share is a dropdown list.  Pick "expose as new graph input". In your example, it looks like you might have already done this.

2.  For each additional node in your graph that you want to read the same rotation param, using the same param dropdown list (where you chose "expose as new graph input")  If you look further down, you should see the list of graph params that already exist.  Simply select the previously defined "rotation" param.

It doesn't look like pixel processors could do what I want anyway, since the pixels are evaluated in parallel.  As far as passing variables through the graph, the solution is to use the value processor in combination of input value nodes and the optional value data blocks you can tack onto existing nodes.

I'm starting to get the impression that while subgraphs can gain access to parent graph params, there's really no way to modify the input params.  I.e. in coding terms, it feels like inputs are treated like pass by value and not reference.  Access to higher level scope vars are good for reading, but not writing.

Sound right?

Substance DesignerSubstance Designer - Discussions - Re: A better mask
 on: June 17, 2021, 11:08:45 am 
Would something like this work?  Use a pixel processor to compare the post-blend with the pre-blend.  If the pixels match, white pixel .  If not, black pixel.  Also, make sure the black pixels always output black.

More questions:
1.  The doc states "When you create an input parameter, a variable is created and associated with it. You can then reuse this variable in any function of you graph"

I'm get the impression those can only be read by the graph and that I can't set input parameters using a set node.  Is that correct?

2.  What's the life of a variable?  Or how do I reset a variable at the beginning of a process?

For example, I would like to have a variable called "startProcessing".  When True, I do the processing.  However, I need to reset it at some point.  If I was coding I'd do something like:

def ProcessGraph():
    startProcessing= False

    #pixel process
    for pixel in image:
        if sample(pos) == targetColor:
            startProcessing= True

        if startProcessing:

In the above example I'm resetting startProcessing before sampling the image.  Not sure how to do this in designer.

Substance DesignerSubstance Designer - Discussions - Scope of variables
 on: June 16, 2021, 07:57:30 pm 
I'm interested in using a pixel processor to calculate the bounding box of a shape.  Then as a second step I want to use that info to position and scale a pattern.  However, I'm not sure how to properly set variables in a pixel processor so it's accessible elsewhere in the graph.

Do the vars need to be param of the graph to stay in scope? 

That did the trick.  Thanks so much!

I've baked a normal map in SP, exported, then re-imported it into a new project.  When assigning the map to the additional maps normal map slot everything looks correct.  However if I remove the map, set the normal mixing to replace and then assign it to a fill layer's normal map channel the normal map doesn't look correct.    I'm using 2017.4.2  Is this a bug or am I just being a idiot :)

SubstanceSubstance - Purchases & Licenses - Download Old Build
 on: October 02, 2017, 04:54:19 pm 
How can I download an older build of Substance Painter?  I need version 2.6.1  I see under the license menu an "All builds" option, but it only seems to contain 2017.x versions.  Thanks.

Well, I can't say that I'm looking for this behavior all the time.  In this case I was using the brick generator and figured if I was going to give the bricks some various greyscale values for the height channel I might as well pump that into the roughness. This seems easier than adding a second brick generator and then having to make sure a majority of the params align between both instances.  Normally (instead) I'd create a base fill layer and then add the brick generator to the mask.  The end result seems the same.

Does it make sense for height values to correspond to roughness, no, but it works as a base to provide some cheap randomness   ;D

I think this mystery channel mapping rollout has been around for a long time and I've been losing my mind with the inconsistent behavior.  As I'm messing with my layers suddenly the options seem different or I make a mental note like, "the brick generator has that channel mapping rollout" only later to discover it doesn't.

This reminds me of the various particle options not always refreshing properly when changing the emitters or receivers in version 1.x.  It's probably fixed in version 2.x, but I gave up on using them because you never knew if all the params would be available.

Here's the requested screen shot.

Pages: [1] 2