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 ... 90
ASL Scripts / Re: Spiral shapes: cave, cone
« on: April 08, 2016, 07:57:05 pm »
I used to use the UV data of the last X amount of points in order to pass the parameters of other shapes. This is no longer needed now that there are set attribute functions.

Finished Works and Works in Progress / Re: Doodling
« on: April 08, 2016, 11:26:08 am »
Random ugly bird modeled off an old creature design. Was going to make a tutorial out of it but then I got really lazy at the wings and went meh.

General Anim8or Forum / Re: free cool.. filter texture prog
« on: April 06, 2016, 07:12:39 pm »
Cool. I think I used a version of this program a long time ago, was cool generating seamless textures. Thanks for the heads up!

Raxx is that a modifier your using during the first 12 seconds of your modeling on the fox? 
That's a subdivision mesh. Select a regular mesh and go to Build->Convert to Subdivided

Cool. Do I get fries with the combo? And can I swap the drink with a milkshake? ;)

I finally got to try the topo tool in-depth along with mirrored modeling, it's really solid! A few hours straight with no crashes or weird mirroring issues, I almost entirely used just the topo tool for the below (unfinished) model.

A major bug to report: Can no longer select faces on subdivision meshes. There was also a time when the mirrored mesh went asymmetrical I think when rotating some points, but I haven't been able to replicate it.

Anim8or v0.98 Discussion Forum / Re: Feature Request Thread
« on: March 24, 2016, 03:10:06 am »
Hit 'o' for object space/coordinates.

Interestingly, object space doesn't match up directly with the bone axes. However I prefer the trackball object space version since it's not as confusing, which reinforces my opinion that the LMB/MMB/RMB X/Y/Z deal isn't necessary anymore.

Anim8or v0.98 Discussion Forum / Re: Feature Request Thread
« on: March 24, 2016, 12:13:31 am »
'Screen-space rotate bones' can already be done with trackball, applying that also to the mouse buttons would badly reduce the mobility of the bones.-1

I'm not entirely sure what you mean. The only way that local manipulation (the way it currently is) trumps the far more intuitive screen space manipulation is when doing purely mechanical animations that need precision along a single axis, or when doing minor adjustments like rotating around the bone's Y axis. Even then, it's easier to use the widget than to use the mouse buttons, so basically there's no point in having the LMB/MMB/RMB X/Y/Z mechanic.

Note: I updated my previous post to further detail what I meant.

Anim8or v0.98 Discussion Forum / Re: Feature Request Thread
« on: March 23, 2016, 04:26:16 pm »
A few more requests to stack on. Some of these have probably already been requested before:

Slide Edges and Multiple Elements
Let the slide tool slide edges. Basically clicking and dragging on an edge slides the edge in the direction of movement along its adjacent edges. Clicking and dragging on multiple connected edges slides the entire set. Clicking and dragging on multiple points does a best guess sliding action.

Edge Loop Manipulation
Let holding shift automatically highlight edge loops (the same way they're detected using q). This feature can be put in nearly all the point edit tools except the topo tool unless the topo tool shift/dissolve operation is moved to a different button.

Face Loop Manipulation
If highlighting faces, basically do the same as above except with faces. How to do this: If shift is pressed, it'll highlight the faces between the quad ring (same detection as Q) of the closest edge of that face. The below video shows what I mean:

Pretend that the yellow selected faces are the areas that get highlighted when shift is held down.

Axis-Restricted Bone Creation
Currently disabling axes have no effect on bone creation. If I wanted to create a bone sticking straight up, the only choice I have is to enable grid snap.

Object Space
Allow object space manipulations to apply to bones. This way (as an example of use), if the Y axis is solely enabled and it's set to local, then creating a bone will create it along the Y axis of and Y-rotated to the parent bone, rather than the global Y axis. I know this can be done with fast select disabled, but it's a bit of an odd thing having to disable it to get that behavior. In fact, it seems if fast select is disabled while trying to create bones, it doesn't always work.

Screen-space rotate bones
In sequence/scene editors, I feel that when you have Edit Bones active and left-click drag on a bone (in fast select or when dragging outside the circle), it should rotate it along the screen space instead of the X axis. In other words, ditch the LMB/MMB/RMB X/Y/Z relationship with manipulation since it's inherently less intuitive than rotating in screen space. I say this because there are now rotation widgets so that when in Object Space you can rotate according to the old relationship anyway.

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.

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