New animation
-
well ive a basic idea of how it does work…. i cant go into details as i never did it before and dont have the time to do tests atm
but from what i see the animations are pretty simple
via UTF you can definy which objects should interact
parent = root
child = component
for every wing you have 2 nodes which describe their starting state and the end state
so in the end you need to create a ship with 2 components and 4 animation nodesanimations are being run in a simple way by setting different coodinates describing which “path” the animation should go
to draw a simple picture of how it does/might work:
take 2 needles… stick them in a piece of wood… connect them with a cord… and now take one needle and stick it into a different place on the wood
et voila an animation -> the cord was your moving component (wing)hope you get the picture… thats how animations work
simple, effective, not that much time consuming, a bit primitive (imho) -
First off you need to add a Joint to the CMP, no Joint = no animation, you then need to attach it to it’s “Parent” and assign the “Child”, this is the component in the CMP you want to animate, yes we are talking multiple component CMPs something most of you don’t want to know about. After that you have to get the Joints orientation right, then set it’s rotation coordinates, this sets the plane that joint will work in, then you have to set how far the joint will “open” during the animation.
None of this can be done in Milkshape as the CMP exporter doesn’t export joints, so your left with UTF_Edit, I think v3 will allow you to edit the rev & pris data nodes. This leaves you with 2 nodes still to add, they are the “header” & “frames”, this is where custom animations fall flat, as I have no idea how to replicate the data in these nodes, I know roughly whats in them, just not how their coded. Frames is just that “frames”, a bit like frames in a movie, for a smoothish animation you need 25 frames for each second of the animation, the “header” is the instuctions on how to join it all together.
This is the rev data for br_elite, the “origin” is the location on the model that the joint is attached to, the “Rotation Matrix” is how you set the rotation coordinates, don’t ask how to work that out as it was a lot of trial & error on my part (I suck at maths), “Axis Rotate” is the orientation of the joint, and “Angle(Radians)” is how far the joint “opens”.PS that’s v4 of UTF_Edit, I think it’s still classed as a beta, meaning I doubt if it’s publicly available for general use yet, :-[ sorry for teasing everyone with it
-
Good work guys, I hope you can find a way to unlock animations,
And I also have that version of the UTF editor,
Or I did anyway >.< -
-
let me guess ::) you copied the nodes from the crusader and put them into the defender, easy enough to do, but still leaves you with finding a trigger to use it properly rather than replacing the baydoor animation.
ok you meen it is easy?
copy the crusader ani to defender and test it!
It wont workit´s more than copy&paste, but its easy
and later i´ll test to make it with a hotkey, but it have timePS: of curse i have copied the nodes of the crusader and edit tham for Defender
-
;D Did the same thing back in February with the rheinland battleships baydoor animation, I transfered it to a custom base I was working on, I’d already worked out the coordinates for the “origin” in the “rev” data, it just took a lot of trial & error to get the orientation & Rotation Matrix lined up properly.
-
…
PS that’s v4 of UTF_Edit, I think it’s still classed as a beta, meaning I doubt if it’s publicly available for general use yet, :-[ sorry for teasing everyone with it
Any idea when that sucker might be available? Looks like it could really be put to good use.
MK
-
hi, im sure some remember me…
i had planned writing a full tutorial on this, since ive also worked it out a couple of months ago.
unfortunately the “demo object” (a huge custom base) is still being worked on. (paintjob)
first you need utf_edit v1.3, the one i have. (or higher obviously)
it lets you edit the fix/rev components position/rotation etc.
cause in milkshape the pivot will be the origin, so move components there, and edit the offset later.
second, you can use the utf2xml tool to add/remove fix/rev/pris nodes, move multiple hardpoints to other groups, clone component/animation nodes, etcAnimation
± Script
± Sc_example_0 <- name of animation
± Joint map 0 <- a joint for each rev component
± Channel
± Frames <- frames of animation
± Header <- type of animation
± Child name <- name of rev component
± Parent name <- name of parent (ex. root)
± Joint map 1
± Ch…
± Fr…
± He…
± Ch…
± Pa…
± Sc_example_1
± Joint map 0
± Ch…
± Fr…
± He…
± Ch…
± Pa…so far i know of 2 animation types…
movement (ex. station_large) <- havent experimented with this yet.
header:
0.000000
1.000000
0.000000frames:
0.000000 <- guessing frame/position
11.813642
23.627285
35.440926rotation (ex. station_small)
header:
0.000000
-1.000000
0.000000frames:
0.000000 <- frame
0.000000 <- rad
40.000000 <- frame
3.137226 <- rad
40.166668 <- frame
-3.132870 <- rad
80.000000 <- frame
-0.008720 <- radchange the frame values to modify the speed of animation,
edit rad to change speed/rotation/direction. (direction can also be changed by editing the components orientation)and here are 2 screenshots, dont have game recording tool installed atm.
the base is made of more than 80 components, had to do this to get a working sur with the sur splicer.
proves that you can have many component and animation nodes btw.
the radar on top and the ring section with its turrets are revolute, spinning.
the baydoors are working like on vanilla bases, except i let them open to the outside.
dock animation can be set in solararch.ini, the other have to be put in select_equip.ini and attached via loadout.inibase showing its firepower:
docking granted:
-
Thanks, got it. Silly me, was looking for utf2xml all the way.
I managed to get a fully working baydoor animation, on a completely custom capital ship. Naturally, this needed the CMP to be exported in such a way.
With the animation in the CMP done, there is only one question left - making a sur file that adjusts accordingly - so that if the baydoor is open, fighters can fly inside, and when it is closed, they can’t.This might fit into another topic, but… oh well. Do any of you know what is needed in the sur so that the baydoor will be accepted? I assume that needs a multi-component sur, where the baydoor is sur component #2 (or index 1) just like in the CMP, but this leaves me with the dilemma of constructing the rest of the sur - there is a ship, with a big hole (hangar) on the inside - thus it is pretty much impossible to make the first sur component convex. I guess the solution would be to have sur component #1 a convex part of Root, component #2 being the bay, component #3 being another convex part of the root, #4 being another convex part of the root - or what I am speaking is simply terrible nonsense. Please correct me - oh and while you are at it, call ms3d groups ‘groups’ and sur groups ‘components’ because I tend to mix them up when reading others’ notes. Thanks loads for all your help!
I might just post a video if everything works out nicely.
