Upspring 1.54
Moderator: Moderators
-
Guessmyname
- Posts: 3301
- Joined: 28 Apr 2005, 21:07
On another (more grim and annoying) note.
Does this look suspiciously bugged or F'ed up? Upspring spat it out after I spent 15 minutes making a good looking aim for my soldier!
Ingame, it looks like he is dancing around...
Does this look suspiciously bugged or F'ed up? Upspring spat it out after I spent 15 minutes making a good looking aim for my soldier!
Code: Select all
Move gun to z-axis 7 speed[0];
Move chest to z-axis 0 speed[2];
Turn chest to x-axis 1538 speed<6155>;
Turn chest to y-axis -3682 speed<-14730>;
Turn chest to z-axis 564 speed<2257>;
Turn leftshould to x-axis -10338 speed<-41352>;
Turn leftshould to y-axis -2316 speed<-9264>;
Turn leftshould to z-axis -631 speed<-2525>;
Turn leftforearm to x-axis -8988 speed<-35952>;
Turn leftforearm to y-axis -1070 speed<-4280>;
Turn leftforearm to z-axis 2017 speed<8068>;
Turn rightshould to x-axis -8943 speed<-35775>;
Turn rightshould to y-axis 1863 speed<7452>;
Turn rightshould to z-axis -403 speed<-1615>;
Turn rightforearm to x-axis -11043 speed<-44173>;
Turn rightforearm to y-axis 23979 speed<95917>;
Turn rightforearm to z-axis 16887 speed<67549>;
Turn leftleg to x-axis -1456 speed<-5825>;
Turn leftfoot to x-axis 1456 speed<5825>;
Turn rightleg to z-axis 1820 speed<7281>;
Turn rightfoot to x-axis 1892 speed<7569>;
Turn rightfoot to y-axis -17420 speed<-69681>;
Turn rightfoot to z-axis 368 speed<1475>;
-
Guessmyname
- Posts: 3301
- Joined: 28 Apr 2005, 21:07
Gah!
This... this is why I dislike using upspring. I'm trying to get the model to appear ingame, open up the s3o again and find it's done this. Why has it done this? It's just broken it entirely!
I've uploaded the s3o for those who want to look at it: here
This... this is why I dislike using upspring. I'm trying to get the model to appear ingame, open up the s3o again and find it's done this. Why has it done this? It's just broken it entirely!
I've uploaded the s3o for those who want to look at it: here
Here, it's fixed, in more ways than one.
Next time, remember... make hierarchy first, move origins around second, and never, ever do an initial pose on a model with UpSpring unless you are prepared to deal with the consequences
To put it another way... I never, ever, ever do initial poses in UpSpring. Ever. I mean, really. Never. That's what your modeling environment is for. It keeps things much, much simpler.
Next time, remember... make hierarchy first, move origins around second, and never, ever do an initial pose on a model with UpSpring unless you are prepared to deal with the consequences
To put it another way... I never, ever, ever do initial poses in UpSpring. Ever. I mean, really. Never. That's what your modeling environment is for. It keeps things much, much simpler.
jcnossen wrote:because the bos exporter is written in lua.. look somewhere in the scripts directory.
I'm aware that the script doesn't work, but I have no motivation/time to fix it. However it might just be a matter of scaling some generated values like the angles.. Im not sure.
Well, first, all you need to do is make sure it A:Exports it with the speeds divided by 182, or with out the > and <, and B: Make sure it exports speeds as positive numbers..
Doesn't sound hard, but i have no experience scripting in lua...
Step zero is to position all parts (e.g. mirroring, scaling) and applying the transformation on all of them. Especially if your exporter is Z-up that's important, the 90° rotation in the root object will lead to errors almost all the time.Argh wrote:make hierarchy first, move origins around second
That's why I assemble everything but the origins in wings and use a 3ds export for the half finished hierarchy. I do all the initial rotation or movement (when needed) by script.
Snipa: 182.0444~ (65536/360).
Just change it from
to either
Snipa: 182.0444~ (65536/360).
Just change it from
Code: Select all
if dif.x ~= 0 then f:write(string.format("move %s to x-axis %d speed[%d];\n", propInfo.obj.name, pos2.x, dif.x / interval)) endCode: Select all
if dif.x ~= 0 then f:write(string.format("move %s to x-axis %d speed %d;\n", propInfo.obj.name, pos2.x, dif.x / interval)) end- no brackets
Code: Select all
if dif.x ~= 0 then f:write(string.format("move %s to x-axis %d speed [%d];\n", propInfo.obj.name, pos2.x, dif.x / interval / 65536 * 360)) end- linear -> degree conversion
I found one (minor) thing to gripe about, JC (took me awhile, I really love this version!). UpSpring doesn't do two things quite right, imo:
1. It doesn't remember your last-used texture directory by default. Sucks having to put it in over and over again.
2. It locks up file access to the image files, even if you are viewing another model! Kind've hard to do touch-ups and such in UpSpring, if we can't just reload the texture and save it in our image editors, because it's locked.
Minor issues, to be sure. Otherwise, I couldn't be happier, really- until we see a new model format, this is a great tool overall, and has helped me be a lot more productive!
1. It doesn't remember your last-used texture directory by default. Sucks having to put it in over and over again.
2. It locks up file access to the image files, even if you are viewing another model! Kind've hard to do touch-ups and such in UpSpring, if we can't just reload the texture and save it in our image editors, because it's locked.
Minor issues, to be sure. Otherwise, I couldn't be happier, really- until we see a new model format, this is a great tool overall, and has helped me be a lot more productive!
Ok, I've done some major look-see into how COB animation works, at the byte-code level, and what I've found is extremely important.
JC, it turns out that we've all been completely wrong about how to best achieve efficient animation within Spring, or for that matter, Command Engine. The most computationally-efficient method, whatever the actual syntax involved, is not:
turn Piece XYZ Angle Speed (interpolation math).
It's not that this is evil, or should never be used, or whatever. It's not evil, and it has some (very important) uses. However, for most animations, it's actually a lot less efficient than this (forgive me, but this has to be phrased in BOS):
{
turn Piece XYZ Angle now;
sleep 33;
}
Where 33 is understood to mean, "one game update cycle".
It may seem ridiculous or whatever, but it's not. The interpolated movement of objects (whether through Spring's own interpolation, or by using turn / wait-for-turn, which is then synced with everything else in Spring by doing some fairly fancy math) is quite slow by comparison to simply saying, "hey, this needs to be here, then here, then here, then here" forever and anon.
There's are additional wrinkles, however, that cannot be addressed within Spring, and are fact is going to have to wait for a new animation language:
Currently, Scriptor does not allow for users to design ELSE statements that properly jump to the right byte of the bytecode. This means that large scripts with hundreds of lines and dozens of IF(condition){}ELSE assumes that the jump goes to the outside of the section, instead of being routed to a coder's choice. This, along with the fact that we cannot use genuine precompiled libraries for common functions, is a major limiter on overall efficiency of the way that our code executes.
All of that said, if UpSpring's animation-output code could build code that looked like this:
if(go)
{
move Piece1 to XYZ angle1 now;
move Piece2 to XYZ angle1 now;
sleep 33;
}
if(go)
{
move Piece1 to XYZ angle2 now;
move Piece2 to XYZ angle2 now;
sleep 33;
}
It'd be a really worthwhile increase in efficiency of the animations being performed. In short, I've finally come to understand why Cavedog insisted on doing their animations that way, and if we had tools that would duplicate that method, we could take the raw output and use it readily.
How I think this should work:
1. User sets an initial pose.
2. User hits a button that says "Start frames".
3. Upspring asks how many frames the user wants the change between the two states to be. Animations can be as short as 1/30th of a second, to as long as they want. Best to ask people to think in terms of "frames" instead of "seconds", because that's really the best way to handle this. If Command Engine is designed for a higher cyclic rate, then use that, or whatever- I'm assuming that you haven't abandoned that project, and that something like UpSpring, along with something like BOS, but without its problems, will be part of it. I know that asking for this for Spring's probably a big stretch.
4. User now moves all of the Pieces (IK'd bitz, etc.) to the next pose, and hits, "Make frames". Then UpSpring does the math to interpolate all movement between the first and second state, breaking it down to the proper rotation / movement per frame, and outputs a screen of text.
5. If users want to put multiple states together, they could either do this manually, or they could just hit a button labeled "Add More Frames". It'd be extra kewl if we could even select frames and cut them, then ask UpSpring to re-interpolate the start and end states (to speed things up and slow them down on the fly) and of course, playback would be nice.
Anyhow... I know this is probably item 100000000 on your priorities, etc., just thought that it might be important later on, if Command Engine is going to continue to support scripted animation. I think that, if this Make Frames thing could even store triangle positions, etc., then this could become a de-facto animation environment for IK'd models, giving us scripted control if necessary, whilst also giving end-users a powerful tool for working with deformation and other things as part of their workflow with CE.
JC, it turns out that we've all been completely wrong about how to best achieve efficient animation within Spring, or for that matter, Command Engine. The most computationally-efficient method, whatever the actual syntax involved, is not:
turn Piece XYZ Angle Speed (interpolation math).
It's not that this is evil, or should never be used, or whatever. It's not evil, and it has some (very important) uses. However, for most animations, it's actually a lot less efficient than this (forgive me, but this has to be phrased in BOS):
{
turn Piece XYZ Angle now;
sleep 33;
}
Where 33 is understood to mean, "one game update cycle".
It may seem ridiculous or whatever, but it's not. The interpolated movement of objects (whether through Spring's own interpolation, or by using turn / wait-for-turn, which is then synced with everything else in Spring by doing some fairly fancy math) is quite slow by comparison to simply saying, "hey, this needs to be here, then here, then here, then here" forever and anon.
There's are additional wrinkles, however, that cannot be addressed within Spring, and are fact is going to have to wait for a new animation language:
Currently, Scriptor does not allow for users to design ELSE statements that properly jump to the right byte of the bytecode. This means that large scripts with hundreds of lines and dozens of IF(condition){}ELSE assumes that the jump goes to the outside of the section, instead of being routed to a coder's choice. This, along with the fact that we cannot use genuine precompiled libraries for common functions, is a major limiter on overall efficiency of the way that our code executes.
All of that said, if UpSpring's animation-output code could build code that looked like this:
if(go)
{
move Piece1 to XYZ angle1 now;
move Piece2 to XYZ angle1 now;
sleep 33;
}
if(go)
{
move Piece1 to XYZ angle2 now;
move Piece2 to XYZ angle2 now;
sleep 33;
}
It'd be a really worthwhile increase in efficiency of the animations being performed. In short, I've finally come to understand why Cavedog insisted on doing their animations that way, and if we had tools that would duplicate that method, we could take the raw output and use it readily.
How I think this should work:
1. User sets an initial pose.
2. User hits a button that says "Start frames".
3. Upspring asks how many frames the user wants the change between the two states to be. Animations can be as short as 1/30th of a second, to as long as they want. Best to ask people to think in terms of "frames" instead of "seconds", because that's really the best way to handle this. If Command Engine is designed for a higher cyclic rate, then use that, or whatever- I'm assuming that you haven't abandoned that project, and that something like UpSpring, along with something like BOS, but without its problems, will be part of it. I know that asking for this for Spring's probably a big stretch.
4. User now moves all of the Pieces (IK'd bitz, etc.) to the next pose, and hits, "Make frames". Then UpSpring does the math to interpolate all movement between the first and second state, breaking it down to the proper rotation / movement per frame, and outputs a screen of text.
5. If users want to put multiple states together, they could either do this manually, or they could just hit a button labeled "Add More Frames". It'd be extra kewl if we could even select frames and cut them, then ask UpSpring to re-interpolate the start and end states (to speed things up and slow them down on the fly) and of course, playback would be nice.
Anyhow... I know this is probably item 100000000 on your priorities, etc., just thought that it might be important later on, if Command Engine is going to continue to support scripted animation. I think that, if this Make Frames thing could even store triangle positions, etc., then this could become a de-facto animation environment for IK'd models, giving us scripted control if necessary, whilst also giving end-users a powerful tool for working with deformation and other things as part of their workflow with CE.
In my experience, ELSE blocks work nicely. I'm using Scriptor 2.1 (which is known to be unstable under Windows XP, but setting it to Windows 98 compatibility solves that).Argh wrote:...Currently, Scriptor does not allow for users to design ELSE statements that properly jump to the right byte of the bytecode.
I doubt CE will support it for more than easy porting, proper skeletal animation is vastly superior and has tools available that have been developed for ten or more years while constantly getting better. Trying to reinvent the wheel won't help there.
Me, I'm using turn ... speed in the hope that this can be used as an easy hint for the position between frames.
Also keep in mind that C (with proper coding conventions) won't allow you to make your else jump to random places either. Just put everything between the if and the desired else into the if block, that way people can see what gets skipped, gotos are horrible style.
Me, I'm using turn ... speed in the hope that this can be used as an easy hint for the position between frames.
Also keep in mind that C (with proper coding conventions) won't allow you to make your else jump to random places either. Just put everything between the if and the desired else into the if block, that way people can see what gets skipped, gotos are horrible style.
-
Warlord Zsinj
- Imperial Winter Developer
- Posts: 3742
- Joined: 24 Aug 2004, 08:59
I would sacrifice a million bunnies for a good opk -> cob exporter.
I can get my mind around the animation in upspring, but the hard and fast rules of animation through script is a little beyond the time I have to spend learning and scripting at the moment.
I mean, sure I'd kill for skeletal animation, but for the moment, I'd really like that as a stopgap solution to get animation out the door quickly and easily.
I can get my mind around the animation in upspring, but the hard and fast rules of animation through script is a little beyond the time I have to spend learning and scripting at the moment.
I mean, sure I'd kill for skeletal animation, but for the moment, I'd really like that as a stopgap solution to get animation out the door quickly and easily.
Noes! I've even requested http://www.commandengine.net to show my dedicatedness !If Command Engine is designed for a higher cyclic rate, then use that, or whatever- I'm assuming that you haven't abandoned that project
But I'll only continue on upspring once i get to model animation support in CE coding...
In the mean time, I can't really use remarks such as "upspring fucks up my piece orientations, look at this model it looks fucked up".... I need the actions that caused this state... Give me information on how to replicate the problem.