Possibly a RND number generation or geometry generation bug #98134

New Issue

Marco · 2022-05-15T10:21:32+02:00

Marco commented

2022-05-15 10:21:32 +02:00

System Information
Operating system: Windows 10.
Graphics card: GTX 1070.

Blender Version
Broken: 3.1.2, cc66d1020c, master, 2022-03-31.
Worked: dunno.

First, a premise: I am quite a newbie with Blender Geometry Nodes, so this may also be because of my incompetence.
However, I spent a couple hours in search of the reason of why this is happening, and couldn't find any problem in my Nodes setup.

Nodes setup

I create a MAIN BOX, from which I boolean subtract several other BOOL BOXES in a randomize manner.
To do this, I create the main MAIN BOX in section 1 of the setup.
In section 2, I create a BOOL BOX, generally a bit larger, and to its vertices I apply a randomized offset.
In section 3, I instantiate BOOL BOXES of random size on each vertex of the BOOL BOX.
Finally, I apply the subtraction.

In the attached file, I added another node in the setup to hide/show the work meshes (BOOL BOX and BOOL BOXES). This is just for bug hunt.

Problem

Now, the problem: if you configure the setting so that you expect to have the same statistical result in holes on top and bottom, this will not happen.
I did NOT check if there are discrepancies also on Y and X axis.
When I begun to notice this problem, it was because the bottom holes were statistically deeper than the top ones.
Then I conducted a short statistical census, and noticed that the bottom holes are not only deeper, but they are also happening about 100% more often than on the top.
In example, if I counted about 25 holes on the top of the MAIN CUBE in 20 different seeds, the same seeds showed me about 45 holes in the bottom face of the MAIN CUBE.

Now, as the BOOL BOXES are sized about the center pivot, I wouldn't expect this behavior, when the BOOL BOX itself is centered on the MAIN BOX and its vertices are offset by the same statistical amount on all the axis.
What I expect is to have the same number of holes, statistically, on each side, no matter if it's top or bottom.

Steps to reproduce the error: simply use the attached .blend file and count the holes!

My explanation: this is possibly a glitch in how Blender randomizes numbers.
Or, if an external library is used, like in example Rust, the problem lies there.
Or, when I did thig bug hunting, I had a blatant and ridiculous oversight on my Nodes setup, lol!

BUG SEARCH.blend

**System Information** Operating system: Windows 10. Graphics card: GTX 1070. **Blender Version** Broken: 3.1.2, cc66d1020c3b, master, 2022-03-31. Worked: dunno. First, a premise: I am quite a newbie with Blender Geometry Nodes, so this may also be because of my incompetence. However, I spent a couple hours in search of the reason of why this is happening, and couldn't find any problem in my Nodes setup. **Nodes setup** I create a MAIN BOX, from which I boolean subtract several other BOOL BOXES in a randomize manner. To do this, I create the main MAIN BOX in section 1 of the setup. In section 2, I create a BOOL BOX, generally a bit larger, and to its vertices I apply a randomized offset. In section 3, I instantiate BOOL BOXES of random size on each vertex of the BOOL BOX. Finally, I apply the subtraction. In the attached file, I added another node in the setup to hide/show the work meshes (BOOL BOX and BOOL BOXES). This is just for bug hunt. **** **Problem** Now, the problem: if you configure the setting so that you expect to have the same statistical result in holes on top and bottom, this will not happen. I did NOT check if there are discrepancies also on Y and X axis. When I begun to notice this problem, it was because the bottom holes were statistically deeper than the top ones. Then I conducted a short statistical census, and noticed that the bottom holes are not only deeper, but they are also happening about 100% more often than on the top. In example, if I counted about 25 holes on the top of the MAIN CUBE in 20 different seeds, the same seeds showed me about 45 holes in the bottom face of the MAIN CUBE. Now, as the BOOL BOXES are sized about the center pivot, I wouldn't expect this behavior, when the BOOL BOX itself is centered on the MAIN BOX and its vertices are offset by the same statistical amount on all the axis. What I expect is to have the same number of holes, statistically, on each side, no matter if it's top or bottom. **** **Steps to reproduce the error:** simply use the attached .blend file and count the holes! My explanation: this is possibly a glitch in how Blender randomizes numbers. Or, if an external library is used, like in example Rust, the problem lies there. Or, when I did thig bug hunting, I had a blatant and ridiculous oversight on my Nodes setup, lol! [BUG SEARCH.blend](https://archive.blender.org/developer/F13075283/BUG_SEARCH.blend)

Marco commented

