Spring RTS Engine

Assimp already exposes nodes in parent->child hierarchy. How those hierarchies are created and named in the first place is presumably up to your modeling software. In the OBJ format I think the nodes are called 'groups'. In other cases the relationships could be 'nodes' or 'bones' or whatever those things that Blender uses as joiners are called (assemblies?).

Assimp also always provides a single 'root' node which in most cases has no meshes of its own but contains child nodes. If these nodes don't have names I think it names them for you, ie: 3DSDummyRoot, 3DSMesh_1, 3DSMesh_2, etc.. These are the names I'm passing to the pieces, so they're also your piece names in the event you didn't name them in your model editor. On the other hand I have seen some simple models imported with nodes named "" (an empty string) so I may have to give them dummy names as well.

In short I don't think UpSpring's hierarchy editor is doing anything that can't be done with common editors. However, it could be that some model formats can't store the hierarchy information when you export.

If it turns out that this is the case I guess lua could be used to remap the hierarchy using nested tables, ie:
Or something like that.

Pretty sure OBJ, which is probably by far the most common format used within the Spring Community for exports, is non-hierarchical.

A lua based 'partner' file with hierarchy and maybe other useful data in it would be sweet.

agreed with flozi

I was thinking about a partner file anyway, for other attributes like scale, alternate textures, rotation offsets, radius, collision volumes, etc.

I'll think i'll have Spring look for a file in the objects3d/ directory called <modelname>.lua any time LoadModel() is called and associate the returned properties with the C3DModel class.

You use obj? I used 3ds, my obj tends to import as a solid lump rather than its seperate parts. Always thought 3ds was the standard for that reason.

So it sounds like under normal circumstances the unit icon is sufficient. Are there currently any mods that don't use unit radar icons for distant units? What about the star wars mod?

There arent many mods which use icons MORE than SWIW, possibly s44 may rival it.

OBJ actually supports multiple pieces, but upspring (and some other progs, too) doesn't know about it and always reads/writes obj as one piece. Not sure if it has hierarchy though or just multiple pieces at the same level (like 3ds export from upspring for ex.)

yuritch wrote:OBJ actually supports multiple pieces, but upspring (and some other progs, too) doesn't know about it and always reads/writes obj as one piece. Not sure if it has hierarchy though or just multiple pieces at the same level (like 3ds export from upspring for ex.)

Pretty sure it just has multiple pieces without hierarchy

Yeah, precisely, upspring doesnt support importing multiple objects from .obj. Thats why i am surprised anyone uses obj at all, let alone "by far the most common format used within the Spring Community for exports".

it's just 10 more minutes and the good feeling that you're doing it the right way

Saktoth wrote:Yeah, precisely, upspring doesnt support importing multiple objects from .obj. Thats why i am surprised anyone uses obj at all, let alone "by far the most common format used within the Spring Community for exports".

How else? 3ds imports as an incorrectly rotated solid lump as well.

rattle wrote:it's just 10 more minutes and the good feeling that you're doing it the right way

^ this

smoth wrote:

rattle wrote:it's just 10 more minutes and the good feeling that you're doing it the right way

^ this

And a +2 from me and Spiked.

resistance to change for the loose

AF wrote:resistance to change for the loose

Come back when you have experience making mods/games for Spring.

What are you guys actually talking about here, OBJ vs. 3DS? That extra 10 mins being the time required to export each piece seperately? If so this is one of the things I want to fix in UpSpring. I don't believe exporting pieces one at a time or having to merge pieces is a limitation of either format, just a limitation/bug in UpSpring itself, correct?

AFAIK OBJ supports groups and these groups can have names

wikipedia wrote:# Named objects, polygon groups and material groups are specified via the following tags.
o [object name]
...
g [group name]

OBJ Spec wrote:Grouping

There are four statements in the .obj file to help you manipulate groups
of elements:

o Gropu name statements are used to organize collections of
elements and simplify data manipulation for operations in
Model.
o Smoothing group statements let you identify elements over which
normals are to be interpolated to give those elements a smooth,
non-faceted appearance. This is a quick way to specify vertex
normals.
o Merging group statements are used to ideneify free-form elements
that should be inspected for adjacency detection. You can also
use merging groups to exclude surfaces which are close enough to
be considered adjacent but should not be merged.
o Object name statements let you assign a name to an entire object
in a single file.

All grouping statements are state-setting. This means that once a
group statement is set, it alpplies to all elements that follow
until the next group statement.

http://local.wasp.uwa.edu.au/~pbourke/dataformats/obj/

I'm not seeing any evidence these issues are limitations of the format, which implies UpSpring simply doesn't understand, use or maintain objects and/or groups.

I don't believe exporting pieces one at a time or having to merge pieces is a limitation of either format, just a limitation/bug in UpSpring itself, correct?

Quite correct yes.

I mostly chose not to put out what content I built, either because it was unfinished, or it was scrapped, the main exception being my very first few baby steps involving a handful of models, and the XTA reactors. I dont want to advertise what Ive done when the likes of smoths artwork are so much prettier

Quick rundown of proposed UpSpring fixes/changes, let me know if any are going to cause you problems. Let me know if i missed something important:

ALL FORMATS
* Show all supported types as default filetype in load/save selection.
* Try to preserve/scale normals and UV on scaling and rotation
* Fix any issues with objects "jumping around".
* Allow Lua metadata file to be exported without saving model
* Batch convert option for files, directories, archives (sdz/sd7) and maps
* Command-line operations for batch convert without GUI.
* Fix texture handling and display. Fix common problems automatically unless disabled in prefs.
* Create / replace parent object for all childs called 'base' at the top of the tree. You can rename this if you require.
* Check UpSpring builds on all platforms that can build Spring
* Fix not saving file extension

OBJ
* Import/Export named objects. Hierarchies may still not be possible but your objects won't automatically merge either.

3DS
* Auto rotate on import unless UpSpring preferences say otherwise
* Maintain hierarchy if possible (may not be)

ANY + Lua
* Look for <modelname>.lua in objects3d and import values and hierarchy if found
* Use Lua as 'god' for all values if that value is set.
* Disable any automatic rotations / fixes if Lua defines these.
* Option to raw import without Lua data (act like the Lua isn't there)
* Attempt to preserve Lua comments and source order/formatting.
* Allow seperate import of Lua (ie, to use a shared Lua or Lua stored outside objects3d/)

AF (PM) wrote:Do you intend to implement this seperatly from lua animations?

Or do you intend to use this as a part of lua animations?

e.g. removing an arm and replacing it within the heirarchy at runtime, or re-arranging it, or building parts of the heirarchy at runtime on demand and picking them apart on a per unit/object basis?

I imagine the Lua/COB system will need to interact with this file at some level however the intention atm is only to provide data that is difficult or impossible to store in the model file itself (essentially making Model+Lua a format in its own right. I'll need to give this more thought before commenting. What you described sounds like it really belongs in Lua/COB scripts and these are currently tied too closely to unit code (whereas models might serve any number of purposes both as world objects and UI elements).

OBJ
* Import/Export named objects. Hierarchies may still not be possible but your objects won't automatically merge either.

Either that or batch import, piece name taken from filename.