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.
Last edited by smoth on 24 May 2012, 15:41, edited 2 times in total.
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:
Quote:
[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
Pxtl wrote:
With the GL approach, will secondary things be aware of the model? Like selection halo widgets? Shadows?
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.
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 :).
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).
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.
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?
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.
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.
SpliFF wrote:
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.)
Users browsing this forum: No registered users and 2 guests
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot post attachments in this forum
Home
Download
Login
Register
FAQ
Search
