#Bones Pro 1.5
9 messages in this thread
It is true that Bones Pro 1.5 has many benefits over version 1.0, but the
problem still remains that if you scale or rotate a bone after the hierarchy
has been set up you have to unlink, reset X form, relink in order to get the
correct deformation, otherwise Bones Pro goes wild with the object vertices.
Another problem is the amount of information that Bones Pro needs to store for
each object. I have 8 chromatids in an 3075 frame animation and it takes about
8 minutes to JUST save the data for each. That is over 88 minutes just trying
to save the data.
Also the project was 7M before but with the inclusion of the Bones Pro
data(which is stored in the actual project) the size increased to 19M, nearly
three times it's original size!
So my project file is way too large 19M, alot of instancing is used so that the
ACTUAL project size in memory when a rendering is started is over 80M(+800,000
faces). On a 64M Pentium 100Mhz it took over 50 minutes to render a single
frame due to the amount of disk swapping.
So I decided to go back to Bones Pro 1.0. So unassigning the Bones Pro AXP from
the chromatids, so they had no AXP and then saving the project should get rid
of all the information that Bones Pro saved in the file, right. No! The AXP
Info is still stored in the project file even if there is no AXP using it, so
my project file has over 12M of data that no IPAS is using.
How can you get rid of this unwanted information? I unassigned the Bones Pro
AXP, saved them only to a 3DS file using Save Selected, then deleted the
chromosomes in my project file, then saved the project file also. I then merged
the chromatids 3DS file into the main project. This got rid of the redundant
AXP data, but it was a workaround and I'm hoping someone else has a better
idea.
DaviD "Modify/Object Attributes/Spring clean" GouID
Hi David,
There is a command in Bones Pro 1.5 to clear the deformation information from
the bones main mesh object. In the main Bones Pro 1.5 interface click on CLEAR
button at the bottom of the screen. This will delete the data from the mesh.
David – Digimation
<<In the main Bones Pro 1.5 interface click on CLEAR button at the bottom of
the screen.>>
Make that a big Homer Simpson DOOOH! on my part. Thanks.
DaviD "push button punched me in the face" GouID
So you do actually reply to _some_ messages. <g> I'm still wondering about the
LenZFX problem I posted 3 days ago…. On another note why is it that LenZFX
will page to disk pretty much all the time? I've had instances where it says
I've use only 5Mb of 32Mb but have paged 8Mb. Any idea if this will be fixed?
Also – any idea on Lumina – I ordered it about 2 months ago and still haven't
seen anything more on it past your initial posts. Just wondering….
DM
>> I have 8 chromatids… <<
Wow! Thanks for the real life info re. BonesPro 1.5. I haven't been able to
use it as much as I'd like, so haven't seen these "features" <g> yet. You seem
to point out some real drawbacks w/ the program. I hope that they are
addressable and addressed soonly.
– Ernie Jackson, 73177,2354
11-Jul-1995 09:18:56 PDT
<<You seem to point out some real drawbacks w/ the program. I hope that they
are addressable and addressed soonly.>>
No, it was an error on my part regarding the storage of the AXP info in the
project. Though the bones scaling problem is still there and should be fixed.
DaviD "2 billion neurons with 1 million redundant AXP floating around" GouID
>>It is true that Bones Pro 1.5 has many benefits over version 1.0, but the
problem still remains that if you scale or rotate a bone after the hierarchy
has been set up you have to unlink, reset X form, relink in order to get the
correct deformation, otherwise Bones Pro goes wild with the object vertices.<<
DaviD,
I Haved used Bones Pro 1.5 in several character animations, (mainly Humanoid
and Hand Articulation and I find it to be a super program. 🙂
The main problem most people have with Bones Pro comes when they start creating
objects transformations at frame 0 (zero) in the KeyFramer.
Example: A single boned cylinder.
If you were to 2d scale the bone in one direction at frame zero and enter the
Bones interface, your mesh object would look fine at frame zero, but stretched
out on all following frames.
Reason:
When an object is created and modified in the 3D editor a transformation
matrix is established for the objects position, rotation, scaling, etc…any
changes made to this object at frame 0 (zero) in the keyframer will only
compound the matrix, unless you normalize it with the Reset XFORM command in
the 3D editor.
If you were to do a Keyinfo on the bone at frame 0 (zero) before the reset
xform command you would find that any scaling or rotational data is stored,
even though the object's changes are graphically reflected in the 3D editor.
After the reset xform all scaling and rotational data at frame zero will be to
set 0 (zero) or 1 (one), ie: normalized.
Because Bones Pro creates object transformation data starting at frame 0 (zero)
any un-normalized scaling and rotational data will be transfered to the mesh,
ie: Crazy Mesh want's a head start? 🙂
The only work around is to reset the xform (normalize at 0 zero) or start all
animations at frame 1 (one). The only problem with reseting the xform is
that the bones bounding box is also updated, resulting in hard to influence
vertices.
As far as the hierarchy goes the principle is the same, with the exception that
the child's movement is dependent on it's parent. The only advice I have for
jointed anitomical structures is "Nuckles are good". A nuckle or knee bone
will allow for a more controllable degree a rotation. If you happen to rotate
the knuckle bone at frame 0 zero or reset the nuckle bones xform to re-align
the objects local axis to the World coordinate system you can always set it's
influence to 0 zero and let the connecting bones take over.
I hope this information clears up some of the question about Bones Pro.
After being tormented with the same problem I thought I would share my research
into a possible cause.
If anything I have mentioned is wrong or misleading, I apologize.
Roy Baker.
Roy,
I don't know if there's anything wrong with your description but it sounds
right on to me, and very well stated.
Thanks, that's a keeper. 🙂
John
<<When an object is created and modified in the 3D editor a transformation
matrix is established for the objects position, rotation, scaling, etc…any
changes made to this object at frame 0 (zero) in the keyframer will only
compound the matrix, unless you normalize it with the Reset XFORM command in
the 3D editor.>>
Thats partially correct. The rotation and translation operations are stored in
the translation matrix for a 3D Editor object, while the scaling isn't. The
reason is that certain transformations performed in a given order mean that the
transformation matrix can't be inverted. If the matrix can't be inverted then
the object can't be repositioned and realigned to object coordinates ready for
the Keyframer. So the scaling is applied, like all other tranformations,
directly to the object vertices but it not stored for inverting later.
The problem only arises if you change the scale at frame 0 in the Keyframer.
There is no problem rotating a bone at the first frame. The reason is that
Bones Pro assumes that no scaling has been done on the first frame. This is an
adequate assumption since all objects when they initially come from the 3D
Editor have a scale of 1.0. The problem is that Bones Pro doesn't check to see
if in the Keyframer that the scale has changed for the first frame. Instead it
assumes it is always 1.0, when in fact it could be anything the user inputs.
This is why Reset X Form corrects the problem. By using Reset X Form the
transformation matrix is reset to identity and, most importantly, the scaling
shown at frame 0 is 1.0 in the Keyframer. The side effect is that you lose the
object's local orientation which sometimes means that boxes are no longer
aligned with their local axiis.
So when you set the scale to something other than 1.0 in the Keyframer(not in
the 3D Editor) Bones Pro goes batty. For instance if you set the scale to 2.0
at the first frame and don't do any other scaling for the rest of the
animation, after the first frame the object will be scaled twice as big. This
is because Bones Pro assumed the scale was 1.0 at frame 0, when in fact it was
2.0. So Bones Pro sees it like this…
Scale
Frame 0: 1.0
Frame 1: 2.0
…
When in fact it is…
Scale
Frame 0: 2.0
Frame 1: 2.0
…
The reason why Bones Pro scales up the boned mesh is that it thinks the bone
changed from a scaling of 1.0 to a scaling of 2.0 after frame 0, when in fact
it didn't change at all. What Bones Pro needs to do is look at frame 0,
determine what scale is used, rather than assuming 1.0, and then apply the
deformations during the animation RELATIVE to the initial scale. If the initial
scale is 2.0 then all further scales should be calculated relative to this
initial scale. So a scaling of a bone of 4.0 would cause a doubling in the size
of the mesh object, not quadrupling, while a scale of 2.0 wouldn't change the
mesh since this was the initial value.
I hope they fix this problem since you often have to do alot of changes to
bones in order to get it right and having to go through the unlink, Reset X
Form, link process everytime you rescale a bone in the Keyframer is a pain.
Especially when you have a lot of objects and a lot of frames!
<<Because Bones Pro creates object transformation data starting at frame 0
(zero) any un-normalized scaling and rotational data will be transfered to the
mesh>>
This is another reason why they it should work relative to the transformation
matrix at frame(0) rather than assuming that the scaling has been normalized.
<<After being tormented with the same problem I thought I would share my
research into a possible cause.>>
Thanks Roy, it always good to hear the same war stories from others.
DaviD "down in the trenches" GouID