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

Pages: [1] 2 3 ... 10
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.

That's great, I appreciate your help as well. We will figure these confusing things out eventually.

The set node doesn't require a sequence node to follow it, but there are times when not using one can lead to problems like the one I just had. I believe the set node just sets the variable and returns its value as the result.

The sequence node just allows you to do "extra stuff" in a situation that is intended to perform some other specific task. The inputs of the sequence node are like execution streams. "In" is executed first, but the value plugged into it is completely ignored after it executes. Then "Final" is executed next, and the value plugged into that is returned as the result. So if you have 3-4 sequence nodes, you can think of them as execution steps, like a list of things that need done in a specific order.

It confuses me all the time when trying to plug up a bunch of sequence nodes. It helps me to remember that it works backwards. Like a line of people trading stuff. Each person asks the person behind them to give them what they want, so they can trade it to the person in front of them for whatever they want. The requesting starts at the end, but the trading begins at the beginning.

When you plug a set node into a sequence node, you're telling the program to set the variable before whatever comes next. But plugging the set node into the sequence node doesn't actually do anything, other than make sure the set node is executed first. For example, you could plug your set node into a divide node that divides your set value by a million, then plug that into the sequence node and it won't make any difference at all. The divide node will have no effect, even though it will execute correctly.

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.

I think it has to do with how you use the sequence node.
Admittedly I'm not entirely clear on how sequences work myself, but when you set a new variable, you should connect it directly to a new sequence input for it to be recognized by functions lower down the pipeline.

If I'm not mistaken, the way you've set it up here would force it to generate two random positions per shape. When the masking image requests its pixel, it would generate a new (incorrect) position, which wouldn't match the position stored in "shapePos". But there was no way you could know this because the masking was turned off. So you fixed it, regardless. However, by moving the sequence node back one step:

It still works correctly, which confuses me greatly, because I know I tried this before and it didn't work. Maybe I had one of the "inherit randomness" switches off on one of the nodes. Or maybe I plugged something into the wrong input. Anyway, I appreciate you taking the time to look at it and fix it.

Another thing that confuses me is why it worked perfectly when I moved it to the luminosity function. Maybe some type of internal optimization was happening, causing it to skip part of the random position generation.

Yes, I was switching that specific situation back and forth because I was wondering the same thing. But it worked exactly the same both ways, so I assumed it wasn't part of the problem. Did you actually get the randomness to work without taking the code out of the switch node? If so, I'd be interested to know what all you changed.

The sequence node is strange, but actually really simple. It literally completely ignores the first input and "returns" the second. So if you imagine it to be a function node, it would literally pass through the second input as the return value. I'm not sure what it's doing to the first input to ensure it "executes", but that's all it needs to do.

So as long as the set node is executed *before* you use the associated variables, they should work fine, even with no sequence nodes at all. This is coming from my limited experience (few months), so someone please correct me if I'm wrong.

Once I moved all of that code to the luminosity function of the quadrant node, it worked perfect. So I think it has something to do with execution of random functions inside of switch nodes, or something to do with generating random values in one node to use in another. Something along those lines was causing the strange pattern, I think.

I know I'm talking to myself here, but wanted to mention that everything works great when I move all functionality to the quadrant node and get rid of the switch node. There is obviously something strange about generating random numbers in the switch nodes. If someone could help me understand what it is, I would appreciate it.


Ok, it is not the scaling. The scaling pixelation thing is an issue, but it is not causing this pattern thing. This time, I'm bypassing my grid and starting all shapes at the center, then randomly offsetting them (random from -0.5 to +0.5 on each axis), and this is the result I get:

I really hope someone can help me understand what is happening here, because I feel like I may be having a nightmare. But I've tried pinching myself and I'm still here. Is my randomizer broken? Is there something about the FX iterator vs randomness that I don't know about? That is my best guess at the moment, but I can't find any information about it.

I've attached another version of this graph. This time, it's pretty simple. All shapes start in the center and offset "randomly" on both axes by -0.5 to +0.5. But that's not what it looks like. Instead of being crazy and random, it looks like they are all in cohorts together, trying to undermine me.

I need a break.

EDIT: Okay, when I move the randomization offset from the switch to the quadrant node, it fixes the randomness. Can anyone help me understand why? The switch is being executed every iteration, right? Why does this matter?

Here is the graph. I setup the defaults to show you what is happening with small scaling. Try doubling the scaling and watch how it changes. Really weird pixel alignment stuff, I think. I am trying to confirm this is what was causing the patterns in the random noises, but having trouble recreating the patterns now.

The shape positions are being computed inside of the switch node. Some of the variables are also computed in the global opacity value of the FX Map.

Any idea how I can make this better? I've tried aligning the shapes to pixels, to their centers, to their edges, but it doesn't seem to make any difference. I think I need some type of filtering applied so that very tiny shapes show as an approximation of their entire shape's color, and not as one or two pixels from it.

I can probably avoid the whole thing by forcing the shapes to remain above a certain scale, but wanted to make sure there isn't a better solution first. Thanks for your time!

I think the problem is being caused by small scaling. I'm getting very strange results when I scale too small, even with no randomness at all. Some shapes are not drawn at all, and those that are some how bond together to create a larger representation of their specific shape, which is one of the strangest things I've ever seen. For example, a huge section of tiny discs will create a larger disc shape, where each "pixel disc" is a single pixel in the larger disc. Really weird stuff.

If I were to guess, I would say each shape is drawing a single pixel from its image, and the pixel chosen changes for each one. The whole thing lines up to create a larger stretched out version of the shape. Mathematical..

I don't understand why its happening now. I've never had this issue when I stack quadrants, even with tiny scaling. It must have something to do with my grid layout. Maybe some type of floating point error or something else I'm not seeing.

I will upload the graph when I get to my PC. Thanks!

Yeah, it's just an interface thing. I don't copy and paste a lot of drop downs, so it hasn't been much of an issue. But I'm happy to help.

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?

Pages: [1] 2 3 ... 10