Child of or Group what's the difference?

What difference is there between making an object the Parent of other objects and grouping the objects in a group folder?
Say I make a door. Then a door knob. Then two hinges for the door. Now I want to adjust the pivot point to make the door open.
I want the knob and hinges to open with the door.
Is there an advantage to making the knob and hinges children of the door?
As opposed to putting them all in a group folder and then adjusting the pivot to the folder?
Thanks for reading and answering if you can.
 
I´d say I won´ t go one or the other way and merge the objects to one instead setting the pivot to one hinge - done.
Unless I missed a step perhaps.

Cheers
Frank
 
I ‘d agree. I was wondering though what the difference is if the editing or transposing or anything is different.
 
* There are quite a few different types of hierarchies possible in the object browser. Each of those (depending on the parent and the child / children) operate slightly differently or not at all. :devilish:

* Bear in mind that an object can be:
1 a polygon (raw or edited)
2 a spline
3 a modifier
4 a creator
5 a particle mesh (plus other instancing options)
6 a skeleton
7 a folder of some sort
8 less frequently used, but possible: a camera or a light
9 a script object
10 an effector
11 most likely, I forgot one or two

* As soon as you associate a subnode object to a supernode object you generate a hierarchy.
* Hierarchies can be stacked. The object browser simply will be re-dimensioned to cater for indentation.
* Modification of a parent will generally influence the children, ie properties are “inherited” by subnodes.
* Hierarchies are generally “calculated” from top to bottom. As a result, the order of objects of children / subnodes will result in a different mesh.

* In a group construct the parent is a “dumb” folder and has the generic parameters of position, rotation and scale, each in X, Y and Z.
* In many of the other hierachical parent > child trees the parent will have more complex parameters which filter down the tree, it can be termed a “smart” parent.
* Some hierarchies will work, others will be dysfunctional. This is largely a matter of logical analysis of the functionality of the nodes deployed in a specific construct.
* Oops, and - yes - there are good reasons to use dead hierarchies in a model :unsure::whistle::sneaky:
 
* Preliminary waffle: I am currently modelling neural nets, from simple to quite complex. In some tricky parts, the structure in the object browser is 12 levels "deep". As much as possible, I prefer to work with original C3D board tools, without any objects made editable. Of course, this is not always doable.
* Efficient editing, keyframing and testing would be virtually impossible, could I not manipulate the hierarchies in the object browser to suit the current editing tasks.

* So, some of the methods & reasons to create a "dead" - or mildly comatose - hierarchy (temporarily or permanent) in the object browser are:

1 Most obvious, toggle the visibility of an object / an entire hierarchy of objects in the E port. Collapse the tree if needed and you can access objects which have been obstructed by the stuff in front.
2 Disable creators to have access to the components. I currently use numerous creators (sweeps, lofts, lathes) in conjunction with splines. On toggling off the C icon in the object browser I gain access to the subnodeal splines and can edit those.
3 Of course, the same applies to any of the modifiers. If I have a substrack of, say, 3 modifiers attached to an object I can collapse an array / ring to a single instance and I can unbulge / untwist / un-whatever the hierarchy to revert to some simple mesh for fine tuning.
4 Tweaking particle meshes (and their relatives): Unfortunately, there is no simple way to collapse a PM to single instances.I have established a constructor folder for PM nodes if processing is required. Of course, I need to shuffle objects back and forth.
5 Booleans: Basically, as either creators or modifiers above, as a result of on the mode. Depending on the specific construction of a Boo, I can also toggle off individual elements of a Boo hierarchy.
6 Constructors: I am using quite a few invisible constructors in these models, be it as a base for particle meshes, as a guide in tags (spline tracks and targets, primarily) and other purposes. Generally, these are sitting in an invisible folder, but it is useful to edit (or keyframe) such objects to achieve some special effects.
7 I am sure, I forgot a few more useful tricks.

* This all (and a bit more) works seamlessly with the search option in the object browser (provided you have devised proper names for objects real and virtual) plus the layers (you can hide / show layers in the E / R mode checkboxes for a given layer).
* I do hope that the search function may be improved pro futuro. Some basic functionality (eg materials) are - unfortunately - not active when the object browser is reduced by a search. Materials can be added, but they don´t show until you return to the global browser.

* Most / possibly all of this you will know anyway, but there may be useful hints for C3D neophytes who are still experimenting with an efficient workflow.

:unsure:
* As much (possibly even all) in life, this is all a matter of personal courageous experimentation and resultant frustration. Whoever suggests there is a manual for anything important should not be taken seriously :mad: and seek medical advice :sick:
 
Back
Top