Per-object textures for s3o

[Pressure Line]

having talked to a few modelers/texturers the general consensus is that multiple textures per unit are awesome. the main driving force behind my push for this idea is that i would like to get started on the 'Lego bits' idea.

The idea being we have a whole load of uvmapped pieces waiting to be jammed together (tank hulls, mecha bodies, cannons, launchers etc), the main obstacle to this currently is that you have to be a uvmapping mastermind to merge the UV's together, essentially negating the whole purpose of the idea (that being it creates an easy way for an inexperienced modder to get his/her basic unit set ready to create their proof-of-concept mod, or indeed create their entire mod from).

The ability to have for example the hull of a tank be assigned one texture, and the turret/weapon have another means that 2 pre-textured parts can simply be imported into upspring, moved to the correct positions, have the appropriate texture assigned to each object saved and be ready to put ingame. Essentially creating a build-your-own mod toolkit, that anyone can use, regardless of artistic ability.

To keep compatabilty with existing s3o models, a duplicate format (called s3d or sth, its not important at this stage) could be created, with the only difference being support for texture-per-object.

[SpikedHelmet]

While taking into account the work involved in doing this, I must say it would be very appreciated by a great many mod developers.

[quantum]

+1, I think it would facilitate making a full model set for mods greatly.

Perhaps it can even be coded in Lua, which would ease the workload.

[AF]

imo it would be far more useful to be able to specify external s3o models as objects inside an s3o, and even have the option to swap them out ingame using lua for other pieces.

This way you get the multiple uv maps you're requesting, and you also allow for a truly enormous amount of flexibility we would have otherwise missed out on, ranging from custom flags and banners on units, earth 2150 component designing of units, to extreme animations and transformations by adding and removing new premodelled geometry on the fly.

Of course one could argue that this is already possible using lua gadgets.

[quantum]

AF's suggestion sounds even better

[Pressure Line]

something like that would also be acceptable. but i would request that the unit animations be controllable via a single cob script. unless someone is willing/able to write a guide for how to script such a unit, it becomes redundant because it will never get used because no-one understands how to use it.

[AF]

if what i wrote is suggested then cob should still be able to use it because it's still an object. cob does not care whether the object is swapped out by lua.

That or the lua object can be attached to a control point which is an empty point in the s3o model.

Eitherway each component should be fully animated individual pieces complete with aiming, weapons etc, there would quite simply be no need for animation of that sort, otherwise the component would be a part of the main chassis and cob animation would be used as traditionally used.

[Pressure Line]

i understand exactly what you are getting at AF (i hope) i will quickly whip out a simple drawing to demonstrate the way ive interpreted what you are saying :D

[Pressure Line]

ok. i have a missile launcher



with its intended point of rotation (elevation) at 0,0,0.

and a tank body



when i get the model into UpSpring i place an empty object where i would be putting the launcher and call it barrel (like i would if the launcher were actually there) i then place some more empty points where the end of the launch tubes would be as child objects of the barrel object (so we are following the same procedure as normal, except the launcher itself isnt visible) as points for our missiles to spawn and cegs to generate (or use planar objects if thats what you do)

do the other things neccesary to get the model working in upspring and save etc. script the unit, write the fbi, weapons and cegs.

then go through the same procedure as normal for the launcher, leaving the origin at 0,0,0. fix the normals, assign a texture etc etc.

here comes the lua magic! the lua gadget has a list of units that it needs to attach more pieces to, and the locations of where to attach them.in this case it attaches missilelaunch.s3o to the barrel object of side1_missiletank. when the turret and barrel objects rotate as told in the cob of the unit the launcher turns with it.

its a bit of a hack, but its probably the easiest way until a proper system of sub-mats is implemented.

Could one of our generous lua benefactors write this gadget? A lot of people will give you much love if you do :D

[AF]

Not really you would have 1 piece say the 'mainturret' object which is an empty point, then lua would attach a mainturret piece to that 'mainturret' object, complete with animation and textures and geometry. The original unit would not be bothered about what the piece is doing unless the two are supposed to interact.

Or indeed if you wished you could just do it how you put it and replace each individual part with an external object represented by empty points.

[yuritch]

In the case of turrets, main unit NEEDS to know what pieces are there. That is needed for weapon aiming first of all.
Inter-COB communication is possible via LuaCOB, so that is solvable if the 'turret' has its own unitID.

