3
$\begingroup$

I started by creating a simple Rubik's Cube and randomizing the colors for each face of the cube by using a geometry node for the single cube. I then added a second object, a plane mesh and made a geometry to grid the cube faster than using an array. As you can see, the same random colors are only applied to the single cube, and the geometry making the grid just duplicates the cube. that I understand why it's not making it random colors for each cube in the grid.

The question I have would be is there a way I can make the colors randomly change on the geometry node that makes the grid, so there is not a recognizable color pattern among the cubes.

Since the Attribute Fill and Attribute Randomizer nodes are no longer in Blender, how can I make that for myself to randomly pick through my materials in the geometry node. Maybe that will work for my random color issue inside the geometry node for the grid. YouTube video link (https://youtu.be/_4HVknkh4es?t=120)

I forgot to mention I have 2 materials. One is the black color material and the other is the color for all the faces of the cube that has random colors. So if it's possible to make only the colors randomly change and not the black material.

Here is the material I have assigned to the faces. enter image description here


This is the geometry node I put on the single cube to more easily random the colors around on the cube. enter image description here


This is the grid geometry node I made to array the cube on the second object (plain mesh object). Geometry node on the plane to make the grid

$\endgroup$
5
  • $\begingroup$ Unfortunately this generates colors with no regard to the actual construction of a rubik's cube :p. You have two orange stickers on the rightmost corner $\endgroup$ Apr 20, 2023 at 16:24
  • $\begingroup$ @AllenSimpson ya I see that. not only that but on the other side there are two opposite colors on the same edge and as you can see red and orange are not opposite to one another like a standard cube. so that is an issue, not a big issue for what I have planned with this model, but I have a plan to fix that after this one problem is fixed first. I changed my tactic from this question (blender.stackexchange.com/questions/290916/…) because I feel going this route will be better in the end than what i was trying to accomplish in my other question. $\endgroup$ Apr 20, 2023 at 17:10
  • $\begingroup$ I would actually try to create a Rubik's cube from 26 small-cube instances, and then apply rotations on the instances around the center of the cube. It would be chaining a lot of random rotations, but rotating instances is very fast. This would ensure all colors are valid. For that you absolutely cannot wrap the small-cube instances in Rubik instances, because realizing will realize the entire tree of instances. $\endgroup$ Apr 25, 2023 at 17:41
  • $\begingroup$ Got it, need to write explanation post and will post as a separate Q&A i.imgur.com/U6cFPvK.jpeg $\endgroup$ Apr 27, 2023 at 10:51
  • $\begingroup$ And here it is: Realistically randomize Rubik's Cube $\endgroup$ Apr 27, 2023 at 17:37

3 Answers 3

3
+100
$\begingroup$

user166113's answer is fine, but here's how I would do it, if I didn't care about the problems mentioned in the commends under the question; I think I'll actually start a new thread on how to randomize a Rubik's cube in Blender, but meanwhile…

If you look at the default UV map of the default cube [left], and create a new color grid [right], you can see four tiles fit into each face, two on each dimension:

While you want three on each dimension ($3×3=9$), so you can create a new color grid, but with default dimensions divided by 2 (now only one tile fits), and then multiplied by 3:

$$ {1024\over2} × 3 = 1536$$

Now 3 tiles fit on each row, but they are cut in half (horizontally) due to how the default UV map is positioned. Either move the UV map by ${1\over12} × {1\over2} = {1\over24} = 0.041667$ to the left or right, or use this offset in the shader:

I marked H7 to be clear what I consider a tile.

The texture was never really needed, just served as a visualization of snapping increments for a noise texture:

UV

For something more complex it's really the same, the extra step being that you e.g. scale the UV to 0 and move it to <1, 1> subdivide the cube, inset individual faces, UV unwrap, count how many square you get per row/column (here 8):

Remember to change the reciprocal in the SNAP from 1⁄₁₂ to ⅛:

Those aren't the colors you want, but you could do something like this to use the color ramp:

$\endgroup$
4
$\begingroup$

For demonstration purposes I am going to use a subdivided cube as your Rubik's cube. I have created a simple Rubik's cube, and added a simple shader to it which uses an attribute from geometry nodes.the shader

here is the geometry nodes: geo nodes If I apply an array modifier or something similar after the geonodes has done it's work, It doesn't know that there are multiple cubes, so it just treats them all as the same cube, and therefore the shader shades them the same. but if you add the array modifier above the geometry nodes in the shader stack it recognizes that the separate cubes have different meshes.

the modifier stack

and now it yields it's expected outcome without having to change the grid-making node.

the output

$\endgroup$
1
  • $\begingroup$ now, using the array, I'm having an issue with an image bump I have on the center caps to each cube. because it's arraying a single cube, the image on each cube in the array is facing the same way. when I was using a geometry grid node I was able to apply a random 90degree rotation to each cube in the grid that didn't have a pattern to the image on the cube center, for example if the image was an arrow then all the arrows will be facing the same direction. is there a way I can randomize the image rotation within the array method you are using? $\endgroup$ Apr 27, 2023 at 12:41
1
$\begingroup$

you could store a random value on the instances domain as well as one on the face domain (which you kind did already ,ish) and combined them in the shader. Use two attribute nodes and set the one you are using to bring in the instances attribute to instancer.

If you are using cycles (because integers don't really work in eevee so well as of now), then you could just capture the index on both domains (kinda like I said above) and combined them with a combine xyz node in the shader, which you could use as the vector for a white noise.

$\endgroup$
4
  • $\begingroup$ I'm sorry, but I'm a visual learner and didn't understand any of what you just said. Could you explain it again, but with screenshots? Sorry to ask that but I have a learning disorder and everything you wrote might as well be in a foreign language because I've read it many times and just doesn't make sense to me. $\endgroup$ Apr 23, 2023 at 2:48
  • $\begingroup$ Integers are fine in Eevee, just tested on 3.4.1. i.imgur.com/hxusUYN.png i.imgur.com/Gq24HOW.png $\endgroup$ Apr 25, 2023 at 17:29
  • $\begingroup$ @MarkusvonBroady my bad. it seems that the issue is with the white noise node, and it's still a problem in both eevee and cycles. $\endgroup$
    – shmuel
    Apr 25, 2023 at 23:45
  • $\begingroup$ hmm i also see it in the regular noise texture. $\endgroup$
    – shmuel
    Apr 26, 2023 at 0:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .