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 - Raxx

Pages: 1 2 3 [4] 5 6 ... 89
Anim8or v0.98 Discussion Forum / Re: Feature Request Thread
« on: March 17, 2016, 08:19:07 pm »
Since it was brought to my attention in another post, I thought I'd bring up a discussion about scripting in the scene editor. More specifically, controller scripting. Currently it's entirely too restricted. Aside from making basic turntable animations, there's not much incentive to use controller scripts in the scene editor simply because it's mostly crippled. I can't count the number of hours I wasted trying to implement physics and IK and animated textures, only to fail on the first two multiple times and only succeed on getting animated textures done with limited success.

"Controllers" should be changed to a different name, in the context of this post. Instead, it'd be better to call them "properties". Properties that can be animated. A script can have properties but properties can't have scripts. These properties can be built-in, like position or orientation, or they can be custom-made.

Controller Scripting
Any element in the scene should be able to have a script attached to it. Do away with separate controller scripts for position, orientation, scale, etc. Instead, make it so that one or more "script" elements can be added to any element (aside from other scripts) in the scene. Double clicking this script element on the timetrack or graph editor pops up a dialog box with the script in a textarea and on/off keyable options.

For example. Object01 has a script attached to it. That script can read and/or edit its parent (Object01) and its parent's position, orientation, scale, visibility, etc. It can also look up and edit any other element's properties. It can look up its own self as well.

I recommend creating an "element" Anim8or data type similar to the object editor's "shape" data type, in that it can access all internal properties and lookup custom properties for any element in the scene.

Hierarchy, order of operations
This is a big one. A script attached to an element must be able to read and write the data for any and all scene elements, including children, parents, and siblings. Do away with babysitting using strict circular dependency rules. It just hampers the user. Instead use an order of operations and otherwise catch/halt infinite loops (with an option to set a directive to not catch/halt loops for that script).

Order of operations is a set of rules the scene follows regarding animation. With this, there becomes no reason to worry about circular dependency.

There are two types of animation. Keyed animation and scripted. All scripts get executed first in a specific hierarchy. Then the keyed animation gets run on top of that (additive).

The hierarchy for script execution is simple. It executes scripts in order of highest in the parent/child relationship to lowest (depth-first search with optional customization on which child gets hit first, basically). So in the following image, let's assume these are all scripts below the scene element.

Horizontally, in which order? If not set then it'll run in the order that Anim8or reads them. Otherwise, if a directive is set (like #index(1);), it'll run it in the order that's set in the scripts. Now let's assume "a" is set to run first. "a" might read and modify properties of an element. "b" might read and modify the same properties as well. So "a" reads and modifies them first. Then "b" reads the properties (that have been changed by "a") and modifies it further.

What about "d" and "e"? If they also change the same properties, then it'd be done in this order: "a", "d", "e", "b". In fact, the order of this entire operation would be "a", "d", "e", "b", "f", "g", "c", "m", "n".

Previous-frame data (or, passing variables between frames)
There should be ways to lookup previous frames' data. The current problem with doing anything physics-like is that there's no way to change, say, acceleration without using tricks. I can give an initial trajectory with direction and acceleration, but beyond a nice looking arc there's really not much else to do. I believe ENSONIQ5 could probably give a nice long rant about this issue ;)

Somewhat related. Currently, a figure can't be expanded in the timetrack to show all its bones in its hierarchy. All controllers/parameters are listed on one level. Firstly, this needs to be changed so that it properly shows its relations in the timetrack as if it were a stack of elements in the scene editor. Secondly, scripts and elements should be able to be attached to bones and/or objects that are attached to bones. Basically, an individual bone should be treated like an element.

An element should be expandable with visual differentiation between its properties (position, orientation, scale, etc) and its child elements. Italics or something for the properties. When keyframing a bone, it should have the same "position", "orientation", "scale" point3 keys that elements have. No more flat-listing a long series of "boneXX-X", "boneXX-Y", "boneXX-Z" immediately under the figure. A simple "orientation" parameter under each bone would be much, much better. And yes, scale should be a point3 value so that non-uniform scale becomes possible.

I already mentioned in other posts how important translation and scaling of bones is in animation, so I won't go there.

Not really the place to ask. How-to questions belong in the General Anim8or Forum unless it's specific to a new feature in the development release.

However, to answer your question, there's no way to currently do so. Anim8or is too simplistic in its circular dependency restrictions, thus preventing one bone from copying the rotations of another bone in the same figure.

