Upspring 1.54

[AF]

Aren't the broken angles due to a broken lua script? Couldn't someone fix them without needing upspring itself to be changed?

[Nemo]

No AF. That's just the exporter - which is a part of the problem, but the bigger issue is that upspring doesn't display angles > 90 degrees without all kinds of weirdness - yes, I know its just a different way of displaying the angle, but with COB animation I really want to turn in just one axis at a time (and going the "back way" to get to that angle results in the part turning in the wrong direction ingame). This also means that turns in multiple axis beyond 90 degrees are basically impossible.

Also, there's a chance every once in a while (usually with turns of 90 degrees or more) of the object you're working on just vanishing and not coming back, meaning that you have to start over from a fresh load of the model.

For JC or any interested coder: to reproduce, take this s3o, and load it into upspring. go to the objects list, click on rthigh, and enter an X rotation of 90 degrees. complete that, then enter a Y-rotation of 90 degrees, and blink as the entire leg suddenly goes missing.

That's just bugfixing. If I were to start feature wishlisting, I'm sure JC would want to slap me upside the head. That said, keyframe deletion would be neato.

[KDR_11k]

It can do those just fine but a rotation of +-90° around the x-axis hits a singularity and I'd assume Scriptor uses some other form (e.g. quaternions) to represent piece rotations internally.

[rattle]

I think it was about ~120° here which caused the weird behavior.
Also, we can fix the exporter ourselves if it needs fixing.

[AF]

Perhaps fixing the exporter will encourage jelmer to fix other things...

[jcnossen]

kdr: Upspring actually uses quaternions internally, but converts them all the time to angles to display them in the boxes.

Maybe I look into rewriting it again to use normal euler angles and try to debug stuff with that, but that will have other problems again. There is a lot of code in upspring that requires the rotation to be inversable. That should be all that is happening: angle change -> convert to quaternions -> store in model -> convert back to angles -> show in GUI textboxes..

I'll try to debug nemo's problem sometime but currently im really busy with stuff.

[KDR_11k]

It's Tait-Bryan angles BTW, with Euler the third axis is another Y.

[Treeform]

jcnossen, if you rewrite it make it run on linux

[Tobi]

http://spring.clan-sy.com/mantis/view.php?id=516

[Agon]

I tried to compile Upspring under Linux. To hard for me or to complex...
If you rewrite the Upspring please use a common gui toolkit like wxwigets or GTK or QT4.

[jcnossen]

I ment rewriting the rotation stuff, not rewriting the entire app :)

[Sheekel]

What do i need to compile this properly?

[Sheekel]

I'm having some difficulty determining where to put the FLTK include files. I think it might have something to do with the fact that its looking for <fltk/Window.h> but the in the latest fltk libraries everything has a FL in front of it, for example <FL_Window.h>

[SpikedHelmet]

I'm just throwing this out there:

- It would be very awesome if the BOS animation exporter function worked properly; at the moment it seems to spit out the makings of an animation, but with borked numbers; ie, "Turn torso to y-axis -2730 speed<-9102>;"

- What would be even more mind-numbingly cool is if Upspring were capable of acting like TA's "Unit Viewer"; ie, it was capable of loading bos files and calling animation scripts based solely off of the .S3O and .BOS files (albeit without displaying emit-SFX and other variable functions; purely move, turn, rotate, etc)

[Das Bruce]

- It would be very awesome if the BOS animation exporter function worked properly; at the moment it seems to spit out the makings of an animation, but with borked numbers; ie, "Turn torso to y-axis -2730 speed<-9102>;"

A long long time ago I had this half worked out, I think you divide by sixty but that could just be random misfirings in my memory.

[SpikedHelmet]

Even then, they're ridiculously large -- things turning at speeds of like 800.

But you just may be correct in that it's something universal... hm...

Either way, it would be very useful if this functionality was streamlined, we're getting into a phase where we're developing quite complex animations and having Upspring>Bos compatibility would be violently awesome.

[rattle]

Try this one

BOSExporter.lua

Put it in .\Upspring\scripts\plugins\

(3.88 KiB) Downloaded 148 times

Should output the values correctly like:

Code: Select all

move base to y-axis [10] speed [10];
turn base to y-axis <45> speed <45>;
sleep 1000;

Even then, they're ridiculously large -- things turning at speeds of like 800.

Actually 800 is a pretty small value outside of the <> tags.
<45> = 45*182.04444 = 8192

Also, the linear constant in scriptor has to be 65536.

[jcnossen]

Ok thanks, I added it to the installer.

I compiled a new upspring with euler angles. The representation with euler has some consequences though:

- It will probably have problems with interpolating some animations (Since interpolating euler angles doesn't result in the shortest rotation path), but it might work better for creating BOS stuff.
- The internal data format is different, so CPK files are also different between the euler and non-euler angles version of 1.54.
- Relative and absolute rotation (In the rotator UI), is now the same, since I can't do relative or absolute rotation without messing up the angles again.

Download
Edit: link fixed

[imbaczek]

borked link warning!

[rattle]

http://user.supradigital.org/jcnossen/U ... Angles.exe