Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[chuft-captain]

Hi Steve,

I'm working on isolating various components of a model (not mine originally) which for me started as an STL file with no submeshes.

I started by using the latest DEV build (with the Build -> Split Solid function) which seemed to work OK as far as revealing the original sub-meshes. Many of these are not grouped into larger conglomerations, so the technique I'm using is to select individual meshes and/or locallized groups of meshes, group them, and move them into a separate layer.
Once I've gathered all the meshes I want in a particular assembly all together in a sperate layer, the plan then, is to go to that layer, ungroup the temporary groups and either re-group them or Join Solids. Then rinse and repeat to create other major assemblies.
Eventually all of these re-structured assemblies will be brought back together into some form of composite model.

That was the plan ... unfortunately, I've struck a problem.
IMAGE 1 shows the model with groups layers 0 and 6 enabled...
The curved section on the right has been isolated into a number of groups from different numbers of individual meshes (one of these groups is shown selected), and each of those groups gets moved to layer 6.

If I then hide layer 6, this proves that it this whole collection of groups is in layer 6.
(IMAGE 2)

What I need to do next, is hide Layer 0, and work with Layer 6 to un-group all the temporary groupings and then re-group or join those elements.

However (IMAGE 3) is what I see if hide Layer 0 with just Layer 6 enabled.


Ctrl-A shows that all the groups are there, but none of them is visible.
(IMAGE 4)

A bit of investigation reveals that in the process of grouping/moving these meshes the material definitions disappear. Instead of showing -default- as the material it is just showing a blank white space for the material, and there is also no way to re-apply the default (or any other material) to the group because neither the drop-down list, or the ellipsis button (...) is functioning.
(IMAGE 5)

If I then un-group everything in Layer 6, they of course are returned to Layer 0.
(IMAGE 6)

-- Incidentally, we've had a discussion a while ago about which layer objects should go to when un-grouped, and whether they should automatically go to Layer 0 when un-grouped).

In the process of un-grouping them, the material definitions are restored on the individual meshes, but they're back in Layer 0 ... a bit of a Catch-22. (I've moved the rest of the model out of Layer 0 temporarily in this screenshot.)
(IMAGE 7)

Trouble is, I need them in Layer 6, assembled / grouped with material definitions retained or re-applied (either individually or to the entire assembly), so that they are NOT invisible!

The main issue seems to be the loss of material definitions in the grouping process. For some reason, I can group them in Layer 0, and they remain visible in that layer, but when the group is either created or moved to Layer 6, the material definitions are lost and so they become invisible in Layer 6. I think it's happening at the grouping step, and the only reason they're still visible in Layer 0 is because for some reason it doesn't care about the missing materials. Incidentally, if both Layer 6 and Layer 0 are enabled, I can see the structure, but when Layer 0 is disabled and only Layer 6 is visible, then the structure (although present in the Layer) is invisible.

CC

EDIT: I've just confirmed that the issue is definitely caused by the group / un-group actions, rather than the layer change, by first changing the layer on individual meshes, then grouping them after they are already in Layer 6.
Once again, as soon as they are grouped, they become invisible (ie. lose the material definition).

[Steve]

I had intended to give a new group the same layer as its components, and if they are not all the same layer give the group the default layer. But it look like this doesn't work.  I'll fix that.

As for the visibility issue, if either the layer of the group or the layer of the component is hidden, then the component will not be shown.  I.e. they both need to be enabled to see the component. So in your image 3 layer 0 is still hidden so the group is hidden even if it;s components have layer 6 which is not hidden.

Currently: Groups don't have materials - they are just a container.  So you can't assign them a material. Would you like to be able to assign a material to all components in this dialog?

[chuft-captain]

I had intended to give a new group the same layer as its components, and if they are not all the same layer give the group the default layer. But it look like this doesn't work.  I'll fix that.

I think that's not the issue in this scenario. As far as I can tell the grouping is working (apart from the "materials"" visibility issue), and I don't think I've encountered too many other issues with grouping but that said, I'm not sure if I've ever actually tried to group objects that are in multiple layers, which I guess is where this particular ambiguity would arise.  I'm not sure what the best solution is in that scenario.