[Argh]

Then it's a separate Unit, though, which matters for various purposes. Moreover, it'd require that that separate Unit be spawned when the Unit was first created. It'd be much better, imo, to just have these objects be non-Units that were "attachments"- Units from the standpoint of COB, but without hitsphere detection, hitpoints, or other details. Basically, they'd be a "Unit" with no details, and they would be attached to a specific null point on the main Unit.

So, for example, you'd have a tank:

unit=Tank;
etc., etc.

[Attachments]
{
AttachedUnit1=TankGun.s3o;
AttachPoint1=TurretNull;
AttachWeapon1=TankWeapon;
}

Which would then tell Spring to draw TankGun.s3o in relation to TurretNull, a nullpoint in the Unit's S3O, and to reference the scripts for AimWeapon, FireWeapon, etc., for TankGun.s3o (if present) as well as the script for the Unit itself.

Getting all of this to work shouldn't be terribly hard- we already have the vector / orientation code, we already have the attach-unit code that allows for Units to be attached to a point on a S3O, etc.

However, to get full functionality, what would be really required is a new set of specific COB functions that mirrored existing COB calls, such as AimWeapon(), StartMoving(), etc., but for attached stuff. Then the Unit, when StartMoving() would return (1), for example, would also return (1) for StartMovingAttached() for the relevant attached parts, which could then be treated as Pieces for all practical intents and purposes. This would take us away from a clunky, Frankenstein approach of actually glomming Units together, and would allow for all of the advantages of multitexturing without making animation tasks unduly complex, because these functions could be written into the Unit's COB, instead of requiring a separate COB for the "unit". I think that's the way to go here- a Frankenstein would just lead to monstrous CPU usage which would completely defeat the overall efficiency advantages of using multitexturing in the first place- basically, what we need is just a way to build multitextured models, not a whole new system.

The other approach would be to write a new model format. Which would have some major advantages at this point, frankly- we could specify that we can use a bumpmap, use alpha-trans for a blue channel, etc., etc. However, the big issue there is... er, do we have anybody who's qualified to write one that is also interested enough to do so? I mean, JC's pretty much done with Spring, and while I guess Trepan and Tobi might both be able to do something like this, I don't think they're going to be interested, unless we're going to go for the full bells and whistles, and implement some sort of IK system. I've heard various muttering about implementing Blender into Spring- I can't say I'm really excited about it, however. I'd rather have a scripted IK where i could use COB to rotate and move points, which in turn worked with the solvers... it'd combine the strengths of both approaches, and mean that we could build mechanical stuff without IK support, have organic stuff that could use COB tricks to allow for a lot of randomness and flexibility, and could combine the two approaches where it would be handy...

[Caydr]

If you guys are going to do something nuts like use this crazyass LUA model switching... thing... please make sure there are examples and good documentation. S3O/3DO's enough of a hassle...

[Pressure Line]

that would be the entire point Caydr.

ideally the LUA system would load the model and whats to be changed on it from a list. something in the form of:

Code: Select all

unitname, piecename, replacement modelname;

would be ideal. so in the case of the example of what id like that i posted before:

Code: Select all

side1_missiletank, barrel, missilelaunch.s3o

or something like that.

[trepan]

Multiple per-unit textures are already possible using the
0.75b2 unsynced LuaRules API (note the"per-unit" part,
not just per-unitDef). Model geometry can also be adjusted
on the fly, per-unit.

[Pressure Line]

HOLY CRAP!

and where in the API specifically? i had a look at the obj>lua widget, but really couldnt make heads or tails of it

[AF]

if its not documented then for all intensive purposes it doesn't exist.

[lurker]

Not just intensive purposes, but normal purposes too. And intents!

[smoth]

imo it would be far more useful to be able to specify external s3o models as objects inside an s3o, and even have the option to swap them out ingame using lua for other pieces.

This way you get the multiple uv maps you're requesting, and you also allow for a truly enormous amount of flexibility we would have otherwise missed out on, ranging from custom flags and banners on units, earth 2150 component designing of units, to extreme animations and transformations by adding and removing new premodelled geometry on the fly.

Of course one could argue that this is already possible using lua gadgets.

would be *in borat voice* very nice

[rattle]

I'd be happy with being able to split a unit up into multiple reusable pieces to keep the amount of work small.
Is it really such a drop in performance? I remember someone mentioning that.