New Spring model system. Need feedback from modellers / devs

[Saktoth]

* Create / replace parent object for all childs called 'base' at the top of the tree. You can rename this if you require.

What does this mean? All models will have an object named base as the root object if they do not already have one?

[SpliFF]

Assimp currently imports models with the top level (essentially a piece representing the whole model) called <filename>.3ds. That isn't really a useful name for COB so I'd simply rename that object 'base' by default (and create it in UpSpring as a parent of everything if you haven't set your hierarchy before). You can rename it before export if you desire since assimp always knows what the top node of a model is. It's only relevant for COB. If you call your top object something else like 'body' or whatever in COB/Lua then you can rename 'base' in the model or in cob, your choice.

The name 'base' has no actual meaning to Spring, UpSpring or Assimp; it just seems that's the norm for most COB scripts and UpSpring tutorials.

[rattle]

Comes from OTA, usually it was a 1-sided quad. I think it had to do with the unit footprint and/or collision checks.

[smoth]

Actually that was "gp" or ground plate. It was set in 3do builder but not actually modeled

[SpliFF]

As part of looking into ways Spring modellers can avoid UpSpring I've been looking into methods of auto-generating model height and radius with sane values.

As part of this investigation I've been looking into what these values are actually used for. I'm also looking at the relationship between these values and other properties like mid position, footprints and collision volumes.

I want to go over a proposal I have to simplify the system somewhat. The key part of this proposal is to allow most assets to be transferred directly from your 3d software to spring without any further work.

But first, here's how things stand right now:

Current System

radius: Created manually in UpSpring by dragging a sphere outwards or setting values. Radius is used to test when a unit is in view, for explosive hits, and for sphere collision handling. 3DO format does not have this and calculates it as 80% of the biggest node/piece in the model (typically this will be the chassis).

center offset: A 3D vector setting the point a unit sits on the ground and pivots. Created in UpSpring by positioning a point or manually setting values. 3DO appears to use the bottom of the root object for Y and 0,0 for X and Z.

height: A number specifying how high a model is. Used to test if objects have fallen into the ground, for los/radar tests, for testing if a unit is underwater, for COB transport code. Set in UpSpring. 3DO appears to use the top of the root object.

collision volume: Used for projectile and unit collisions. For 3DO uses a "box" collision around the root object (i think). Otherwise the default is the unit radius. Can be overridden in unit FBI to use 'cylinder', 'box', 'sphere', 'footprint' It should be noted that ALL collision types start with a radius test around the volume for early-out optimization.

footprint: X and Z values used for placing buildings and determining how much room is needed for pathing. This is set in unit FBI but 3DO models have a root piece named 'GP' which is used for defaults.


At first glance it's starting to look like most of these values serve little purpose at all. In 98% of cases it should be sufficient to automatically calculate all these properties especially if you've correctly placed your object relative to the origin (0,0,0). It looks like the extra control provided by setting these values is primarily about handling models with long pointy bits.

Given this is observation it should be possible to greatly improve how auto-generation deals with these types of models. Here's my proposal:

New Proposal

Step 1a.) Look for a piece named 'radius'. If found this will be used for height and radius then removed from the model.

Step 1b.) If no 'radius' piece then find all non-pointy pieces. The algorithm is simple: ignore any piece where:
a.) one of the dimensions is more than 20x longer than the others, or
b.) the longest dimension falls below some minimum threshold (too small), or
c.) the piece names contains the substring '_nocol' (set in 3D editor).

This gives us an array containing either a single 'radius' piece or all our 'solid' pieces.

Step 2.) Use our radius or solid pieces to calculate dimensions as follows:

height: Walk the solid pieces in the model looking for the highest vertex.

center: Use the scene true origin (0,0,0)

radius: Use the center and max extents of the combined solid parts and make radius at least large enough to contain them.

footprint: Find a piece named 'footprint' or use the X and Z extents of the solid parts

collision: Use radius for early-out test then, if a unit is greater than a certain size, do per-piece box tests for higher accuracy.


