Author Topic: Strange Patterns in Random FX Map  (Read 558 times)

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?

Can you attach your sbs ?
Product Manager - Allegorithmic

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!
Last Edit: April 11, 2019, 04:31:57 pm

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!
Last Edit: April 11, 2019, 05:42:16 pm

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?
Last Edit: April 11, 2019, 08:18:55 pm

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.


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.
Esger van der Post.
Texturing addict.

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.
Last Edit: April 12, 2019, 02:51:21 pm

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.
Last Edit: April 12, 2019, 03:18:49 pm

I just noticed the set value not being plugged into a sequence input, so that's all I changed in the example, while ignoring the rest of the function. It admittedly made for a bad example, but luckily you figured out the rest.
Also, I though you needed a sequence node for each set value, but apparently that's not the case.

As for why it worked in the luminescence function, I'm surprised by that as well. I'm thinking perhaps you can acces set values within the same node without adding them to a sequence, while separate nodes require a sequence.
Esger van der Post.
Texturing addict.

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.

Ah, that explains a lot. I partially misunderstood what the sequence node is intended for. I've just been using it to tie separate functions together that I placed in a single graph for the sake of convenience (ie placing all functions of a quadrant inside the luminosity graph), and did know it required this counterintuïtive order.
So it's done the job despite not fully understanding the explicit function of the node. Thank you for explaining the concept to me.

Esger van der Post.
Texturing addict.

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