Today, the first thing I did was to solve this problem. I asked Charles for help. He showed me using the assemble sop to identify each cube as an individual geometry.
Then I asked him how can I know which cube number to choose if I want to choose a specific cube. He then directed me to Ziggy. Ziggy explained to me while laying down sop by sop. First, I need to break up the group and re-assigning new primitive attribute then grouping them with the new attribute. Next, a foreach sop to add a point to each cube. A centroid expression to centralize the point. A delete sop to see the selection.
After getting the cubes isolated, I started applying jitter movement, running through foreach, using the rand($FF) expression, also an if statement to activate the expression at a certain frame. I tried tweaking the values of the expression but after quite some time, the movement looks subtle through the camera angle. I asked Steven for advice to see if scraping the idea will be better. He agreed.
After that, I carried on to the next part where the cubes will roll towards the camera. The steps are as follow; save a single bgeo of the rest position, delete unwanted attribute to clear up memory and neater in a way, creating a new velocity attribute and then promoting it as a point attribute so in a point sop, velocity can be added there. Next I put them into a dopnet and do a test run. However, the result was not as expected. Instead of individual cube roll, the thing moves as a whole, the entire area moved together. Consulted Ziggy on this and he points out that using RBD object moves the entire thing as it reads in the sop path while using RBD fractured group has a group mask function which read each group, allowing each group to act on its own. I had a test video on this.
No comments:
Post a Comment