February 26, 2011
I’d love to build an app, which basically only manipulated data/prototyped data. Basically you would import mesh data/nulls/shapes etc (possible create base types: nulls etc) and rig/control them through a nodal work flow. I.e Max’s script controller in encapsulated nodes.
- Import models, objects, point cloud data – possibly create nulls etc
- Transforming wouldn’t need specific connections (i.e a transform handle node in Houdini)
- Parenting would be done in the viewport and possible show up in a schematic type view
- Each object would appear as a node or cluster (point cloud etc) – inputs/outputs being position/rotation/scale/xyz
- Local/world space could be used as input output
- Nodes could be grouped/compacted into digital asset/compound like object. i.e you could build an IK/FK compound
- Vector operations on the models etc
- add, subtract, multiply, inverse, transpose, dot, cross, power,exp, factorial, abs,ceil,floor,mod,arcLength,tangent, binomial
- sin,tan,cos, acos
Case Types E.g.
- If/else/elseIf/finally/then, continue/while, try/catch/throw/break
Value Types E.g.
- integer,float,point2,point3,point4, matrix n*n
- custom variables
- pi, e, etc
- Importing data – simple xml data, open customizable
- Animation support?
- Skinning support?
- UV support? Masks?
- Reference space – At one level we want to work on the object itself, at another we want to work on its vertices/knots etc. Operators need to handle both levels of abstraction.
- Is this just for prototyping? (i like this) – need XML to export data to be readable in a standard web browser for translating in final app max/maya etc..
Maybe I’m just describing Houdini/ICE, but this would be purely for visualizing/manipulating object relative data – custom subsystems e.g. iksolvers, rendering, animation layers, custom constraints etc etc..
More on XSI Compounds here: http://softimage.wiki.softimage.com/xsidocs/ICE_compounds_OverviewofICECompounds.htm
February 21, 2011
I’ve been looking into Bungies approach to scene traversal, and thinking about how it would work for max. I look at it from time to time – but have recently taken a greater interest into as I’m solidifying a lot of my methods and need a way to traverse there hierarchies.
Essentially (from what i understand), they have metadata nodes which contain standard attributes: type, version etc, children which reference other metadata nodes attached and any additional custom attributes which reference nodes that are attached. Nodes are attached via a .metaParent attribute to allow recursion up to the ‘meta parent’
Im assuming both meta nodes, and nodes themselves use the ‘.metaParent’ attribute to recurse up until a ‘meta root’ is found, and if not how does a meta node find its parent?
In max, i think this would mean single or multiple attributes on the same or different objects could reference each other using the .metaParent’ and ‘type’ attribute.
Where a metaNode or Tag as i like to call it, contains custom attributes pointing to the nodes attached for a specific system such as ik, it essentially becomes a ‘Hub’ with the ability to inherit functions of the tags connected to it.
Would this make the ‘meta children’ attribute redundant though?
February 13, 2011
Maybe I was a little hasty. Crucially when it comes to keys, animators need to know the reference a value exists in – and that, it shouldn’t change. For example if I animate a guy jumping from one platform to another – the curves of the jumping, moving from and to the platforms shouldn’t pop erratically to allow its reference space to change. More over the the space the values are relative to should be transformed.
The offset is a great mechanism for retaining space – it wouldn’t be a good mechanism for FK/IK systems because your trying to force the IK/FK into its opposite – i.e you want its value to change. Can we form a rule here? When you want the value to change directly transform the object, when you want to retain the value transform the objects parent space.
You still need to allow this approach to be understood by the animator. The offset needs to be understandable, accessible and crucially clean-able!. Any system that transforms an object by an offset will encounter pops and hitches if the keys of the offset change, get moved or deleted. (Another reason to place them in there own area – attributes etc)
October 23, 2010
I think about rigging, frameworks, articulation etc a lot – in fact I think about it most days, fighting battles in my brain on how systems should work. The simplest, no the most elegant way to give an animator as much control without hiding them in layers of abstraction (something the current tools I work with, have a lot of issues with.)
Today its all about key ownership and whether TDs should interfere with them – with systems like fk/ik and space switching keys are essentially used for gluing the ‘state’ of each system together seamlessly. But I’m not sure if we should be be manipulating to support the mechanisms of the rig outright – i.e. for the rig to work.
I work with a lot of animators, who’ve come from all walks of life – the one thing I’ve learned over the years is to let them own there keys and not create them for them. I.e. they control the space, weight and mechanism of the rig. They tend to hate keys embedded on hidden controllers, deep within the graph or keys bundled in with mixed systems e.g a key automatically getting created for the transform of the fk/ik with another for the weight of the system.
It’s great as a technical demo i’m just not sure I should be making keys that are only there to allow a rigging mechanism to work. I’m actually learning towards openness in space switching as ik-fk does with separate controls for local, world and parent spaces.
I’d rather have an animation know exactly know how there rig works and take a extra time I think , than to make it seamless and embed hidden keys into the rig – that are hard to get at.
August 9, 2010
My girlfriend won 3rd place in the Applied Arts Magazine Scholarship – Pretty awesome seeing as she hasn’t even graduated yet!
July 29, 2010
When constructing heirachies do not use the ‘next child’ method of connection/visual display. More-over build the heirachy as one system and visualize its connections with another E.g.
With a hand do not build the hand as connection between the forearm and the hands first child. Rather construct the heirachy with connections between them I.e.
Elbow > Elbow To Wrist > Wrist > Wrist To Index Finger
This should be noted for all hierachal construction methods.
July 16, 2010
I’ve started learning Python (albeit slowly) and pretty much recommend any tech artist/animator/rigger to do so to! It’s awesome and the sheer number of libraries and packages using it is crazy:
Motionbuilder – http://en.wikipedia.org/wiki/Motionbuilder
Softimage – http://en.wikipedia.org/wiki/Autodesk_Softimage
Cinema 4d – http://www.py4d.com/
Lightwave – http://www.newtek.com/lightwave/core/techfaq.php
July 2, 2010
Going a little off-topic to let eveyone know my girlfriend won a national scholarship in graphic design!
Winner of the Applied Arts $1000 Scholarship
Mariya Karpenko, University of Alberta (Edmonton, AB)
Project: Luxury Soap Packaging
Instructor: Gabe Wong
You can find more info here:
And her website: www.mariyaKarpenko.wordpress.com
May 21, 2010
Don’t do this!
What you see is what you get – that is the rule you need to follow when it comes to getting and setting transforms. When an objects transform is actually an internal transform relative to an internal parent and not its physical one things get very complicated when trying to access them.
If at all possible (this applies to rigging too) when accessing data and there controls, don’t hide data/curves in other data/controls methods. Blending between IK-FK is a clearly defined system; you can see both systems and know when your blending between them.