Attaching *models* onto *units*

[smoth]

This is a thread about:
Attaching models to units.

You will be reported if:

• - you post about trying to attach a unit to a unit.
  - you post about show hide pieces on a model.
  - you derail the thread.

What I will not discuss here:

• - your ideas on gameplay
  - what I am executing with this code

It is pathetic that I have to preface a post like this but you guys largely have no self control.

Here is what I am trying to do:
I have a unit, this unit has an empty node which I want to attach a model to. I want the model to work as though it was a regular piece on the unit.

[smoth]

What I know currently
Jk has given me some code to do this using a piece from one unit and attaching it to another.

notes from a conversation:

[1:39:03 PM] <smoth2> jk
[1:39:24 PM] <smoth2> what is your opinion on me trying to attach models to units
[1:39:36 PM] <smoth2> I was thinking that you do polies for stuff like lups
[1:39:46 PM] <smoth2> so maybe it won't be too expensive?
[1:46:37 PM] <[LCC]jK> attach models to units?
[1:50:47 PM] <smoth2> yeah
[1:51:01 PM] <smoth2> like say I want to use a different model for the barrel on a tank
[1:51:31 PM] <smoth2> and attach said model to the tank barrel object of the tank(which would be an empty object)
[1:53:44 PM] <smoth2> say like the guns on the top left
[1:53:44 PM] <smoth2> http://img820.imageshack.us/img820/7091/armor1.gif
[1:54:10 PM] <smoth2> I have an empty object on the arm where the gun will go
[1:54:19 PM] <smoth2> and want to attach the weapon model
[1:54:53 PM] <smoth2> I would only move the gun by moving the point it is attached to
[1:55:00 PM] <smoth2> thoughts?
[1:57:17 PM] <smoth2> fucking weblobby
[1:58:10 PM] <[LCC]jK> you could just replace the dlist
[1:58:46 PM] <smoth2> even if it is a model using a different texture?
[1:58:54 PM] <[LCC]jK> the other barrels still need to be features or units to access their dlist, but you don't need to really create an unit
[1:59:17 PM] <[LCC]jK> even then you could swap the texture with dlists
[1:59:38 PM] <smoth2> what if it is a different texture than the modeling I am attaching?
[1:59:52 PM] <[LCC]jK> http://springrts.com/wiki/Lua_UnitRendering
[2:00:04 PM] The time is now 2:00:04 PM
[2:00:31 PM] <[LCC]jK> Spring.UnitRendering.SetMaterialDisplayLists -> swap the texture in those 2 dlists (they get called before and after the piece)
[2:00:49 PM] <smoth2> oh so the attched piece can use a different source than the parent?
[2:00:56 PM] <[LCC]jK> and replace the dlist of the piece with Spring.UnitRendering.SetPieceList
[2:01:03 PM] <[LCC]jK> yup
[2:01:09 PM] <smoth2> how do I attach the model piece to another model?
[2:01:21 PM] <smoth2> oh
[2:01:26 PM] <smoth2> I grab the piece from one unit
[2:01:31 PM] <smoth2> and attach to another?
[2:03:51 PM] <[LCC]jK> yup
[2:04:10 PM] <[LCC]jK> but it seems you need to create an unit with the new model once ...
[2:04:32 PM] <smoth2> so I need to have a rack of guns somewhere on the map lol?
[2:06:36 PM] <smoth2> so if my gunrack dies?
[2:06:43 PM] <[LCC]jK> nah you just need it for an infinitesimal period
[2:06:52 PM] <[LCC]jK> to create the dlist
[2:06:56 PM] <smoth2> ah
[2:07:01 PM] <[LCC]jK> after that you can destroy the unit again

With the GL approach, will secondary things be aware of the model? Like selection halo widgets? Shadows?

yup

Flozi has tried this before but ran into issues.

[FLOZi]

The old trepan / Pressure Line thread: http://springrts.com/phpbb/viewtopic.ph ... bj+texture

I strongly suggest you don't go down that route though.

