Anim8or Community

Please login or register.

Login with username, password and session length
Advanced search  


An update to Anim8or, v1.00b, is available with a few bug fixes. Get your copy HERE. See the "ReadMe" file for details.

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - chuft-captain

Pages: 1 [2] 3 4 5
Thought that would be the reason ... and it's a good thing, because often it's very helpful to rotate about the origin instead of the mesh's pivot ... and you know what I'm going to say next don't you ...   ;D 8) ... that it would be a good option to offer users when doing rotations of native meshes .. the option to rotate around the origin instead of the mesh center.



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.
However, if I first export and re-import it (as an STL), then each copy is rotated about the workspace axis.

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.

Quote from: Steve
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 !  ;-)

Will check out this build as soon as I get a chance Steve, esp. as it looks like you may have addressed some of the issues I raised with you in December regarding Groups and Layers functionality.
(BTW. Does private messaging work on this forum? I sent you a follow up PM in Dec, but as there is no apparent Outbox/SentBox in the forum, in the absence of a reply from you, it's not clear to me whether PM's are delivered or not.)


A suggestion for new functionality...

I do quite a lot of repetitive actions in my modelling (especially involving rotations, as I often design models which have some level of symmetry around the Y-axis).

For example, I might create a piece of geometry which I then want to duplicate and rotate through 60 degrees (x 5).

In this case the actions would be:

ctrl-V (Paste in the initial geometry)
then ...
ctrl-C, ctrl-V, Edit -> Rotate -> Rotate Custom -> tab to the Y-Axis box, type 60, click OK
and repeat this 4 more times...
ctrl-C, ctrl-V, Edit -> Rotate -> Rotate Custom -> tab to the Y-Axis box, type 60, click OK
ctrl-C, ctrl-V, Edit -> Rotate -> Rotate Custom -> tab to the Y-Axis box, type 60, click OK
ctrl-C, ctrl-V, Edit -> Rotate -> Rotate Custom -> tab to the Y-Axis box, type 60, click OK
ctrl-C, ctrl-V, Edit -> Rotate -> Rotate Custom -> tab to the Y-Axis box, type 60, click OK

WHat would be quite good is if there was some sort of "Repeat last operation" function (ideally linked to a hotkey ... perhaps ctrl-R or ctrl-shift-R)

This would significantly improve this workflow, by reducing the need to access several layers of menus multiple times in order to repeat the same rotation, and if tied to a hotkey would greatly reduce the tension in my mouse wrist!  8)

ie. It would be reduced to:
ctrl-C, ctrl-V, Edit -> Rotate -> Rotate Custom -> tab to the Y-Axis box, type 60, click OK
ctrl-C, ctrl-V, ctrl-R
ctrl-C, ctrl-V, ctrl-R
ctrl-C, ctrl-V, ctrl-R
ctrl-C, ctrl-V, ctrl-R

I guess this "repeat last operation" could extend to other types of operations as well, not just rotations (that just happens to be the situation where I often find myself needing it).

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.

Quote from: Steve
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).

Quote from: Steve
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!

Anim8or v1.0 Discussion Forum / BUG involving Layers, Groups, and Materials
« on: December 19, 2017, 03:03:59 pm »
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.

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.

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.

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

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

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.


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

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


Actually, I do most of the design work in openSCAD before importing into Anim8tor for finishing (splitting of the meshes, texturing, etc).
(Fig 1)

This makes it very fast and easy to re-design because it's a parametric design.

Want fewer floors? Change a single value: (Fig2)
Want more floors? (Fig3)
Hell of a lot more floors?  (Fig4)


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


Thanks guys for the suggestions.

I've managed to get this done with a combination of your suggestions.
1. By dealing with a quarter of the model this reduces the size of (de)selection tasks, and also makes the job easier thru easier access to the inner faces.
2. I'm then using the detach-faces method to separate into 2 meshes once the correct set of faces is selected. The hardest part of the entire process is getting the right set of faces selected - this is still somewhat time-consuming and prone to error, but less than before.
3. Once separated, I copy inner and outer into separate objects or layers, and then mirror, and join solids to recreate the original quadrants.