2022-05-15 10:21:32 +02:00

Added subscriber: @megmaltese

Philipp Oeser commented

2022-05-18 16:42:07 +02:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2022-05-18 16:42:07 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

Philipp Oeser commented

2022-05-18 16:42:07 +02:00

Cant spot the fault in the geo nodetree either. Weird.

Maybe this rings a bell with the #geometry_nodes team?
Will confirm for now.

Cant spot the fault in the geo nodetree either. Weird. Maybe this rings a bell with the #geometry_nodes team? Will confirm for now.

Jacques Lucke commented

2022-05-24 13:06:45 +02:00

Added subscriber: @JacquesLucke

Jacques Lucke commented

2022-05-24 13:06:45 +02:00

Simplified the file a little bit while looking into it.
random_correlation_simplified.blend

I think I found the issue.

You have two Random Value nodes (one for translation and one for scale of the smaller cubes). Both use the same ID and Seed as input.
Since they have the same id/seed input, they produce the same random values (up to a scale factor based on the Min/Max input).
Consequently, the larger the z value of the translation, the larger the z value of the scale of that cube.
Since the Spread cube is larger than the Main cube, the instance cubes have to move up on the bottom side and down on the top side to intersect the main cube.
Now, all the instance cubes that moved up on the bottom side, are more likely to have a larger z scale than the instance cubes that moved down on the top side.
Therefore, they are more likely to intersect with the Main cube, hence you get statistically more intersections at the bottom.

A fix is to modify the seed that is passed into one of the Random Value nodes.

Simplified the file a little bit while looking into it. [random_correlation_simplified.blend](https://archive.blender.org/developer/F13102743/random_correlation_simplified.blend) I think I found the issue. * You have two Random Value nodes (one for translation and one for scale of the smaller cubes). Both use the same ID and Seed as input. * Since they have the same id/seed input, they produce the same random values (up to a scale factor based on the Min/Max input). * Consequently, the larger the z value of the translation, the larger the z value of the scale of that cube. * Since the Spread cube is larger than the Main cube, the instance cubes have to move up on the bottom side and down on the top side to intersect the main cube. * Now, all the instance cubes that moved up on the bottom side, are more likely to have a larger z scale than the instance cubes that moved down on the top side. * Therefore, they are more likely to intersect with the Main cube, hence you get statistically more intersections at the bottom. A fix is to modify the seed that is passed into one of the Random Value nodes.

Jacques Lucke commented

2022-05-24 13:11:01 +02:00

Changed status from 'Confirmed' to: 'Archived'

Jacques Lucke closed this issue

2022-05-24 13:11:01 +02:00

Marco commented

2022-05-24 18:18:44 +02:00

Aha! That was subtle! (for me at least)
In fact, I think I noticed the same problem on the X and Y: on the - side, more holes than on the + side.
Anyway, thank you!

Aha! That was subtle! (for me at least) In fact, I think I noticed the same problem on the X and Y: on the - side, more holes than on the + side. Anyway, thank you!

Marco commented

2022-05-24 20:14:42 +02:00

Expanding on this, shouldn't the RND generation work differently, so to avoid this kind of situation?
After all, one could easily WANT to have ONE seed for all of the output.

How I understand this, is that the RND is generated between 0 and 1.
Then this number is normalized between the MIN and MAX values of the RND parameter.
So, the size of the box goes from 0 to Z, it's always positive.
But the position randomization is from negative to positive, so from -Z to +Z.

This means that the larger the RND is, the most larger the box is, but also the more shifted up (+) the RND position is.
A way to solve this could be (and in my opinion, SHOULD be), not spreading the RND between - and + straight away, but doubling it before doing so.
This would push down the negative value, putting everything back into place.
But I guess this is not done for the sake of speed, right?
So I'll have to deal with this myself, I guess.

Expanding on this, shouldn't the RND generation work differently, so to avoid this kind of situation? After all, one could easily WANT to have ONE seed for all of the output. How I understand this, is that the RND is generated between 0 and 1. Then this number is normalized between the MIN and MAX values of the RND parameter. So, the size of the box goes from 0 to Z, it's always positive. But the position randomization is from negative to positive, so from -Z to +Z. This means that the larger the RND is, the most larger the box is, but also the more shifted up (+) the RND position is. A way to solve this could be (and in my opinion, SHOULD be), not spreading the RND between - and + straight away, but doubling it before doing so. This would push down the negative value, putting everything back into place. But I guess this is not done for the sake of speed, right? So I'll have to deal with this myself, I guess.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Possibly a RND number generation or geometry generation bug #98134