The way jk suggests will be much nicer for the game dev to handle. There's no reason it can't work - I simply didn't spend that much time on it and my graphics coding is atrocious. My intention for S44 was first AA guns for US tanks and then possibly crew for open vehicles / ships.

Honestly I had forgotten all about it, would still be interested in working on this.

[smoth]

I will be fiddling this weekend on it(baring personal business) so I will do my approach to getting the basic attach working and you can do your attempt. I suspect by doing this then comparing notes we may finally put this long requested feature to bed :).

[bobthedinosaur]

edit: never mind! the map mod i was thinking of was made by fatcontroller and it did not use gl draw (not helpful)... ignore me.

it looks like no one has had a working version of this gl draw just yet?

[SpliFF]

Just be aware that even if you copy a displaylist off another model like jK suggests all pieces of the model will be rendered with the same texture. If you go the Pressureline approach and render the list yourself it will be tricky to match the piece transform and even if you do you will have issues with self-shadowing, cloaking effects and performance.

If this is going to be done it really should happen engine-side. Although it is a much requested feature (multitexturing) it has been rejected before for performance reasons (switching textures is expensive).

To summarise, your best solution right now is Spring.UnitRendering.SetPieceList and a shared texture atlas. A better longer term solution would be unit multitexturing on a mod-selectable or unit-selectable basis (so mods/units that don't require multitexturing aren't hit with a performance penalty).

[jK]

jK suggests all pieces of the model will be rendered with the same texture

read the chatlog

[SpliFF]

Oh right, missed that. Wouldn't that approach trash framerates or does it preserve batching of displaylists by texture (i haven't seen the code)?

[smoth]

if you are talking about code for a gadget, flozi and I have not written it yet. Been a really rough week and best I can do when I finally get home is play towerdefense for an hour and go to sleep.

Hopefully spliff I can test it tonight.

[Pxtl]

Am I the only one confused why this isn't an engine feature? I mean, we've got much more trivial, lua-able stuff hard-coded into the engine... while something that's a core rendering system is left to be hacked out in lua?

[SpliFF]

I can answer that one. The rendering system has for a long time been rather inelegant. For example, features were calling into unit rendering classes. Some cleanup has already taken place and I'm sure more will come but it does make adding Lua interfaces a bit awkward.

There is defineately a desire out there for more generic model and texture handling capabilities. In particular it shouldn't be necessary to actually create a unit to get at the model and texture data. Right now it isn't so much a Lua issue as it's more about model creation being a bit too integrated into the unit creation code.

[smoth]

Current tasks:

• LRN 2 DISPLAYLIST
  gl draw stuffs
• attach DISPLAYLIST
  Spring.UnitRendering.SetPieceList (displayList=nil reset to default)
  ( number unitID, int lod, int piece [, number displayList = nil ] ) -> nil
  AKA ( target, unknown, targetPiece, distplaylistofpiecetoadd)

[Pressure Line]

If i get some time over the weekend I may try to code out something I've been thinking about that should be able to do this, no promises though.

If you go the Pressureline approach and render the list yourself it will be tricky to match the piece transform and even if you do you will have issues with self-shadowing

I didn't have problems with either of those (in the latest revision of my work.)

[Pressure Line]

Got a preliminary version working based off the work I did in 2007. Will make a demo of it tonight, and post some screens :D

[FLOZi]

If it still requires obj2lua i'm sorry but it is worthless. Here's hoping it does not.

[Pressure Line]

Nah, it's actually good, uses s3o models. I just ended up spending too much time setting my main PC back up for Springing last night.

[FLOZi]

Then colour me excited

[Pressure Line]

Screenshot



I just attached the tank model (didn't have any other models handy) to the barrel

will need a bit more work to be actually useable

[Pressure Line]

First test version now available!

But do be aware that it wasn't written in a current version of Spring

[Pressure Line]

Will update tomorrow and try to get a better demo unit, as well as adding in shadows, and possibly a new config format for better flexibility.