As for the visibility issue, if either the layer of the group or the layer of the component is hidden, then the component will not be shown.  I.e. they both need to be enabled to see the component. So in your image 3 layer 0 is still hidden so the group is hidden even if it;s components have layer 6 which is not hidden..

I think that this indicates that you and I maybe have fundamentally different ways of thinking about the purpose of "layers".
I think that this statement:"if either the layer of the group or the layer of the component is hidden, then the component will not be shown" is the issue really because (at least for me) this causes great confusion because of the way I think about the purpose of "Layers", as I'll explain below.
I actually didn't realize this was the case, but in my opinion, the idea that a component and a group containing that component can have different layers is bound to cause confusion wrt. visibility, as well as other ambiguous situations for which you're trying to find a solution.
The paradigm I think of is similar to the typical concept of "layers" in an architectural drafting program (eg. Archicad, etc) where objects of a certain type or "class" are assigned to a particular "layer" (eg. layers might be called: electrical, plumbing, landscaping, etc) and components within a particular layer may or not be "grouped" together into larger assemblies. At any time a particular layer can be made visible or not.
In that sort of program, objects would tend not to switch between layers in most cases (at least not very often). Conversely, layers would be made visible/invisible frequently.
Those programs typically allow an essentially unlimited number of "user-defined" layers.

Anim8or, as a general purpose modeling program, perhaps needs to be a little more generic than that, however it seems to me that the "uncertainty" about what to do in certain circumstances arises from the fact that objects from different layers can be grouped together.
Perhaps this area needs some rationalization and a clear definition of the purpose of grouping and of layers.

It seems to me that the act of grouping components is a deliberate act which implies the designer has some idea of a common purpose for that "assembly" of components, in which case, I think that the group and it's components should always have the same layer.

YMMV of course, but the comments above describe the way that I think about this.

A few simple restrictions/changes might simplify things and remove the "uncertainties" about layer choices:

• You can only group components (and/or other groups) that are already all in the same layer. (The new group stays in that layer initially, but can later be moved into another layer if desired ... in which case #2 below will apply).
• The component meshes and / or any sub-groupings will always inherit the current layer of the topmost group if and when it changes layer (the layer would propagate down through the hierachy). If un-grouped on a later date, the subordinate groups/components will remain in that layer initially.
• Obviously when a group or component is "released from it's captivity in a top-order group", it then once again becomes a top-order object itself, which means that it can once again be directly assigned to a different layer. In which case rule 2 would apply to it's subordinate objects (if any), if and when it 's layer is changed.

It follows from these rules I think, that a change of layer can only occur from a decision and deliberate action on the part of the model designer. Anim8or will ensure that objects stay in the current layer when un-grouped, and therefore as a developer you no longer have to worry about what the best action is (wrt. layer choice) in a myriad of group/ungroup scenarios. It's up to the designer and whatever their workflow is, to manage the layer location of all (and only) top-level components, whether they are unconstrained meshes, or grouped assemblies.
The part which would be enforced by Anim8or is the requirement for all subordinates to inherit the layer of the top-parent (at all times).

Currently: Groups don't have materials - they are just a container.  So you can't assign them a material. Would you like to be able to assign a material to all components in this dialog?

I think that would probably make sense, although this I think should be only an optional action with a warning (rather than the mandatory inheritance I suggest for layers), as there's probably many scenarios, where components or sub-groups would already have materials assigned which you would most of the time want to keep.
This could be a dangerous option, but might provide some flexibility and efficiency in the assignment of materials, and hopefully will also solve the issue where materials are lost when things are grouped. (Note: this implies the "Material" on a group will need to indicate something like "multiple" when the sub-ordinate materials have NOT been over-written.)

One "buyer-beware" that occurs to me is: how will this capability impact on UV-mapping (or visa-versa)?

BTW. I seem to remember being able to assign materials to groups in 0.95 / 0.98. You might want to check that, as this might be either a bug or regression ... or maybe you made a deliberate decision to change this at some point (I'm certainly not aware of all the changes you've been making lately.)
... or my memory is flawed!

Bear in mind also, that this model has a rather unknown origin and history and has been initially separated via the new Build -> Split Solids functionality, so although unlikely, it's possible that some of the behavior I'm seeing may be due to an issue with either the model or the new code.
It does look more like an Anim8tor issue though, but I suggest you confirm independently with another model (if you haven't already) before doing a whole lot of code changes.

NOTE: I'm not asking you to make these changes before Christmas of course. I wouldn't ruin your Christmas like that! ... and some of my suggestions are probably significant enough that you should probably stew on them for a while to consider all the ramifications, and also allow other people's viewpoints/opinions.

Merry Christmas!
CC

[Steve]

Good feedback. There's a bit to digest here, but I have a couple of comments.

Groups and Layers:

I agree that it's confusing as it is. Putting everything in a group on the same layer, as you suggest, is easier to understand. So I propose doing pretty much what you suggest:

1) When you make a group, if all components are in the same layer assign the group that layer. If not, prompt the user to choose a layer to assign to the group and all the components.

2) When you dissolve a group, keep the same layers on the components as they were assigned when the group was formed.

