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.

Topics - CodeRunner

Pages: 1 [2] 3 4 ... 6
What would be the best option for initializing variables in a pixel processor node? I'm trying to setup some variables that will be used inside the pixel processor before the processing actually begins.

I tried using the "output size" function to generate variables, but for some reason, Designer doesn't always execute that function when the graph loads up. So the processor ends up being executed without the variables being initialized. I have to tweak some of the exposed variable values to get them to initialize.

Does anyone know why this happens, or if there is a safer way to initialize them outside of pixel processing?

Substance DesignerSubstance Designer - Feature Requests - Ghost Manager
 on: May 07, 2019, 11:59:11 pm 
We need a ghost-node manager that works like the dependency manager. Each ghost node should be listed where we can swap it out with a valid existing node that has same-name (or same-type) connectors.

There is an issue that causes function nodes in unloaded graphs to turn ghost when we rename their identifiers, which can cause a lot of distress. This would seriously help with that.

EDIT: Most importantly, make sure to leave some kind of identifier on the ghost node that lets us know what it was. Even if everything else is ignored, this feature should be included for sure, if its possible.

Do unplugged parameters always default to zero? Is it considered safe practice and normal workflow to leave function node parameters unplugged to specify zero, or should it be avoided?


Does anyone know what the internal maximum random seed is for Designer? It's not really 10 is it? This seems like it would severely limit the number of random possibilities. Values above 10 seem to function, but are they defective in some way? I haven't been able to find anything about this in the manuals yet.

Anyway, after exposing the parameter and trying to generate random values, it appears as though very high seeds are identical to each other (or I may just be doing something else wrong).

If anyone can help, I would really appreciate it.

Substance DesignerSubstance Designer - Discussions - Random Integer
 on: May 04, 2019, 03:51:59 pm 
I'm trying to write a simple function node that generates a random integer within a range of values supplied to the function. This was my first attempt:

But this had terrible results. While generating a random number between 0-5, I got the exact same result with random seeds 0, 1, 2, and 3 (maybe 4 too). So then I got a little frustrated and tried this:

Which appears to work much better. Different results for every random seed. Can anyone help me understand why? Am I making an obvious mistake in the first one that I'm not seeing? Or is there some internal operation concept that I don't get?

Thanks for any advice!

Does anyone know if resizing images is a safe way to perform a high-pass operation? Essentially, I'm extracting the small details from larger details by blurring the image and subtracting that blurred image from the original (high-pass). But I've found that simply resizing the image to a smaller scale, then back up to normal is much more efficient than blurring.

Does anyone know if this is a safe method to use? I've noticed that the pixel processor bi-linear sampling is apparently different than the filtering used by Designer when it resizes. I'm just wondering if the resized images are going to differ drastically across different machines. I'm only intending to use my graphs for texturing model assets offline, but would still rather make something stable.

Thanks for any help!

Hey guys, I am (again) having some issues with patterns showing up in the randomness of my FX Map. I've trimmed the node down into something incredibly simple, where each dot has a random position 0-1 and a random luminosity 0-1, and this pattern shows up:

You can pretty easily see the pattern of luminosity running through the lines, where we have a bright-dark-bright-dark thing happening diagonally.

If anyone can shed some light on why this is happening, I would really appreciate it. From what I can tell, it seems to only happen when I call random from the FX switch node. If I use random in the quadrant node, it goes away.

I was once told by a member of the Allegorithmic staff that all paths of a float / switch (if/else branches) are executed during a single run of the Pixel Processor, even if only one of the conditions are met. Is this true?

I've noticed that the random node is a good way to test these situations. The outcome changes if random is called twice per pixel instead of once, or three times instead of two, because random always outputs the same results if called in the same order, but doing this changes that order.

When I create several conditional branches, where only one is true, random does not seem to be executed for those branches. This makes me think these branches are actually *not* being executed. Unless Designer is internally prepared for such situations and compensates for it by "ignoring" the random calls.

I would like to know how the optimization works? Does the entire conditional branch get skipped (in a way that would make the number of sample calls irrelevant), or are the function nodes designed to internally skip execution when their branch should be ignored (where they still cost something even when not used)?

