folders and combining objects

folders and combining objects

How come when I move an object into or out of a folder or another object, the proportions and position of the object i'm moving change? Is there a way to have the object retain it's XYZ coordinates independently regardless of whether it's in or out of a folder?
 
Hi,
the object only change its propotions and positions if you've already changed the coordinates (position, scale or rotation) of the folder.

The position coordinates of a object are always given relative to it's parrent object coordinate system. So if the folder isn't at the origin objects you drop into that folder will be positioned relative to the origin of the folder coordiante system.

The advantage of folders are that you can put objects into them and move all object which are in the folder at once when you move the folder.


By,
Martin
 
Re: folders and combining objects

Lonestar said:
How come when I move an object into or out of a folder or another object, the proportions and position of the object i'm moving change? Is there a way to have the object retain it's XYZ coordinates independently regardless of whether it's in or out of a folder?

Lonestar, have you figured this out yet? I've wasted hours and hours and hours and hours and hours.....
 
Hi,


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.

To abstract, that's "action grouping" vs "algebraic grouping".

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. 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.

But "algebraic grouping" MUST be preserved as it is a fundamental 3D modeling concept, and allows hierarchical transformation, cloning independently objects, and so on...

I guess that there should be some ways to make the two POV work together.

Tell me if I'm wrong 8) :lol:,

Cyril.

--- edited ---
PS : Just a though. 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.
 
klog said:
Hi,


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.

To abstract, that's "action grouping" vs "algebraic grouping".

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. 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.

But "algebraic grouping" MUST be preserved as it is a fundamental 3D modeling concept, and allows hierarchical transformation, cloning independently objects, and so on...

I guess that there should be some ways to make the two POV work together.

Tell me if I'm wrong 8) :lol:,

Cyril.

--- edited ---
PS : Just a though. 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.

Hi Cyril

For me, this is not a philosophical issue, it's practical. 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.

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. 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. 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. But with raw polygon objects, you can at least "burn" a transformation to reset the coordinate system. With nested folders, there does not seem to be any way for the children to keep the transformation incurred by the parent.

A 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. 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). Cheetah seems to insist on the latter.

From what I have seen of Cheetah, the ability to "burn" transformations of folders and their descendants would do the same thing, no?

Eric
 
Hi Eric,

Eric_J said:
From what I have seen of Cheetah, the ability to "burn" transformations of folders and their descendants would do the same thing, no?

You're right and that's what I've call instant grouping in my previous post, because "burning" the children transformations finally means applying a temporary and convenient group to that objects, to perform actions on them. For that kind of use (which are always followed by an ungrouping) it should not be necessary to push all the objects into a folder, acts on it, "burn" and extract the objects from the folder. In this regards, multiple selection of objects, with a way to lock it, could be usefull.

Cyril.
 
Hi Cyril

I agree that making multiple selections and locking them would be a great help, but why does that have to be temporary? And how does that relate to folder behavior?

The ability to group and ungroup quickly and easily--and to manipulate the point around which a group transforms, either temporarily or permanently--is absolutely critical in making assemblies with components. This same behavior works in SketchUp fine (mostly)...so IMHO, claims that "it can't be done" or "all 3D programs work this way" are, for me....um....difficult to swallow...

I think Cheetah is really great, but for me, this is a significant problem...

Eric

:D
 
Hi Eric,

Eric_J said:
I agree that making multiple selections and locking them would be a great help, but why does that have to be temporary?

Cause if you want to preserve your objets into a group, its transformation will remain the same than the group one, and there is no need for a special tool : this is how the Cheetah3D folders work.

Locking a multiple selection is also a form of grouping...

Eric_J said:
And how does that relate to folder behavior?

I think that it should be important to distinguish between conceptual composite models that require algebraic chaining and grouping, and that are intrinsic to such a model, requiring a long term kind of relation between sub-components, and between convenient grouping for modeling purpose, that are short term grouping.

I don't think that using the same idiom for the 2 is a good idea.

Eric_J said:
so IMHO, claims that "it can't be done" or "all 3D programs work this way" are, for me....um....difficult to swallow...

Relax Eric ! ;) This is a 3D software "internal" point of view. 3D scene are the expression of mathematical representations. You can use GUI trick that simplify the way your work, but vertices are 3D points and transformations 4x4 matrix, so fundamentally, 3D softwares inherit from linear algebra (scene graph, inverse kinematic, mechanical system, ...).

By the way I never read any "it can't be done" on this forum.

