How to setup a RubiksCube ...

[lmc]

Hi there,

I am currently doing some research regarding rubiks cube's rig and i would like to ask is there any easy and quick solution that without very complex scripting setup.

There is some solution and resources which i found on the forum unfortunately there is some minor error when you animate it.

(A.) a very basic solution and setup: build the rubic's cubes..center the rubic to global 0,0,0.. select all and move all centers to 0,0,0
keep the orto views open for easy rows selection and keep rotating and keyframing. [madD,xsibase]

This matter will happened with the gimbal lock problem after few rotate.


(B.) Rubiks cube : centralized computations, by Cyril GIBAUD - http://http://www.studionham.com/index.php?opt ... &Itemid=56

Overall are cool but its comes wrong result while you have negative value of rotation.


And there is some old thread that mention about Helge Mathee's setup but i can't find now due to the links were broken. Some cool ice compound setup was found at vimeo but there is no tutorial for it.

For MAX, There is some TCP setting which allow you to just rotate you cube without any issue.


Any tips or solution will be much appreciated, thanks


Best Regards,
LMC

Newcomer alert: please use the URL tags - HB

[Hirazi Blue]

Can't help you there, I'm afraid...
But this sounds like a nice additional challenge for our new ICE project forum.

[TwinSnakes007]

I dunno if a ICE based solution is possible because you'd need to create some kind of dynamic parenting where children would switch parents based on selection or some other event.

[Hirazi Blue]

That's an interesting question. I have read at least one claim of someone ("our very own" Leo) solving it in ICE (German: here), but sadly not providing his solution as it was meant as a start for a (apparently failed) workshop over at the German Softimage community...
;)

[TwinSnakes007]

Hmm..those are some nice ideas in the German thread.

Get's me to thinking there may be a simple, centralized solution to this.

[cormaction]

I've had a quick stab at this and I was working on a method involving the "test inside geometry" node. Seems like one of the guys on the german site has done something similar, only realised after I had started into my own version! I have it working up to a point and this is where someone who knows a hell of a lot more about logic and programming than me might be able to help?

Basically, my setup is particle based for the moment so I'm using a volume of particles in a cube, 3x3x3. I have then gone and put a box where the faces of the rubiks cube would be which encloses/covers the particles on that face so it will activate the "test inside geomerty" node. By using an IF node, a test inside geometry node and some translation stuff (using a coold little node I found called CM_RotationPivot 2.0 by Ciaran Maloney on rray.de) on the particles I can get the particles on the face I'm moving to follow it and leave all the other particles in place. Great!

However...say if I move the top face, then I move a side face, the particles that were associated with the boxes when they were born are still associated after the turn so the rig goes a bit mental after a couple of turns.

What I'm wondering is, if there is some kind of method that can be used to re-evaluate if a particle is inside the geometry after I turn one of my enclosing box geometries (faces), say, 90 degrees so it doesn't permenantly get associated with that geometry? I've tried everything my little brain can think of but no dice so far.

So there are my ramblings...here's a picture of the ice tree (reeeaaaly basic) and a scene file (SI 2012 SAP1). The colours on the cube are currently just random colours, I haven't gone about setting each particle and its correct colour yet, just trying to get the basic workings figured out.


Image:http://www.rightpsyche.com/Files/RubiksCubeICE.jpg
Scenefile:http://www.rightpsyche.com/Files/Rubiks ... E-v01c.scn

Any thoughts would be appreciated..... I may be going down a dead end with this method but if that little problem could be solved, it could be potentially quite a simple solution for a rubiks cube rig! Or it could be a waste of time heh.

(Moderator edit: embedded the picture - HB)

[TwinSnakes007]

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-

[TwinSnakes007]

Where'd you get that rotation pivot compound (CM_RotationPivot)? That's the part I cant figure out how to do.

[Hirazi Blue]

I assume it's this one over at the Area... ;)

[TwinSnakes007]

Made some progress on this...well post a video tomorrow.

[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?