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
Ongoing Anim8or Development / Re: Picking Rules
« on: March 23, 2016, 03:19:38 pm »
Steve, awesome! It's just about perfect now. Manipulating the elements feels very natural and things happen nearly always as I expect them to happen :)

They work very well. I noticed great improvement between v1229 and v1230.
When in fast select, with the move tool, if I select an edge and then drag one of its points, the whole edge will move. Is this expected? On the contrary, if I select a face, then drag one of its edges, the edge will be moved.

This is because selecting an edge also selects the edge's points. There may have already been a discussion about it already, but maybe it's time to revisit it: Should selecting an edge also select the points of the edge? I ran into Thanos's issue a few times before as well, having accidentally selected an edge instead of a point, and then when subsequently trying to move the point again it also moves the edge's other point. This forces me to have to undo the accidental manipulations (when in fast select mode), then deselect everything and try again.

With the new fast select and topo tools in place along with the new selection conversion when switching between p/e/f, I feel that selecting an edge should only select the edge and not its points. Afterall, if you switch to point mode, it automatically selects the points of the edge anyway.

Hey Steve,

1. There may be cases where the user wants to make a long string of cuts right next to points. The easiest way to do this is to disable points so that only edges can be cut. And of course, there may be instances where the user only wants to connect or manipulate points. How about, when the topo tool is selected it automatically enables the p/e modes/buttons if they're disabled, and then if the user wants to cut edges or points only, they can enable/disable whichever? By the way, currently if points are disabled and edges enabled, the topo tool doesn't highlight or work on edges when the mouse is on or near a point.
2. This is useful I suppose, more so than not. If the user wanted it to not be usable then they could either group it or layer lock it. I assumed it was supposed to work the other way since fast select doesn't work on elements when outline/points are disabled for that shading mode.

I've been thinking about this for a while now, but I think it would be far more useful if outline/point draw preferences could be set on a per-shape basis (other per-shape preferences would be nice as well, such as showing textures, materials, X-ray, etc). An option in the shape properties could be, "Override default viewing preferences", and when that is enabled then per-shape options could be selectable. Blender has this type of feature. Later if/when panels are implemented, per-shape viewing preferences would be a snap for the user to set.

Finished Works and Works in Progress / Re: Toy Airplane
« on: March 19, 2016, 03:50:26 pm »
Looks good. Probably would drop like a rock but throwing rocks is fun too ;)

Hey Steve, the mouse picking is great now! I think points could use a few more pixels in radius/priority over edges (still battling more than I like over edges when trying to move points), but other than that I'm very satisfied. Thanks for taking the time to improve it :)

I have a few bugs to report, there seems to be strange behavior between smooth shaded and flat shaded. May be related to nemyax's issues:
  • When "Smooth Outline" or "Flat Outline" is disabled, subdivision meshes still show the outline/control mesh.
  • When "Smooth Points" or "Flat Outline" is disabled, it still shows the points for meshes and subdivision meshes.
  • For the Topo tool, when "Smooth Points" or "Flat Points" is disabled and "Outline" is still enabled, then it still highlights points and when clicking to move them, it moves the edge and not the point. Basically, Topo tool ignores the shading UI preferences and manipulates elements regardless of if they're enabled/disabled/shown/hidden.
  • Interestingly, left-side manipulation no longer works correctly when "Outline" is disabled and moving points/edges via the topo tool. Of course, if the previous three issues are fixed then I think this'll become a non-issue.

I'd forgotten about that kind of linking via ASL.

I know I'm steering the topic shamelessly, but one of the things I was wanting to do when slex asked about it (and one of the examples for why I recently made a post about controller script changes), is to make a "lookAt" script for an arbitrary bone. This is a simple implementation with math of which many examples can be found online, but without the ability to get the position and orientation of a bone, it's nearly impossible to make a lookAt script (or an IK script). Also, things would be simplified if it was just a simple "orientation" parameter rather than separated x/y/z parameters.

Coupled with those changes,

...scene mode in Anim8or would be greatly improved if that script could be implemented and used on gui in some next development built, so the bone/s could be controlled with the target directly- the same way as the object,camera or light can...

If a few enhancements to interfacing between the user and scripts, such as being able to load scene scripts from the scripts directory as script elements (selectable in a scripts menu), and allowing scripts to set parameters the same way parametric shapes are done (in a dialog box via the GUI), with these parameters being keyable, then lookAt, IK, particles, physics, etc can be implemented via scripts in a user-friendly way. Some of these scripts can, if useful enough, be packaged with Anim8or internally and become an integral part of the animation experience.

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

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