Can anyone straighten this out for me? If this is true, it dramatically changes the way I can go about designing graphs.

Thanks for any help!

There is an issue that occurs when switching between two nodes that have many exposed parameters. When the user double clicks, the program has to switch both parameters and 2D display, but the large number of parameters takes a second to load, which prevents the double click from registering.

It's hard to guess, but I think this is happening because the double clicks are not being detected using time stamps. Or perhaps you need an input buffer, or to detect input on a separate thread apart from image processing.

A great feature to have would be an exposed int quadrant member that represents its "depth offset". When the user changes the value +1, the quadrant would behave as if 1 extra empty quadrant was inserted above it, attached to all 4 inputs.

I'm not sure how difficult this would be to program as a feature (maybe very easy), but it would be big in terms of functionality. One could expose the variable and name it scaling, and have instant noise scaling that is similar to the scaling used by the built-in FX noises. It would also make many FX maps simpler - we would only need to create quadrants that render things.

Substance DesignerSubstance Designer - Technical Support - Undo Bug
 on: April 12, 2019, 05:04:42 pm 
Here is a specific undo bug that can be reliably reproduced.  I attached a graph to perform the steps with. Open the pixel processor function and perform these two steps:

1. Attach the const float 1 node to the set(myScale) node
2. Press Ctrl + Z to undo

The graph should turn black and fail to cook. The only way I've found to "repair" it is to break the related connections and reconnect them. Even saving / closing / opening the graph back up won't fix it.

It would be very functional friendly if Designer handled inputs like variables when dealing with things like sampling. When we reference an input image in a graph function, it should reference it by name instead of number. And when we change the inputs around (rename), the samplers should change automatically like variables do.

It's too easy to be in a situation where you have to delete an input to a complex graph, which causes all of your sampler references above it to reference the wrong images. Very easy to miss one, or forget they are buried in functions. It would be nice to have the same system that variables have when one is deleted - which shows the developer where the references are.

To deal with backwards compatibility, you could just create a new type of sampler and mark the old ones as outdated.

Why does the FX Map's iterate node have its own random seed? How is it different than the node's random seed? Is there some way to create a new random seed per iteration?

I've created a shape splattering FX map that uses a single quadrant node with an iterator at the top, which iterates once for every shape drawn. This is the first FX Map I've tried to make that uses a single quadrant node. Each shape starts out on a grid layout (X*Y), which I calculated using the total and $number ($number / total and $number % total). Then each one is randomly offset. And this is where I'm running into trouble. For many node counts, I'm getting strange patterns in the result, as if the randomizer is repeating the same results every so many iterations. I'm almost certain the patterns are caused by the shape positions, because everything else is non-random. Here is an example of one, where you can clearly see line patterns going diagonally through the layout:

The image above was drawn with each shape randomly offset using a range between -0.5 to +0.5 on both X and Y axes. Here is the function used to randomize the shape offsets from their X/Y grid layout:

I've verified that the grid layout is correct without randomizing the positions. But as soon as I start adding random offsets, I keep getting these strange patterns. Does anyone know why, or how to resolve this? Is the FX-Map repeating the same random results in some way?

This may be a known issue, but here it is just in case. When you copy and paste an exposed drop down box control with more than a few options (5+), the pasted version will only show the first few options. The user has to click the '+' button to make the others become visible.

Likely because the internal "size" variable is not being updated during a paste operation.

Painter seems to clamp exposed parameters even when they are marked not to clamp in Designer. I'm assuming this is because the sbar file doesn't support the boolean that controls it. But why not allow users to manually type in a value anyway? Keep your widgets the same as they are now, but allow us to override the value range when we want by manually typing in our out-of-range values. If nothing else, give us an option to enable that warns us of possible dangers when doing this.

There are many filters that specify a min/max range only to make the slider more sensible and useful. These ranges are usually not meant to be a forced rule. For example, your built-in blur filter only goes up to 16, because if it specified 128 as the max, the slider would be almost useless (too touchy).

We need some way to override the value range when it makes sense.

Pages: 1 [2] 3 4 ... 6