Eric_J said:
I think Cheetah is really great, but for me, this is a significant problem...

And I'm pretty sure that Martin is hearing you :)

Cyril.
 
Hi,
I can understand that it would be nice to have a direct counterpart to what's possible in some 2D apps. But here is a small example why it doesn't work in a 3D app with a "true" transformation hierarchy.

1. Create a Folder and drop a cylinder into it.
2. Rotate the cylinder by 45°.
3. Now scale the folder by 0.5.
4. You end up with a sheared cylinder.

The question is now what position, rotation and scale parameters such a sheared cylinder would have in the global coordiante system? And the answer is there doesn't exist such a trippel.

It would be necessary to transform the vertices by itself to the global coordinate system. But that isn't possible with parametric objects.

I hope that example helped a little bit to understand the actual problem.

By,
Martin
 

Attachments

  • cheetah3dschnappschuss006_122.jpg
    cheetah3dschnappschuss006_122.jpg
    28.5 KB · Views: 602
  • cheetah3dschnappschuss005_135.jpg
    cheetah3dschnappschuss005_135.jpg
    26.3 KB · Views: 589
  • cheetah3dschnappschuss004_781.jpg
    cheetah3dschnappschuss004_781.jpg
    7.4 KB · Views: 598
Hi Martin,

I do not know if I fully understand Lonestar request, but I think that he just need a way (and the reciprocal) to extract an object from a folder, and preserve the current coordinates of all the object vertices.

IMHO, it should not be necessary to attach a full featured transformation to this object, if you apply the transformation hierarchy to each of the vertex, and set the extracted objet transformation to identity.

Regards,
Cyril
 
Hi Cyril and Martin

I've attached a picture to try to explain the difficulties I'm having.

In the browser, the two boxes are grouped (Folder) so that they move together. The Folder of boxes is a child of the purple Tube, so that when the Tube rotates, the Folder of boxes rotates also. There is a similar arrangement for the yellow Cylinder and the green Barrel.

However, the coordinate sytems are all at the origin, so nothing can rotate along its axis. 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.

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.

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.

I don't know the math/logic/code issues involved, but this behavior is virtually impossible to work around, unless maybe you can do Rubik's cube drunk and blindfolded and calculate the orbit of Venus' moons in your head, and I can't do that...:(

If you DO get it all worked out, and decide to change grouping, you pretty much have to start all over again.

Does this explain the problem? Does *anyone* out there have any suggestions?

Thanks!

Eric
 

Attachments

  • boxestubes_01_205.jpg
    boxestubes_01_205.jpg
    106.4 KB · Views: 435
Martin said:
Hi,
It would be necessary to transform the vertices by itself to the global coordinate system. But that isn't possible with parametric objects.

I hope that example helped a little bit to understand the actual problem.

Martin

Thanks for the explanation--this seems to make sense for parametric objects. Does the same thing apply with raw polygon objects?

If having a 3D application work like a 2D application is difficult to implement, it would help to have some suggestions on how to build and animate complex scenes? Hmm....maybe that should be my job..... :)

Eric
 
Hi,

Eric_J said:
Thanks for the explanation--this seems to make sense for parametric objects.

Martin, you could attach an invisible (for the user) transformation matrix to all the objects in addition to their current scale/rotation/translation triplets.

This matrix is initially set to identity.

When an objet is extracted by a special action from a folder, this matrix is set to the concatened transformation hierarchy of the folder (including the object own transformation), and the scale/rotation/translation triplet is reset to neutral.

This way, you don't have to make such an extracted object, an editable one (raw poly), and you can preserve parametric objects.

Another option is to add a second triplet (plus the first one and the above matrix) that is able to save the old triplet of the object (before the special extraction from its folder). This should allow to switch losslessly between tthe 2 states of the objects.

Cyril.
 
Cyril/Martin

This may or may not be relevant (or correct!) but it seems that the global coordinate sytem (or an object in it) can not have a scale attribute; it can have only position and rotation, because they are absolute. Scale does not exist--only size.

In that case, could Martin obtain his triple point by defining the user's global coordinate system to be the child of an invisible (not accessible to the user) global coordinate system where position and rotation are indentical, and the scale is one?

Or maybe that is what you just described, in programming terms?..... :)

Also--in the Properties window, the position, rotation and scale numbers show the local coordinates. The option to have an additional window with the global coordinates could be of some benefit (just a thought...)?.... Or maybe a pull-down option to see global coordinates.....

Eric
 
Back
Top