I didn't find it necessary to incrementally select small sets of faces then hide them and join them all at the end. This would probably reduce likelihood of mistakes, but at least for now I've found that reducing the size of the problem and easier access to inner faces means I can pretty much get it done in a single step (although I did notice one tiny error).

Now I just need to gradually improve this process so that it is less time-consuming and error-prone in future, as I will need to go through multiple iterations developing this model.

Thanks for all the suggestions. This is a really great forum. I haven't been here for quite a while, but got some very helpful suggestions almost instantly.
Really much appreciated!

Thanks again


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.



I agree that working on 1/4 of the mesh is a good idea, regardless of the workflow. What do you recommend as the best way to accurately split the mesh (exactly on the axes). Important to do this as exactly as possible so that are no tiny gaps when mirrored later.
Is there a way to delete every part of a mesh in a selected quadrant? ... or is the cutting tool the only way?



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?



I'm working on a mesh which is essentially like a curved box with windows. (I'll attach a couple of screenshots to this post to give context to what follows.)

What I need to do is to split this into 2 separate meshes; One mesh containing only the inward facing faces, and the other mesh with all outer facing and other faces (such as those making up the "window sills").

So the approach I've taken is to work on 2 copies of the mesh. In one I'll strip off all the inner faces, and on the other I'll strip off all faces except the inner faces.

This however is proving to be impossible to do in an efficient way (if at all) for a number of reasons.
I'll describe the workflow I'm using step-by-step so hopefully you can see what the issue is.
(Let me know if you need to see screenshots of any of the intermediate steps in order to understand.)

Mesh 1: (get rid of internal faces, leaving outer faces and window sills)
1. Face select mode; Restrict to BACK faces only; In the LEFT viewport, select the lot using area select.
2. Re-enable FRONT selection. In the front viewport, use the MMB to de-select any faces I want to keep (eg. outer faces and windowsills on the opposite side of the mesh ... selected by the previous step).

At this point, the inner faces on just one side of the model are selected, and I should be able to delete them and then perform a similar procedure for the other 5 sides.
Unfortunately, it's not that simple because a number of "window sills" are still selected (by step 1) on the side of the model I'm working on, because very few of these faces are perfectly orthogonal to any given viewport.
So before I can hit the delete key to get rid of the inner faces, I have to laboriously find and de-select those extra faces on the window sills, else they will be deleted as well.

This is a laborious and error prone process, and during this process I have to be careful also not to de-select any of the faces I actually intend to eventually remove.

The problem is that I have to find and deselect ALL of these ectras without making a single mistake before I can hit the DELETE key. This is turning out to be virtually impossible due to a BUG (or a functional flaw) in the UNDO history...
It appears that only actual modeling changes are being pushed onto the UNDO stack, which means that if at any point in this laborious process I make a simple de-selection error, or click the wrong mouse button, or forget to change modes between operations, there's no way to undo that single action.

At that point I have to go right back to step 1 and start all over again ... only to fail again.

So far I haven't been able to do even a single side of this mesh to completion, despite multiple attempts.

IMO, all actions (not just model changes) should be pushed onto the UNDO stack, as it's just too easy to make a single mistaken select / de-select, or mis-click in this long process.

I'd appreciate it if anyone has any clever techniques / suggestions to get around these issues in order to achieve the original goal.

Be interested also to know your opinion on the UNDO issue Steve, as it's all to easy to make accidental de-selection errors (putting me back to step 1) when using a MMB which also doubles as a scroll-wheel. If only I could just UNDO the last "action", then I wouldn't be forced back to square 1 every time I make a mis-step in the process.


Anim8or Challenges / Re: Challenge #34: Anim8or 1.0 splash screen
« on: June 01, 2017, 12:33:59 pm »
I just hacked these together from the splash screens (but this method doesn't make for very effective or pretty icons). Just a quick and dirty way to easily distinguish between the shortcuts.
I'm sure you can do better! :)

Anim8or Challenges / Re: Challenge #34: Anim8or 1.0 splash screen
« on: June 01, 2017, 11:51:10 am »
Some custom icons to decorate your new Anim8or 1.00 shortcuts...

Pages: 1 [2] 3 4 5