AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |
Back to Blog
Group in cheetah3d2/28/2023 Similarly, if you remove Folder.2, move the Barrel, Burn the Transformation and drop Folder.2 back onto the Barrel, everything in Folder.2 moves again. If you remove Folder.2, move the Barrel and move it back, and drop Folder.2 back onto the Barrel, everything in Folder.2 moves. Moving the coordinate system of the Barrel-in order to center it-doesn't work, because when you move it back in Object Mode, everything else moves with it. However, the coordinate sytems are all at the origin, so nothing can rotate along its axis. There is a similar arrangement for the yellow Cylinder and the green Barrel. The Folder of boxes is a child of the purple Tube, so that when the Tube rotates, the Folder of boxes rotates also. In the browser, the two boxes are grouped (Folder) so that they move together. I've attached a picture to try to explain the difficulties I'm having. Cheetah seems to insist on the latter.įrom what I have seen of Cheetah, the ability to "burn" transformations of folders and their descendants would do the same thing, no? When ungrouping, the option is available for the children to keep the transformation (and stay where they are) or not (and return to their original locations). With nested folders, there does not seem to be any way for the children to keep the transformation incurred by the parent.Ī quick search of (ahem) Blender's manual seems to show that the group command uses one of the objects (active one) to be the parent of the others. But with raw polygon objects, you can at least "burn" a transformation to reset the coordinate system. In Cheetah, the new parent (the folder) always begins with a coordinate system that is the same as the universe's origin, so the children's coordinates don't have to change. When objects are grouped, a parent is created for the grouped objects, no? In order to prevent the children from moving in the universe, their local coordinates would have to change to agree with the new parent's coordinate system. Since I'm not familair with the terminology distinctions or programming concepts, I can't say one way or another, but what you say makes sense. I honestly can not figure out how to make nested group/ungroup/regroup functions perform at all, without keeping a very long list of every t,r, and s value for every folder, doing the arithmetic, and manually applying new values, every time. Perhaps some kind of instant groups, that, like the selections in 2D painting software, live as a current state but is never stored into the scene, and allow to restrain or to widen the field of an action.įor me, this is not a philosophical issue, it's practical. I guess that there should be some ways to make the two POV work together. When an action is performed on such a group, it is " solidified" for all the objects and extracting an object from the group means extracting the modified object.īut "algebraic grouping" MUST be preserved as it is a fundamental 3D modeling concept, and allows hierarchical transformation, cloning independently objects, and so on. IMHO, the kind of stuff that Lonestar and others require, is " action grouping", that is invoking an action (here a transformation) on a group of objects. To abstract, that's " action grouping" vs " algebraic grouping". Even if I fully understand Martin point of view on this topic, as it is the standard mathematic (aka algebraic) one, I must admit that this could be disturbing when working on important scene.
0 Comments
Read More
Leave a Reply. |