Manually keying the two eye bones is the easiest way, asides from the morph targets approach of creating the eye movement of both eyes as morph targets and animating them that way. A potentially harder way is to have the eyeballs as separate objects in the scene and set them to "face target" a target so that they automatically rotate and follow a target...but then you have to try and keep the eyeballs in the head while you're animating the body.

Maybe other users have found easier solutions.

Anim8or v0.98 Discussion Forum / Re: Feature Request Thread
« on: March 17, 2016, 05:48:56 pm »
Small request: Make it so that the axis buttons are triggered the same way as the p/e/f buttons. LMB enables only that axis and disables the others, RMB toggles by add/subtracting from the current set.

What you see on the screen isn't necessarily how it's picked since I use separate passes for point, edge and face picking, all using Anim8or's software pipeline. Just because only part of a pixel is visible it doesn't mean that it picks any differently than if it were all visible.  When picking is enabled for multiple things selecting a face at a steep angle will be closer to the user that the point so even if the point is within range the face could be chosen instead since the part of the face that the mouse is over is closer to the user.  This doesn't happen if face selection isn't on, of course, like for the topo tool.

BTW does the change in color of the topo tool help?  I thought it would since you can tell when you're over a valid end point.

Yes, I'd observed that it's not necessarily the same, however in a lot of cases it still holds true that the picking for points is blocked in in the same areas that it's hidden (blocked by the edge/face that's closer to the user than the point). This shouldn't be happening! In the below video, #1 is a case in which it's not highlighting edges even though it's clearly hovering over them at the endpoint. #2 is the case that I've been describing, in which it seems like the edges or faces being rendered on top of the point are preventing the point from being highlighted.

Changing the color does help, though the color doesn't differentiate between whether it's connecting to an edge or connecting to a point. How about this:
  • Not hovering over any element: Yellow dashed line with no end point under mouse.
  • Hovering over edge: Orange dashed line and orange endpoint
  • Hovering over point: Orange dashed line and yellow endpoint
  • Using Ctrl to make a new edge in mid-air: Yellow dashed line and yellow endpoint
Or something like that.

