Spring RTS Engine

Yeah basically what I feel is that

Kloot wrote:[attachment=0]core_commander.obj.lua[/attachment

Contains the part that can and should be easily typed manually, while combining it with the painful numbers that should be auto-generated. I want to have a single lua file that I can create and easily edit to just enter the piecename hierarchy. Then when I open an obj in Upspring, load the tree file, and Upspring could create the new lua which also contains offsets, based on these two. Thus I can edit the obj in whatever editor I want, not have to touch the tree file (unless it's a tiny change) and then the Upspring process is 10 seconds, instead of its current 10 minutes. Kloot's A_B link thing sounds unnecessary to me.

CarRepairer wrote: It's this part that scares me:

Code: Select all

offset = {7.7157217504009e-08, 2.4599997997284, 0.72614061832428},

Obviously typing in all the offsets would be a bit unfriendly, but if you choose to use the Blender plugin (that I'll release later), your workflow will just look like this:

1) create (or import) the .obj in Blender
2) name/move objects and add parent relations between them as you see fit
3) select File ==> Export ==> "Spring OBJ Lua meta-data script"
4) ???
5) profit

This will write the hierarchy information (and the painful numbers) for you.

Kloot wrote:

CarRepairer wrote: It's this part that scares me:

Code: Select all

offset = {7.7157217504009e-08, 2.4599997997284, 0.72614061832428},

Obviously typing in all the offsets would be a bit unfriendly, but if you choose to use the Blender plugin (that I'll release later), your workflow will just look like this:

1) create (or import) the .obj in Blender
2) name/move objects and add parent relations between them as you see fit
3) select File ==> Export ==> "Spring OBJ Lua meta-data script"
4) ???
5) profit

This will write the hierarchy information (and the painful numbers) for you.

How do I edit each piece's origin like in Upspring's origin mover? I am still new to modeling and even newer to Blender. I'll assume it's doable so maybe this is a Blender question, not related to this thread.

One at a time? For every Piece? And if you need to make adjustments later?

It's like upspring without the interface

Are the origin coordinates relative to the parent piece or global?

Cool news, thanks for this Kloot! I know it makes it far more likely for me as a non-modeler to have a try at getting models into the game :D! (and the Blender Plugin sounds like a great idea)

CarRepairer wrote: How do I edit each piece's origin like in Upspring's origin mover?

http://wiki.blender.org/index.php/Doc:M ... ts/Editing

rattle wrote:Are the origin coordinates relative to the parent piece or global?

The plugin writes them in relative coordinates, but the engine can also deal with global offsets. There is a special metadata key localPieceOffsets to let it know how they should be interpreted.

rattle wrote:

One at a time? For every Piece? And if you need to make adjustments later?

It's like upspring without the interface

This. You'd still have to enter all the co-ordinates whichever method you use. I actually think I'd prefer to do it without the Upspring gui getting in the way.

Thanks for all the hard work, Kloot. I look forward to trying your Blender plugin when it's ready.

The plugin writes them in relative coordinates, but the engine can also deal with global offsets. There is a special metadata key localPieceOffsets to let it know how they should be interpreted.

Nice to hear, you also answered my next question.

355 + // NOTE: unlike 3DO / S3O, the min- and max-extends of a
356 + // piece are not calculated recursively over its children
357 + // since this makes little sense for coldet purposes; the
358 + // model extends do encompass all pieces

This is neat, but is there really a reason it can't be done for per-piece coldets with 3do/s3o?

There probably isn't (it would be an easy change at least), but I haven't checked for any deeper reasons why the 3DO/S3O code was written that way.

Anyway, I've attached the Blender plugin to the first post. To those willing to test it, be sure to scan the .log as well as the .lua script for any errors after exporting. Thanks.

This is great news, hope it's the first step in the direction of a more standard model/animation format for Spring.


IK someday?

omfg we have lua animations what more do you want srsly. its an rts engine.

You've not played any modern RTSes, have you Trib? Mesh deformation / skeletal animations would be nice, practically necessary for organic units. Sure, Lua animation is a step forwards, but we still lag behind.

Would it be that difficult to allow the use of a format with support for skeletal animations, whilst the script just uses bones instead of pieces? Ie the animation system (ie Turn, Move, Spin etc) would be exactly the same, but would allow for mesh deformation and proper animation of organic units. Still scripted animations rather than canned, but it would solve the worst of the issues with organic units. Would that be difficult?

what more do you want

furiously unrelated cheese kinetics, you?


For simple IK that's feasible right now you'd need to describe along which axis a piece may turn how much and such which should be stored in the model descriptor file

/me humps kloots leg

* calculate 3DO/S3O piece extrema non-recursively

This makes per-piece coldet actually work; the
old code was only structured in a recursive way
to propagate the maximum radius/height/size up
to the root-piece.

Hump it moar!

Sorry, could someone explain what a coldet is?

My bet on collision detection.

Guessmyname wrote:You've not played any modern RTSes, have you Trib? Mesh deformation / skeletal animations would be nice, practically necessary for organic units. Sure, Lua animation is a step forwards, but we still lag behind.

Would it be that difficult to allow the use of a format with support for skeletal animations, whilst the script just uses bones instead of pieces? Ie the animation system (ie Turn, Move, Spin etc) would be exactly the same, but would allow for mesh deformation and proper animation of organic units. Still scripted animations rather than canned, but it would solve the worst of the issues with organic units. Would that be difficult?

which has what to do with "ik plox!!!!"?
I agree with everything you said, and my snide comment still holds.