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.

Topics - chuft-captain

Pages: [1]
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?

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


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.


(Build 1269)

So it's a bit hard to work out exactly what's going on with this one, but I think the crux of it is that when grouping objects it seems that the group is always sent to layer 0 (even when the grouped objects are initially all in the same layer).
If Layer 0 is hidden then the newly grouped object disappears from view ... in which case I can re-enable Layer 0 and re-assign the grouped object back to the original Layer, however if Layer 0 is visible, then it's not immediately apparent that the Layer has changed.
I understand that when the objects being grouped are individually in different layers before grouping, then the only logical decision I guess is to put the group in Layer 0, however when they're all already in the same Layer, then perhaps it is more appropriate for the group to remain in that Layer.

This opinion is based upon the way that I work --- I tend to use Layers to group multiple objects which are used to compose an assembly or assemblies, but I often need to temporarily un-group assemblies to make changes to individual elements, and then re-group the assembly or assemblies, at which point the assembly and it's components gets re-assigned to Layer 0 (and this fact often goes un-noticed by me if Layer 0 is also visible.)
I imagine that if I was to make changes in all Layers and forget to re-assign the Layer on every occasion after re-grouping, then eventually everything would just end in Layer 0 ...  so I think you can see the problem.

As I can have multiple assemblies which I may want to view and work upon independently, I tend to organize each assembly and it's components into it's own Layer. I then want it to remain in this Layer unless I choose to move it elsewhere. The constant re-assignment to Layer 0 causes a bit of chaos which affects my workflow.

Other people may have a different opinion about this if they perhaps use Layers in a different way to me, but this is how it affects my workflow.


This post referenced in: Version 1.0 Bugs and Suggestions


While UV mapping a texture I needed to maximize Anim8or.
After maximizing, the viewport failed to redraw.  After returning to windowed mode it came right.

Around about the same time this happened, I also tried to save the project but when trying to enter a filename to save as, I found that my keyboard was giving the wrong chars.
eg. I would press the "-" key and get a single quote. The ";" key would give md something like an "a" with some sort of umlat decoration.

Note that around the time these issues appeared, I had also downloaded a couple of random textues, so this behaviour may be indicative of a virus rather than an actual Anim8or bug, but it would ne interesting to see if anyone else can replicate these issues.

Great that we now have the ability to organize objects into folders, however, in projects which have a lot of objects (eg 100+) it can be very tedious and time-consuming to create (or re-organize) those folders because each object must be visited individually, and a dialog opened, etc...  in order to change it's folder.

Some way of bulk-selecting objects (and maybe drag and drop functionality) to be moved into a specific folder would make life a lot easier in this respect.

This post referenced in: Version 1.0 Bugs and Suggestions

In earlier versions, the current object window has always been indicated by a "tick mark".
Now that we have the ability to organize object windows into folders, on re-opening a saved project, it can sometimes be a little difficult (when there's a large number of objects and folders) to locate the folder in which the current object window resides.

Perhaps a tick could be maintained on the parent folder of the current object as well as the object itself.

This post referenced in: Version 1.0 Bugs and Suggestions

A while ago I told Steve I had a few thoughts / observations / suggestions for version 1.0, however I'm always too busy doing other things, so I never get around to posting them.
So what I thought I'd do is create this thread as a place-holder containing a reference to each of the suggestions, bugs etc, as I get around to posting about them. Some will be simple bugs, others might be issues raised as a result of changes in the latest build, and some others will be issues that have been around for a long time which I've never got around to reporting. (Most of these I've either long forgotten about or found workarounds, so I'll probably just post about each of these as I re-encounter them and my memory is jogged.)

Please DO NOT REPLY to this thread, as it's just designed as a personal reference / index to the issues as I report them. Please only comment / reply in the DETAIL thread (once I've created it).

As I get around to it, for each issue, I will add a bullet point to this post/thread with a link to the detailed thread describing the issue in more detail. If you see an item listed here without a link to a separate thread, that's just because I haven't got around to creating the detailed thread yet.