3) Changing a groups layer also changes all it's component's layers. (Probably obvious, but just to make it clear.)

Group materials:

You're correct, v0.98 showed "Multiple" as the material when there were multiple materials within the components of the group - and you couldn't change it. If they all used the same single material then you could change it for all components in the group dialog. This somehow stopped working so I'll restore this original behavior.

[Gyperboloid]

Layers, as I finaly figured out, are very usefull. We just should clear it up a little bit.
First: Steve, it seems that the "0" layer has kind of a "higher priority" by default, always. When you hide that layer, in the material bar, the matterials ( visuals , spheres ) don't show, you can see the names only ( pic.1 ).
Also there's something with the primitive (the Mesh Primitive - see "a mesh" - is fine) created on an empty layer set as default, different than "0". The "0" layer pops up, although other was set as default. When you double click on the primitive and then close ( only by "Ok" ) the parameter window the "0" layer turn off and the ( say ) "1" gets active with the underline under it ( the same result can be achieved by simply converting the primitive into a mesh )( pic.2). Note: when creating two or more primitives without changing the settings, first gets active the " 0 " layer ( first primitive ) and then as an addition the default ( if different than " 0 " ).

Now, very important, about grouping- ungrouping. Ofcourse very important others opinion, how they generaly go around with it.

1)When grouping items of the same layer, it's obvious the group should stay in that same layer  (period) Ungrouping items, that originaly were located on the same layer, should be relocated on that " old" layer and not transfered automaticaly to the "default" layer
2) About grouping items from different layers: first I thought it would be good to prohibit that possibility and to mention, by a pop up window ( So'd just you know window  ), that items can be grouped only when they belong to the same layer and they must be manualy transfered to the same layer before you can group them. Then, ofcourse I understood that it would be stupid, because you loose the ability to group at once a lot ( million ? ) of items without the need to manualy ( !!! ) edit their settings !!! So, grouping items, that originaly belong to different layers should locate the newly created group into the default layer.
And here I bring up again the suggestion, if it is at all possible, to set the " default " layer via the Midle Mouse Button on the tool bar directly. You just click ( MMB ) on the layer you are currrently working in ( better maybe "working layer " - as a replacement to that " default"  ), that layer gets the underline and everything you group will be transfered to that " working" layer. It's the way actually things work now, just you have to go all the time through the Options menu, wich is not practical. Currently, when ungrouping items that originaly were located in different layers, each item returns to its original layer and that's the correct way, nothing should be changed, because when editting often you need to group things just for a sec or two and then relocate everything back. The only thing is that grouping items from different layers, as you mentioned, hidding the layer (of the item originaly ) hides the item inside the group. That should not happen. The visibility of the group should relay only on the layer that the group belongs. Anim8or should " seek " for the group layer's visibility only and only when items will be ungrouped they can be affected by their original layers.

[selden]

It seems to me that grouping and ungrouping should not affect the layer memberships of the group's members in any way, or at the very least that maintenance of its distinct layer memberships should be an option.

To hearken back to CC's reference to architectural design, it seems appropriate to be able to group together all of the meshes comprising all of the layers of a room ( electrical, plumbing, furniture, walls, etc) so one can copy that room from one building to another while preserving its layers.