Anim8or Community

No need to apologize,

Tried that out, and it seems to do pretty much what I was suggesting to Steve, so it looks like he has already long ago implemented this, just in a form which I was unaware of.
(There are large sections of Anim8or functionality that I have barely touched on, so please excuse my ignorance.)

Thanks for the guidance. I learn something new about Anim8or every day, and it just keeps getting better and better!

Claude,

That's good to know ... but to borrow a phrase by Slartibartfast from Hitchhiker's Guide, "I don't know this 'Axis' mode of which you speak".
The only "modes" I have ever seen are Object, Figure, Sequence, Scene.

(I did say my knowledge of Anim8or features was not that broad, didn't I?  )

Thanks!

CC,

Groups can be used to reduce the number of manual copy-paste-and-rotate operations when the rotations are around a central point. You can group the models that already have been rotated and then rotate that entire group. It can significantly reduce the total number of operations involved. When you're done you can ungroup them all (or not) as appropriate. Similar groupings can help when creating linear assemblies.

I agree, though, that creating "macros" consisting of a sequence of operations would be very helpful.

Thanks Selden,

I have in fact used that technique many times in the past which can be great for replicating geometry where symmetry is involved.

chuft-captain: For your immediate example, try:

1.Copy, paste paste paste paste, and position them.
2.Select all copies and Edit->Rotate->Rotate Custom one time to rotate them all y+60.

You may have misunderstood my description of the scenario. In my example, the first object is copied and pasted then rotated to 60 deg. It then has focus, so the next copy/paste operates on that object which is then rotated to 120 deg (60+60), the next 180, and so forth around the y-axis. --- So I end up with 6 objects at 0,60,120,180,240,300.
I should mention that these are imported objects which seem to be treated a little differently in rotation than natively created objects.
eg. If I draw a cube, position it at [-50,0,0] then rotate it, each copy is rotated about it's own internal axis.
(IMAGE1)
However, if I first export and re-import it (as an STL), then each copy is rotated about the workspace axis.
(IMAGE 2)

I'm NOT complaining! This difference (whether deliberate or not) is a very helpful feature, but anyway, the second scenario is what I was talking about, whereas I think you're talking about the first.

One big issue is that it has to work for pretty much everything. Partially working features are frustrating to use because sometimes they just mysteriously don't work. Another is screen resolution which affects some commands. And the big one is the amount of work to add it.

I understand. It's just a suggestion for what might be a "nice to have", but the decision about what to do is entirely up to you, and must be tempered by the amount of work required, and the risk of regression/confusion.
My initial feeling was that this could be restricted to rotations, but I understand your motivation to implement a feature such as a "repeat last action/operation" with as wide a scope as possible.
I do think that cut and paste operations maybe should be excluded from a feature like this, and of course it should be subject to the usual undo/redo functionality.
If you were to add this in some form and extend it's use beyond just rotations, perhaps there still should be some limit to it's applicability ... ie. no cut/paste and perhaps limited to "transformation" type operations only, but then as you point out, you get into the issue of confusion around  "partially working features". I really don't have a broad enough knowledge of Anim8tor functionality to be able to suggest limits on it's scope.
Probably requires a bit more thought by "minds immeasurably superior to mine".... da .. da .. daaaah; da .. da .. daaaah !  ;-)

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

Thank you to everyone who took the time and effort to make suggestions on this thread.
I tend to just learn whatever limited functionality I need to get specific tasks done in Anim8tor so I probably haven't developed the depth of knowledge most people here have, so I really appreciate your advice.
It's always tricky when you "don't know what you don't know" (if you get my drift).

Cheers
CC

Is it possible just to uniformly rescale the 2nd copy to fit inside the 1st?

I'm not sure exactly what you mean, but I think that approach may result in scaling errors, and contiguous parts of the 2 meshes may no longer meet with that approach ... but perhaps I mis-understand what you mean.
I think I have a reasonably workable method now, but thanks also for the suggestion. If I can get my head around what you mean, then that may be an alternate solution. There's many ways to skin a cat, esp. in 3D modelling (pun intended).

Cheers
CC

Trev,

I understand your point, but seems to me it's just a tradeoff between ease of undo versus complete un-recoverability. I'm not suggesting ALL actions (eg. POV rotates, etc) should be preserved, just "significant" changes.
My personal opinion is that in many Anim8tor workflows changes in selection status of FEP is a significant enough action to warrant inclusion in the UNDO list, not least because the fiddly nature of these "edits" means that mistakes are likely to be frequent, consequences costly in terms of rework ( as my example demonstrates), and would not be expensive in terms of memory use in the UNDO stack.

Text editors like Notepad++ preserve all significant state changes in this way, and it's not usually a problem as long as you notice your mistake before too much new work has been created. Granted, the issues are a lot more complex in a 3D editor, than in a text editor, but the basic principle is the same.

I take your point about noticing a mistaken delete, but that
is just the nature of the beast, and applies equally in the text-editor example.

However, the point of UNDO functionality is to recover from recent mistakes. If a mistake goes un-noticed for a long time, then a decision needs to be made to either roll back and sacrifice subsequent work, or roll forward and apply a patch for the earlier error.
Just a decision you have to make depending on the circumstances, and the relative size/complexity of subsequent work vs original error.
When the UNDO stack preserves all significant state change, then you have the opportunity of making this decision (roll back or patch). When it doesn't, then significant amounts of effort can be lost with a single unfortunate click. (Which is where we are at present IMO).
Hope this makes sense.

Regards
CC

Trev,

Thanks for the suggestion.
That sounds like it will work but also probably just as tedious, if not more so, than my original approach. A lot of mode-switching, but it might lessen the risk of my finger sometimes missing MMB and clicking on the LMB instead. (We all know what happens then ...)

I suspect I'll still encounter issues with not being able to UNDO certain actions when I make a mistake using your approach ... which again might set me back to the beginning, but it's worth a try I guess

I do think however that the issue of the restricted UNDO functionality should be addressed. If that was resolved then accidental clicks or inaccurate selections would be easy to roll back which would make both of these approaches much more robust, not to mention making all anim8tor workflows much more robust.
Any thoughts wrt UNDO functionality STEVE?

Thanks
CC