As I said, if anyone has comments about any of these issues, please reply in the DETAIL thread (NOT in this thread).

Here's the first few:
1.OPENBuild 1269 BUG - Alt key has been re-assigned. DETAILS HERE
2.FIXEDObject Folders - Parent Folder needs an indicator as well. DETAILS HERE
3.OPENObject Folders - Some sort of bulk re-organisation functionality needed.DETAILS HERE
4.OPENGroup / Ungroup - inconsistent effects on Object Layers DETAILS HERE
5.OPENGroup / Ungroup loss of Materials -- (May have been fixed already - TBA)
6.NOT A BUGRedraw failure + keyboard remapped on SAVE. DETAILS HERE

It appears that the function performed by the ALT key has been reassigned in this build.
Previously (0.98) it was used in combination with the Right-Mouse button to allow de-selection of faces, lines, vertex's in Object/Point editing mode.
Now it appears to bring up the rotate tool instead. (Not sure if this is an intended change or simply a bug.)

This is a problem because I can see no way now to deselect faces, etc. when accidentally selected.
For example, after selecting 50 faces, if the 51'st face is incorrectly selected, there is no way to undo that last selection, and you have to start from scratch every time you make an accidental selection.

This post referenced in: Version 1.0 Bugs and Suggestions

I'm doing some rendering tasks at the moment which require the exact viewpoint to be replicated for every single render. The rendering tasks are very tedious and repetitive, so I was hoping to write a script to automate this. Is this possible in ASL?
I haven't really done a lot of scripting in Anim8tor, but a quick look suggests that ASL is perhaps aimed at modelling and animation tasks, but I'm not sure if it's capable of scripting user actions, etc.

For example, after setting up a Custom Viewpoint, the script might need to do some or all of the following:
(pseudo code)
Initialize/specify Renderer
Perform AA Setup (set SPP, Sampling Method)
foreach <object> in <list of objects>
   foreach <material> in <list of materials>
      -- apply material to object
      -- Render -> Render Image
         Select Antialiased
         Select Image + Alpha Channel)
      -- Save the rendered scene as a PNG to a specified Output Folder with a unique filename genarated using some convention such as:
      -- Close render window
The end result would be a folder containing a rendered PNG with alpha channel for each combination of object / material.
      eg. a couple of example filenames using this convention might be:

Can these sort of tasks be automated in ASL?


General Anim8or Forum / Crash in Build 1269
« on: April 18, 2017, 04:12:35 pm »

I'm new to this forum (but not so new to Anim8tor as I've been using it for at least 10 years now).
Tonight I installed DEV build 1269, specifically because I've found that I've recently found that I need the ability to create custom User Views. (Prior to this I was using 0.98 which does not have this feature.)

For a while all was good with this build, I created a few Custom Views in one object, and re-organized a long list of object windows in my project into folders (also a feature I've wanted for a long, long, time!)

Unfortunately (and this is the reason for my first post here), I found that when I created a new Object Window and tried to cut and paste a mesh from the original object into the new window, the moment that I switched to the newly created window the program crashes. (This only happens if I'm using a Custom View at the time. -- If using one of the standard views (Ortho, Front, Back, etc... ) then no crash.

As a side comment, with regards to the User Views functionality, I notice that newly created views are only valid in the Object Window in which they are originally created. I personally think that it might be more useful to give them a global scope (or at least allow the view definition to be copied/transferred/applied from one Object window to another).
This is perhaps dependent on the specific use-case, but in my case I want to be able to layup different components of a scene in separate windows and then render them separately (using the same custom view) in order to create transparencies of foreground objects (ie. with alpha channels) which can then be later superimposed on different backgrounds in The Gimp, Photoshop, etc.
If each custom view is only local to the window in which it is created, then the same viewpoint can not be replicated in multiple windows, and this task is too hard (unless there's a another maybe better way of doing this that I'm not aware of).


Pages: [1]