Thought the point picking was improved too but I think it was just me >:(
Yes, a bit of radius tweaking would help a lot. At this time component picking is only remotely comfortable at a low monitor resolution.

Glad I'm not the only one. Faces can partially cover the point based on the angle of the faces and the camera angle, like seen in the image below (I imagine this might be the result of recent changes regarding editing hidden elements). The majority of points become partially covered regardless of the camera angle. In this example, the orange point is a highlighted point on a mesh. The red outline is an approximation of where the mouse has to be in order to highlight the point. Obviously, it's ignoring a large portion of the point!

This is why it's so frustrating, because not only does mousing over the center of the point not work a large part of the time, but the location around the point that is ignored is random based on what's partially hidden or not. The topo tool is supposed to allow for a rapid amount of edits in a short amount of time, but every other point is where I get stuck wasting seconds trying to get it to highlight in order to edit it. Also, if I start a cut and hover over an ignored portion of the point and that area just happens to be on an edge, sometimes it's so close to the point I have no way of knowing that I actually cut the edge and not the point! This makes me have no confidence any time I make a cut connecting to a pre-existing point, and I waste further time verifying it. I end up having no desire to model as the picking frustrations build up.

I'll quote what I mentioned a little while ago:
Picking Radius: This applies to the RMB-move for the topo knife and the move tool in fast select mode. The picking radius for points is much too small for comfort. In XSI (Blender and Wings3D have advanced picking as well), it begins picking the closest p/e/f at 80 pixels. Points get absolute priority (this is important!) when the mouse is around 12 pixels away from it. Edges get next priority over faces, at about 12 pixels distance as well. I know I've been harping about this before, but it makes for an extremely smooth and natural experience when modeling and I can't think of any reason not to have this level of picking. When testing this and previous builds with the topo tool, it's been something of a sore point for me.

Major changes for build 1227:
Fix #098-079: Cut Faces Can Crash.
Fix #098-082: Double clicking on a controller name in the Track Window doesn't show the Key Value Editor when the controller is a script.
Fix #098-083: Topo tool issues with Mirrored Meshes.
Fix #098-084: Screen doesn't update while rendering a movie.
Dialog Box Location: Locate dialogs within the current focus window.
Fix missing bounding box: on subdivision shapes when Subdivision Edges aren't shown.
Topo Tool: Fix several mirrored mesh issues.  Should be fairly solid now.
Topo Tool: Change color from yellow to orange when over a valid target to make it easier to know when this happens.
Edge Extrude: Update to obey Fast-Select rules.
Larger Icons: Added an option for larger toolbar buttons in the ConfigureUI dialog. to help tablet and touch screen users.  No larger icons yet - making them is a lot of work!
Color scheme: Update screen immediately when user changes scheme instead of on the next run.
Remove UpdateWindow() call: Under Win 10 when to main window is on a second monitor this seems to cause a crash before the window is shown.

Steve, many thanks for the updates! The topo tool updates definitely make it a much more solid experience. [edit]Thought the point picking was improved too but I think it was just me >:([/edit]

Double clicking the controller name works and is a big help.

I like the larger buttons. The icons may not be bigger but I like the roomier feel to it even on the PC. I kind of prefer it that way.

I can confirm that the UpdateWindow() fix solves the crashing issue I reported.

Anim8or v0.98 Discussion Forum / Re: Feature Request Thread
« on: March 12, 2016, 01:35:58 pm »
Some other ASL requests that have weighed heavily on my mind for some time now. Usually after banging my head on the wall, I'd type up a big ol' write up of my grievances, then by the time my frustration's died down I'd realize it's more rant than request and delete it. This time it's a good night's sleep after, so hopefully I can articulate a good post :P

Here's an example of what I wrote last night trying to get a small matter accomplished:
ASL Snippet
  2. if($he_sharedPoints[$he_Point[$curHEString2[$j]]].x != -1.0)
  3. {
  4. if ($he_Pair1[$he_EdgeIndex[$fToInt($he_sharedPoints[$he_Point[$curHEString2[$j]]].x)]] != -1)
  5. $feature_neighbors[$he_Pair1[$he_EdgeIndex[$fToInt($he_sharedPoints[$he_Point[$curHEString2[$j]]].x)]]] = 1;
  7. if ($he_Pair2[$he_EdgeIndex[$fToInt($he_sharedPoints[$he_Point[$curHEString2[$j]]].x)]] != -1)
  8. $feature_neighbors[$he_Pair2[$he_EdgeIndex[$fToInt($he_sharedPoints[$he_Point[$curHEString2[$j]]].x)]]] = 1;
  10. if($he_sharedPoints[$he_Point[$curHEString2[$j]]].y != -1.0)
  11. {
  12. if ($he_Pair1[$he_EdgeIndex[$fToInt($he_sharedPoints[$he_Point[$curHEString2[$j]]].y)]] != -1)
  13. $feature_neighbors[$he_Pair1[$he_EdgeIndex[$fToInt($he_sharedPoints[$he_Point[$curHEString2[$j]]].y)]]] = 1;
  15. if ($he_Pair2[$he_EdgeIndex[$fToInt($he_sharedPoints[$he_Point[$curHEString2[$j]]].y)]] != -1)
  16. $feature_neighbors[$he_Pair2[$he_EdgeIndex[$fToInt($he_sharedPoints[$he_Point[$curHEString2[$j]]].y)]]] = 1;
  18. if($he_sharedPoints[$he_Point[$curHEString2[$j]]].z != -1.0)
  19. {
  20. if ($he_Pair1[$he_EdgeIndex[$fToInt($he_sharedPoints[$he_Point[$curHEString2[$j]]].z)]] != -1)
  21. $feature_neighbors[$he_Pair1[$he_EdgeIndex[$fToInt($he_sharedPoints[$he_Point[$curHEString2[$j]]].z)]]] = 1;
  23. if ($he_Pair2[$he_EdgeIndex[$fToInt($he_sharedPoints[$he_Point[$curHEString2[$j]]].z)]] != -1)
  24. $feature_neighbors[$he_Pair2[$he_EdgeIndex[$fToInt($he_sharedPoints[$he_Point[$curHEString2[$j]]].z)]]] = 1;
  26. if($he_sharedPoints[$he_Point[$curHEString2[$j]]].w != -1.0)
  27. {
  28. if ($he_Pair1[$he_EdgeIndex[$fToInt($he_sharedPoints[$he_Point[$curHEString2[$j]]].w)]] != -1)
  29. $feature_neighbors[$he_Pair1[$he_EdgeIndex[$fToInt($he_sharedPoints[$he_Point[$curHEString2[$j]]].w)]]] = 1;
  31. if ($he_Pair2[$he_EdgeIndex[$fToInt($he_sharedPoints[$he_Point[$curHEString2[$j]]].w)]] != -1)
  32. $feature_neighbors[$he_Pair2[$he_EdgeIndex[$fToInt($he_sharedPoints[$he_Point[$curHEString2[$j]]].w)]]] = 1;
  33. }
  34. }
  35. }
  36. }

I built those lines slowly while it made sense, but now looking at it it'll take me a few minutes to actually figure out what's linking to where, and I'm the one that wrote it! There's also no simpler method that I could think of. To help myself out, I write nearly as many comments as lines of code, but still I would hate life if I had to come back to this code even a week later when it's not fresh in my mind. It's also only a small portion of the entire script, which I'm not going to share because it'd cause nightmares to all present.

Arrays in functions: Passing arrays as parameters, and returning arrays from functions. Without this, I have to create arrays beforehand outside of the $main function so that the function can fill in arrays. This is extremely counter intuitive, and hard to organize when multiple functions need to output arrays multiple times for the main function or between other functions.

Recursion: It's incredibly difficult converting algorithms that require recursion into non-recursive functions. A lot of 3D-related algorithms rely on binary trees/linked lists, and making non-recursive traversal functions (especially without custom data structures as requested below) is a stack of headaches rolled into one. I have to create stacks and counters and do convoluted orders of operations to try and cope with it.

Custom data structures: I'm not asking for anything super complicated like full-featured object definition. I just want to be able to make my own data structure out of the data types already available. I could make linked lists without having to create a dozen arrays with weird convoluted relationships to each other passing indices as values to be indices for other arrays.

An example of how it'd look creating a new data structure could be something like:
Code: [Select]
!datatype half-edge (int id, int next, int prev, point3 point, int edgeindex, int opposite);! indicates it's compiled first before the rest of the script, and needs to be asserted outside of the $main function. Then to use the half-edge data type, declare it like any other variable:
Code: [Select]
half-edge $HE[1];To assign the values, two methods can be used.
Code: [Select]
$HE[0] = (0, 1, -1, (0,0,0), 85, 23); // Can also have variables passed as values
$HE[0].id = 0;
$HE[0].next = 1;
$HE[0].prev= -1;
$HE[0].point = (0,0,0);
$HE[0].edgeindex = 85;
$HE[0].opposite = 23;
It'd be useful to also be able to use custom data types within custom data types. For example a custom data type vertex:
Code: [Select]
!datatype vertex (int id, point3 loc);
vertex $v;
Can be used in half-edge:
Code: [Select]
!datatype half-edge (int id, int next, int prev, vertex point, int edgeindex, int opposite);Writing to it can look like this:
Code: [Select]
$HE[0] = 1;
$HE[0].point.loc =(0,0,0);

Pointers: Same * and & operators/behavior as in C++, would aid the use of custom data types, binary trees, linked lists...

Matrices: I'm already fairly deficient when it comes to 3D math, so I won't go into much detail here. Some means to make matrices Nxn size, and functions to perform operations on these.

Type conversion. toInt and toFloat functions for strings (like toInt("123.45") returns 123 and toFloat("123.45") returns 123.45. I made my own functions in ASL to do this but it'd obviously be much more efficient if this was built-in.

toString for ints and floats (yes there's PrintToString, this would basically be a simplified macro of that).

Automatic type conversion between ints and floats (for example $array[1.466] automatically converts down to $array[1]).

Adding two multiple strings appends them together in the order they appear. Example: $var = "Hello" + " " + "there" + ", " + "everyone!"; is a lot simpler than doing $var = PrintToString("%s%s%s%s%s", "Hello", " ", "there", ", ", "everyone!");

[Edit] Obviously, most of these requests are things found in regular programming languages. If instead an API/dll extension system was being worked on, I really couldn't care less about these requests and just wait for that to save myself all the headache :P

Anim8or v0.98 Discussion Forum / Re: Feature Request Thread
« on: March 11, 2016, 11:21:41 am »
Another ASL-related request: Status Bar and Progress Bar output.

There's not much (read:nothing) in the way of GUI options for ASL. What I'd give for the ability to create custom dialog boxes in ASL...sigh. Anyway, something that *should* be simpler to implement is the ability to print to the status bar, and the ability to start/update/end the progress bar (same progress bar as what's shown when rendering). Yes, there's the console, but it's not a very user friendly method of informing the user about things. I've made progress bars in the console before but ugh, it's such a ghastly way of doing things.

Status bar text updates have lots of uses. Such as informing the start/stop of a script, latest warnings, error messages, debugging, etc. Same as the console but nicer. It could use the same .open/print/close functions as the console, but instead of "$console" it's "$statusbar".

Progress bar updates are useful in object editor scripts that take a long time to generate. Like my phur plugin, some of my export plugins, or some of the other mesh plugins others have done. The function to start/stop/update the progress bar could be as simple as SetProgressBar(#). Where it's a float value between 0 and 1 with 0 being off and 1 being full. Automatically sets to 0 upon script termination in case the user forgets to write it in.

And a side note, it'd be nice if the progress bar made use of the Windows task bar progress bar indicator ( So that when rendering or while a script is running, the user can glance at the task bar and easily tell if it's still going or not. This is a Win7+ feature but it should be relatively simple to do an OS version check for it.

This is a future-friendly ASL feature request since the status bar and progress bar are key parts of the Anim8or interface. Even if more GUI features are implemented in ASL, these two elements will remain relevant.

PS...Personally I'd love it if the console was embedded in the bottom of Anim8or's interface (expandable above the status bar). Oh, and custom coloring the text...

Anim8or v0.98 Discussion Forum / Re: Bug/Issue: Normals (ASL)
« on: March 11, 2016, 10:48:11 am »
Nicke, thanks for taking the time to show that the manual way produces more consistent results. I tried yours and a few other surface normal algorithms and got mostly the same consistency.

Steve, thanks for the detailed explanation as to why Anim8or's results won't necessarily be consistent.

For now, I'll just go with Newell's method of calculating surface normals, which provides good enough results (takes only ~1 second to calculate ~197,000 faces). If a system time method gets put in, I'll pick whichever I determine to be the fastest method. :)

Anim8or v0.98 Discussion Forum / Re: Feature Request Thread
« on: March 09, 2016, 09:17:07 pm »
That's true, but in my opinion these types of restrictions should be in the hands of the users, that it should be up to the coder whether their script should have true inconsistent/unique features or not, and up to the end user whether or not to use the script and/or unique features. Obviously in Anim8or inconsistencies aren't that useful, but you never know, something outside the box could be done with it that'd surprise us.

Anyway, a memo in the ASL spec about the usefulness of the Xrand() functions vs timestamps would help alleviate the issue :)

Anim8or v0.98 Discussion Forum / Re: Feature Request Thread
« on: March 09, 2016, 05:08:45 pm »
A small but important ASL request: A system time function to retrieve the timestamp and maybe a date function to accompany it. There are many obvious uses for this (evaluating script performance, timing out functions, timers, saving files with date, etc.) and I've always wondered why it hasn't been implemented.

Anim8or v0.98 Discussion Forum / Bug/Issue: Normals (ASL)
« on: March 07, 2016, 02:15:49 am »
I'm posting here since this seems like a bug to me. I'm working on a new set of scripts and part of it detects the sharpness/creases of edges in the geometry. I'm doing this by measuring the dot product of the normals of the two faces connected to an edge to get its sharpness (1 is flat, 0 is not).

To get the face normals, I'm calculating the mean of all the normals of the points in a face (ie (normal1 + normal2 + normal3)/3). I'm getting these normals using GetNormal(GetFaceNormalIndex()), rather than calculating the geometric normal manually. I'd rather not go through the hassle of triangulating and math-ing and combining for each face since it's more work, and more convoluted since I have to work with mesh data not tridata.

The issue is that I have a symmetrical mesh, and at a lot of locations a face on one side comes up with different normals than the corresponding face on the other side. I get why this can happen for n+3 sided faces, but it's also happening for triangles! And yet when I show normals in the Options->Debug menu, the triangles' normals look exactly symmetrical when the ASL version is not. This leads me to believe that there is some sort of lack of precision going on or something. My script needs precision!

So here I am reporting it. I hope it can be fixed if it's not an error on my part. Below and attached are examples that I hacked together to show what I mean.

ASL Snippet
  1. file $c;
  2. shape $s, $childShapes[0];
  3. int $i, $j, $k;
  4. float $numSides;
  5. point3 $faceNormal;
  7. $"$console", "w");
  9. project.curObject.GetShapes($childShapes);
  11. for $i = 0 to $childShapes.size - 1 do
  12. {
  13. if($childShapes[$i].GetKind() == SHAPE_KIND_MESH)
  14. {
  15. $s = $childShapes[$i];
  17. for $j = 0 to $s.GetNumFaces() - 1 do
  18. {
  19. if ($s.GetFaceSelected($j) == 1)
  20. {
  21. $faceNormal = $s.GetNormal($s.GetFaceNormalIndex($j, 0));
  22. $numSides = $s.GetNumSides($j);
  24. for $k = 1 to $numSides - 1 do
  25. {
  26. $faceNormal = $faceNormal + $s.GetNormal($s.GetFaceNormalIndex($j, $k));
  27. }
  29. $faceNormal = normalize(($faceNormal.x/$numSides, $faceNormal.y/$numSides, $faceNormal.z/$numSides));
  31. $c.print("\nFace %d has normals (%.3f, %.3f, %.3f)\n", $j, $faceNormal);
  32. }
  33. }
  34. }
  35. }
  37. $c.close();

The above script lets you select faces, so that when you run it it'll print in the console what the face normal is for each of the faces.

A bug I found: selected subdivision meshes no longer have bounding boxes when "Show Subdivision Edges" is unticked in Configure->GUI

Anim8or v0.98 Discussion Forum / Re: Feature Request Thread
« on: March 04, 2016, 06:11:06 pm »
This concept, or a very similar one, is called Instancing in OpenGL and D3D. At first glance it may seem simple, but there are a lot of nuances. If you allow editing of the per face properties in an instance (materials, texture coordinates, etc.), updating then when the geometry of the base shape changes is very complex. Vertex, edge, face, normal, tex-coord numbers often change throughout the mesh when just one small part is edited. This is the same, fundamental complexity with mirrored meshes.

What would be fairly easy to support: position, orientation, scale, materials (substituting different ones for the ones in the base model), and all global properties shown in the Properties editors such as subdivision level, parametric parameters, layer, smooth angle, etc.
As I described in the post above, clones shouldn't be editable meshes unless they're converted into their own independant shapes (and thus not being clones/instances anymore), so there wouldn't be any editing of materials (besides the base material), texture coords, or anything else p/e/f on these active instances. Thus this complexity is avoided. So yes, what you described as fairly easy to support is what I described, and therefore useful enough ;)

Anim8or v0.98 Discussion Forum / Re: Feature Request Thread
« on: March 04, 2016, 10:35:00 am »
I know that it's about time to focus on the other editors, but here's a feature for the object editor that I would find extremely useful, and I'm sure others would as well.

Clone Mesh
A clone is a duplicate of a mesh shape. It's basically just a copy. If the original gets edited, the copy updates to that version of the original immediately. A clone can be transformed (moved, scaled, rotated). A clone can have its own unique parameters (it copies the original's when the clone is first created, including the original's transform). For example, if it's a mesh, then the smooth angle can be customized. If it's a subdivision mesh, then the working/final divisions and smooth angle can be customized. And of course the layer. Also, clones can have unique materials assigned to them (only the base material--if specific faces have assigned materials, those remain the same as the original's). It's only the mesh structure that remains exactly the same as the original.

The mesh structure of a clone can't be edited. Therefore it'd be useful that if it's a subdivision mesh, that it doesn't show the control mesh whatsoever in any of the shading modes (unless give it an option in its dialog box?). However, a clone can be converted to mesh to "unclone" it.

There are a lot of uses for this. The user can make a clone of the mesh and scale it -1, creating a mirror and then be able to do mirrored modeling while being able to see the changes on the other side immediately without the control mesh getting in the way if it's a subdivision mesh. Things like eyeballs, mirrored accessories and clothing, etc., becomes easy to do. If an object needs lots of copies of a mesh, like for example a metal chain, these can all be cloned and then when editing the original chain link, all the other chain links become updated immediately as well. It also greatly reduces file sizes for things like this.

Copying and pasting a clone results in a clone with the same parameters as the copied clone. Deleting the original mesh deletes the clone (maybe autodetect if there are clones of that mesh, and then ask if the user wants to delete the clones or not. If not, then the clones get converted to meshes).

As for morph targets, I think it'd be interesting if it reflected the original's morphs as well when setting and animating, with an option in its dialog box to not copy it.

This isn't an original idea of mine. It's something I used a lot in XSI when I used it for modeling. I think it'd be somewhat easy (compared to the *ahem* mirrored modeling feature) to implement as well, since it's just running a copy method every time a cloned mesh is modified, and in figure/sequence/scene editors it can be treated like a transformed instance of the original mesh when building the list of geometry.

Pages: 1 2 3 [4] 5 6 ... 89