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

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.

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

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

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

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!

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

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!

i'm pretty sure this is the first time i've produced a piece of art and somebody's responded with "hmm... it's nice, but it needs more poo" - but hey, whatever floats your boat, heheh

LOL. The poo idea is mostly about finding a way to inject the mascot into the splash (with a bit of comic relief), as well as to confer good luck upon Version 1.00. (I'm sure you've heard the expression: "It's a sign of good luck to be shat upon by a bird" ... although I've always suspected that this particular proverb probably originated only out of a desire to make the shitee feel a little better about the event.

...i thought about giving the image a grittier overall effect, leaving some of the 'window' panels out and showing pipework and concrete walls behind, with cables coming through, hanging in mid-air and attaching to the text object as if it was undergoing some sort of maintenance.

I'm picturing a sort of "Blade Runner" aesthetic from your description. (Or perhaps something more recent such as the movie "Total Recall", or "The Expanse".)

Chuft-Captain: Certainly not going down that way, much to long winded having to navigate through DOS to get to where I want to be.

Kreator: No need for DOS, these are windows shortcuts. For your convenience I'm made them for anyone that wants them. Just extract the attached Zip onto your desktop or the folder of your choice. NOTE that after extracting you will have to edit the target box in each shortcut and change "C:\Anim8or\v1.0\Anim8or.exe" to the location of your own anim8tor 1.0 executable. (eg. "C:\Program Files\Anim8or\Anim8or.exe")Note also that if spaces are involved such as in "Program Files" you WILL need the quotes as well.