So in theory, and without major changes to my Assimp loader, I should be able to support sane defaults for 99% of unit geometry. This means that although a companion Lua should be still supported for the 1% of cases it's looking less and less likely it will really be needed. This should eliminate any dependence on UpSpring or the need for any tools outside a 3D model program for creating future assets.

Feedback appreciated.

[SeanHeron]

If I'm not misunderstanding, your suggestion would have two main effects:

- One that if you were to use Upspring at all anymore, the ways in which you set the meta-information in it would change a bit.

- Two (and more importantly),

• - that if your model is not too exceptional
  - (and you have the origin [0,0,0] set as center of your model),
  - and the algorithms you laid out did a good job,

Then -- > you'd not need to hand-make any meta-information at all (ie lua-companion file/ set up in Upspring)? Since the Engine would do all these steps automatically on load up of obj/3ds models, yes? (And then perhaps write them to a companion file to save on future calculation time - as is done for Map-pathing).
But of course if you wanted, you could override some/all of these values by including a meta-info companion file, no?

If all those assumptions are correct, then the suggestion sounds pretty awesome to me :D!

-----
Less important:

collision: Use radius for early-out test then, if a unit is greater than a certain size, do per-piece box tests for higher accuracy.

This, of course, would be something people have been grovelling for for ages . Though I wouldn't have expected it to have anything at all to do with the rendering side of things... and as I don't know how complex these calculations / that code is, I'd wager you might be setting yourself up for a lot of work that isn't a necessity for what you really mean to do.
(Though to be fair: I'd think having this would be pretty cool myself - missles streaking in between striding Mechs legs - or through open chopper hulls !).

[SpliFF]

If I'm not misunderstanding, your suggestion would have two main effects:

- One that if you were to use Upspring at all anymore, the ways in which you set the meta-information in it would change a bit.

No. You'd set it the same way, it would just be stored different (lua file, not s3o header). I'm also offering new ways of setting it via your 3d modelling software of choice.

- Two ... Engine would do all these steps automatically ... if you wanted, you could override some/all of these values by including a meta-info companion file, no?

Yes.

Use radius for early-out test then, if a unit is greater than a certain size, do per-piece box tests for higher accuracy. This, of course, would be something people have been grovelling for for ages .

Nobody's grovelling because that's pretty much what happens now when you set per-piece collision volumes. It's just not default and most people probably don't know how/when to use it.

... and as I don't know how complex these calculations / that code is, I'd wager you might be setting yourself up for a lot of work that isn't a necessity for what you really mean to do.

The collision code was written some time ago by people much better at that sort of thing. Anything my proposal does is simply interfacing with that system.

[FLOZi]

There's a reason we can set these things properly by hand and not rely on automation. You also miss that several of these can be set in the unitdef as well as via upspring.

All in all, I think it is a terrible idea to remove the flexibility we currently have for hacks like additional pieces which are removed from the model.

[bobthedinosaur]

All in all, I think it is a terrible idea to remove the flexibility we currently have for hacks like additional pieces which are removed from the model.

Wait. What?

[SeanHeron]

- Two ... Engine would do all these steps automatically ... if you wanted, you could override some/all of these values by including a meta-info companion file, no?

Yes.

That's not what he's saying Flozi.
Edit: All this is just additional to the system we already have - ie make the Upspring (or write yourself a .lua companion file) process optional.
Setting any and all of those values manually would still be completely possible.

[FLOZi]

- Two ... Engine would do all these steps automatically ... if you wanted, you could override some/all of these values by including a meta-info companion file, no?

Yes.

That's not what he's saying Flozi.
Edit: All this is just additional to the system we already have - ie make the Upspring (or write yourself a .lua companion file) process optional.
Setting any and all of those values manually would still be completely possible.

I managed to miss the tiny disclaimer on the end that 'the 1% that need manual setting could still have it'.

Magical reserved piece names sets a bad precedent imo.

I'm pretty sceptical of the whole 'use your modeller for everything and dump Upspring' approach generally. You promised us a bugfixed Upspring; That is usable now, not some time in the future when the model loader/renderer has been rewritten. S3O as a format is sufficient, and Upspring while buggy and lacking in many respects is capable.

There's a reason very few Spring modellers use Blender.

[SeanHeron]

First off (as this has been misunderstood elsewhere), by no means do I intend to speak for SpliFF, as I'm neither in his head, nor have anymore information than that out of this Thread (apologies to be stating the obvious [and Flozi, I'm clear that you realize this], but, yah - better safe than sorry)

