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
Selden makes a good point.

We would not want to break the export scripts!

Fortunately, though, there is a workaround: Object/Point Edit's "Drag Select" option can be used to select all of the surfaces in the current Object, including those that Ctrl-A doesn't select.
That's interesting because in the scenario I describe above, the drag-select does not select the group in question.
No hurry for me to get a fix though Steve, because I'm not really doing any actual modeling lately ... just using some models I was playing with last year, to test your new code.

Also, to Selden, have you considered importing the STL's directly into Anim8or to see if there's any difference in how they're handled when not converted into OBJ format first?

Yes, I suspect you're right. It's probably always been the case as you say (I've confirmed it as far back as build 1269, so it seems this would be a new feature.
I'm not sure how hard this would be for Steve to implement, but what do other's think of the idea to be able to export only visible layers?

It looks like I broke this in my latest changes to groups. I'll fix it.
Thanks Steve,

... although FYI I think this has been happening for a while, maybe as far back as build 1269 or earlier, so you might have to look back a ways to find the fault.

Any groups involved? ... in my case I definitely saw a difference in "selectability" between meshes and groups... which makes me suspect some issue with group-layer memberships.

YMMV - well obviously it does!  ;D


I've seen something similar. I haven't yet worked out exactly what's going on, so take my comments with a grain of salt.
I think this is related to the Group/Layer changes. It looks like there may be still some gremlins to work out.

In my case I had one group of meshes in layer 6, and another group in layer 0. The (faces of) the groups/meshes in layer 6 were selectable, but (faces of) the group in layer 0 were not.
I disabled the visibility of layer 6, and ungrouped the group which was unselectable. It disappeared, so I re-enabled layer 6, and there were it's constituent parts (whose faces are now selectable). However, if I re-group those objects, they automatically return to layer 0 (at least their group does) and once again, the faces are not selectable.

So there seems to be a few issues here.
1. The sub-meshes seem to retain a "memory" of their previous layer membership when grouped, and on un-grouping, they return to that layer (in this case layer 6). If I then immediately re-group those objects, the new group returns to layer 0. The combination of these 2 things it seems to me makes it impossible to permanently change the layer membership of a group of meshes, because they retain their memory of another layer instead of inheriting the layer of the group.
IMO, if you move a group to a different layer then the sub-groups and sub-meshes of that group should also inherit that change, whether they remain grouped or are subsequently un-grouped.
2. It seems to me that the fact that the faces are not selectable has something to do with the fact that they are in a group. Is this also the case with you?
When I ungrouped, the faces of the ungrouped objects became selectable (in layer 6), but these were also grouped objects themselves, which again suggests to me that this has something to do with the object layer not matching the contained object's layer(s), rather than simply the fact that they are part of a group.

None of this I'm sure of ... more testing is required ... but I hope this helps.

EDIT: Bingo! I've just worked it out.
As I said. the objects contained in my "unselectable" group seem to think they are members of layer 6, even though they are grouped in layer 0. When layer 0 (the group's layer) is visible the group is visible, and the faces are also selectable, BUT ONLY IF LAYER 6 IS ALSO ENABLED. If layer 6 is disabled, the objects remain visible (because they are members of a group in layer 0 (which is still enabled), however they are not selectable because they "think" they're still members of layer 6 (which is now disabled).
It seems that the "selectability" of objects and their faces is linked to their layer membership (and it's visibility status) ... (probably as it should be), but, because they seem to be retaining their memory of layer 6 membership, they are not selectable when that layer is disabled.... even though they are grouped (and visible) in layer 0.

The selection issue, only seems to be an issue for "sub-groups", "meshes" however still seem to be selectable when part of a group in another layer, even when their own layer is disabled. It seems to me that layer membership is not being propagated down and applied from the top-level group to the sub-groups.

Anim8or v1.0 Discussion Forum / Invisible layers are always exported ...
« on: February 02, 2018, 10:24:08 am »
One thing I have noticed recently (prior to this latest 1318 build) is that when exporting a model with hidden layers (into CMOD format) it seems that the hidden layers always get exported regardless of their visibility. This, to me seems counter-intuative, and caused a few duplicate mesh issues in exports, until I realized what was going on.

IMO, what is exported should be only what's visible at the time (otherwise unexpected extras can end up in the export).
It would be good to be able to easily export an assembled model as a series of sub-models (if so desired) by just enabling the desired layers, and disabling all other layers, then exporting the partial model.

This has a lot to do with my workflow, so YMMV. The opposing argument would be that users would have to make sure that all inhabited layers are visible if and when they wanted to export the complete assembly, rather than in parts.

I hope this makes sense ... what do you think of this idea?


I just did a very quick check of the Group/Layer changes, and on first glance it looks great!
Individual and combinations of layers can now be displayed or hidden at will, regardless of the status of Layer 0, and it appears that Layer 0 is no longer treated as a special case. (This I agree with completely.)

I'm sorry, I don't have time to test these changes in depth at the moment, but on a very cursory first glance it looks really good, and I'm amazed you got this done in such a short time since Christmas! Thanks a lot!
I'll do some more in-depth testing of the interaction between Group/Ungroup actions and layer memberships when I have more time, but it's looking good so far.



Sorry, I appear to have hijacked this thread a bit. If you want to keep this thread on topic, you can split off all my suggestions into a separate thread if you like (especially as it turns out you've already implemented most of my suggestions in some form or other a long time ago!)


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!


I can't find that button in my version (latest dev build 1318).
The only button that looks vaguely like it is in the Coord section (group of three) but when I hover over it, it says "World Coordinates <w>".
Is that the button you meant?

EDIT: Forget that, I think I just found the button you mean (just above the other one) ... sorry about that. I'll try that out to see it's effects.


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?  8) :D :D ::) )


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

Pages: [1] 2 3 4