How to setup a RubiksCube ...

[cormaction]

I was thinking along the same lines...

But instead of test inside geometry, I thought of using a null on each side of the cube acting as a controller, which then tests to see which particles are closest to this null, and then only these particles are effected when the controller rotates. That way you dont have to keep track of anything and it's dynamic.

The second part would be adding some logic to limit it to only one controller at a time, until the controller completes a 90 degree rotation, maybe a state node there.

Just some thoughts.

-TS-

I tried something similar using a test distance to surface scenario but still no dice. It's an evaluation order thing for me ("test inside/distance to" nodes only evaluate in my current set up at particles birth, would like find a way to make them evaulate say, every 90 degree turn of a face) and I'm not quite sure how to overcome it at the moment. "State" and "if" nodes haven't worked out for me so far. So if any of the ice experts out there would be willing to possibly shed some light on the problem I'd really appreciate it! Am curious to see your own results though, have you managed to overcome the problem with any of your own methods? Will look forward to a video.
I'll be away for a week so if anyone replies and I don't gush with gratitude right away I'll make sure to next week!

[TwinSnakes007]

Nope, as soon as I moved two controllers I ran into the same problem.

I even put the point cloud creation under the modelling stack [only processed once], and then put all the driver-driven stuff in the animation stack. Still same results.

It's probably something stupid I'm missing. Still fun stuff, learning alot solving this one.

-TS-

[TwinSnakes007]

Gave it another go, and I've had some success with multiple rotations. I think the problem was that 3D Grid node we where using. I think it's recreating itself each time, at least that what it looks like.

Anyway, I used the PointCloud-Cube instead and it's working with successive rotations on the point cloud. I tested a 90 degree Y Axis rotation followed by a 90 degree X axis rotation and it worked.

This should let us keep going..



As you can see the Red particles has been rotation on the Y Axis, and then you can see the Green particles have been rotation on the X Axis, correctly taking the appropriate Red particles as well.

-TS-

[TwinSnakes007]

Any ideas on how to color the sides of each square?

I guess we'd need to create some real geometry and then instance that to act as the faces of the rubik cube.

-TS-

edit: I created a cube, inset the faces, then created a cluster for each face and named the respective cluster so that the color can be set in the ICE tree. Until someone recommends a better way, that's what I'm going with.

[Hirazi Blue]

Could be that I misunderstand you, but if you go for the instance shape method there is no need for the ICE Tree to set any color. If your original cube has all six colors and the instances inherit these color, all should be well, as the sides/colors shown of each single cube in the larger Rubik always stay the same, so turning each single cube into a new position shouldn't necessitate any ad-hoc additional coloring...
;)

[cormaction]

Ok, back from some holidays! I took a look at your method there TwinSnake... nice idea! I'm still getting issues though. If you rotate say the particles on the Y axis 180 degrees, then rotate the particles on the X axis 180 degrees then try rotate the ones on the Y axis again they pop all over the place mid-rotation until they're back to a multiple of 90 degrees again. You having this issue? Seems like the same evaluation issue as before?

[TwinSnakes007]

Yeah, it's still not a viable solution. It falls down because the evaluation order is not easily represented in this setup.

Each controller (driver) needs to be able to do 90 degree turns. But, the controller is only holding rotation values for an axis, not "turns" per-se, in Rubik Cube terminology. So, in my mind, this requires us to build an array of "turns" in the same way that SI builds an operator stack. In this way, the array is holding the accumulation of "turns" and not the controller (driver).

Any ideas on how to realize something like that?

-TS-

[Chris_TC]

So, in my mind, this requires us to build an array of "turns" in the same way that SI builds an operator stack. In this way, the array is holding the accumulation of "turns" and not the controller (driver).

Any ideas on how to realize something like that?

I don't think this is possible because you can't append values in a non-simulated ICE tree. SRT information has no history stack either. When you rotate a control null, the new rotation overwrites the old one, and the old value is lost.

[TwinSnakes007]

Chris, I was hoping you where following this thread.

Is this even possible in ICE?

[Chris_TC]

Is this even possible in ICE?

It should be I suppose, but I'm not that experienced with rigging.
When the thread was originally made, I had tried a particle setup that's similar to what you have tried. I put circles around the cube and tried to use the particle positions to figure out whether they should be affected by the circle's rotation. I think everything worked whenever I hit 90 degree increments, but the in-betweens were broken.

[swann]

Any ideas on how to color the sides of each square?

I supose you should use MaterialID and other nodes in ICE to proceduraly shade faces. But i don't get how to use them.

[TwinSnakes007]

So, in my mind, this requires us to build an array of "turns" in the same way that SI builds an operator stack. In this way, the array is holding the accumulation of "turns" and not the controller (driver).

Any ideas on how to realize something like that?

Dont even ask me why this was still in my brain somewhere, but an "idea" just hit me how to solve this.

I'm gonna mock something up tonight and see if it will work.

[Pancho]

Hi TwinSnakes,

Did you proceed with your research or did you stop working on this project?

Cheers
Thomas