You promised us a bugfixed Upspring; That is usable now, not some time in the future when the model loader/renderer has been rewritten.

I'm not sure I quite follow you there - my understanding was that SpliFF said he would fix up Upspring (and add the new functionality) when it was necessary as a tool for conversion of .s3o meta-information into a different format (ie the companion Lua-file).
It certainly would be finished before the rewrite is done/commited - but that's not what you meant by "now", is it ? I don't see what sense the bugfixing/updating would currently make in this context, when there's not yet anything you can do with the Lua-companions ? Apologies if I'm misunderstanding you badly here.

S3O as a format is sufficient, and Upspring while buggy and lacking in many respects is capable.

I can't disagree with that, but I would add that it doesn't seem to be a convenient format (from how I understood remarks on it by Bob - I must admit I have no firsthand experience). That merit alone, in my opinion, is worth the change
(I fully realise that the incentives for me as a "newcomer" are very different to those of the devteam of an established game such as Spring'44 - and that those differences invariably will lead to different opinions).

[smoth]

I'm pretty skeptical of the whole 'use your modeller for everything and dump Upspring' approach generally.

...

There's a reason very few Spring modellers use Blender.

Change skeptical to outright violently oppose and you will have my stance.

[SpliFF]

FloZI, smoth, I don't think you're taking enough time to process what is written (not just in my last post, but the whole thread). If it didn't get derailed so much by misquotes you'd probably realise:

a.) I am currently working on UpSpring because it's still required as a GUI for those that want it and as a converter to move to obj+lua or 3ds+lua. This latest proposal hasn't changed that, just added new possibilities (both automatic and manual setup) without UpSpring.

b.) Assimp exposes properties like bones, animations, lights and cameras that s3o/3do don't support. So while s3o might be adequate now it certainly won't remain so if/when the possibility of non-cob animations is exposed. It's certainly redundant once Spring has a model metadata file and/or modern formats that both Spring and UpSpring understand and a simple and reliable conversion process.

c.) I think I made it pretty clear that the named radius and footprint objects stored in the model are optional and overridable, if I didn't then consider it made clear now. You may find the concept cumbersome, I do not. It's simply a personal preference and an entirely optional one at that.

d.) I never said anything about blender. Pretty much any useful 3D editor should let you name objects/pieces/nodes and hide them.

e.) Most objections raised are concerns about a implementation that isn't written yet. If it turns out it doesn't convert accurately then there's something to discuss. For now the only meaningful objections can be about the process itself. There's no point getting upset about something that's optional or the same as you do now.

f.) Most of the processes described are only relevant to NEW assets. S3O headers (radius/height/center etc) are just passed through to 3ds+lua/obj+lua unchanged. 3DO doesn't even have these headers.

I'm offering alternatives, that's all. If you think your current workflow is the bee's shit then keep doing it, just use 3ds+lua or obj+lua instead of s3o since supporting s3o/3do in the engine when they can be converted just complicates engine development in the short and long terms.

I think you should go back though the thread and read my posts carefully. Particulary my UpSpring TODO list, the purpose of the metafile, and the methods available to edit/create it. Then, come back with specific objections that haven't already been discredited. I may not like UpSpring but you've already made it clear you want it so I'm giving us BOTH what we want. There's no basis for disagreement on that point. If and when I lose interest in UpSpring the source code is out there for future development.

The only thing i'm not suggesting should be optional is the maintenance of the current s3o/3do rendering pathways in the engine. If assets can be easily converted then their old formats no longer serve a valid purpose and they are an impediment to future rendering/animation developments. ALL legacy/unmaintained mods are about to break with Spring 0.85.1.2 anyway (see modinfo.tdf discussion) so backwards compatibility effects of my changes are totally irrelevant now. Batch conversion should make converting assets easier than rewriting modinfo.tdf.