Attaching *models* onto *units*

[smoth]

For what I am doing, lua rendering it the way you are doing is not useful. This thread is about a specific approach.

[Pressure Line]

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.

done.

I want the model to work as though it was a regular piece on the unit.

done*.

*you can do everything except show/hide or explode the drawn piece. all translations and rotations that affect the node the model is attached to are preserved.

For what I am doing, lua rendering it the way you are doing is not useful. This thread is about a specific approach.

I'm not sure I understand. v4 does (almost) everything you requested in your first post (inasmuch as the external model needs to act as if it is part of the original model) The fact that I am attaching the tank model onto the end of the barrel is solely due to the fact that I did the coding on my netbook, which doesn't have the tools installed for me to make a proper test model and texture it.

[smoth]

Perhaps jk can explain it better.

[FLOZi]

Perhaps you can? PL's code is the simplest implementation possible, putting possible performance issues aside, what doesn't it do that you require?

[gajop]

Skimming PL's code a bit it seems it only draws unit models on top of unit models (i.e it draws unitdefs that are 'attached' to certain units), didn't bother to read it all though.

Btw, smoth, are those attached models of yours supposed to be doing any sort of collision or other interaction with other objects, such as bullets, units, or the world?
Because if not, you probably don't need any more complex implementation than what PL's showing. Not even sure if performance is an issue if you can live with those *models* being unitdefs, at least formally (but hey, you don't mind hacking stuff so that unintended use isn't a problem :))

[smoth]

Perhaps you can? PL's code is the simplest implementation possible, putting possible performance issues aside, what doesn't it do that you require?

Would have to look into if it was compatible with jk's normal shader. As I have some custom shader stuff I want to do.

I have not had the chance to look at his code, did he change it from the old stuff that greatly?

[knorke]

lost my post, short:
Tested and worked. (in current version of spring)
Neat!

Could not get it work in my mod when copying over the stuff. (no errors, nothing showed up, i edited the config thing to use my unitnames)
Needs changes in gadgets.lua or other such files?

Btw would this also work to add transparent pieces to units?
I was testing that a while ago but in a much lamer attempt (4 empty pieces on model and draw a quad between=zomg glass window)
But yours might work for real transparent cockpits and such?

Skimming PL's code a bit it seems it only draws unit models on top of unit models (i.e it draws unitdefs that are 'attached' to certain units), didn't bother to read it all though.

I think the files in widgets\ are for drawing "real" extra pieces instead of "fake unitdef pieces"

[Pressure Line]

yeah, the widgets are tests from ~2007, using a custom model loader that trepan wrote.

I will remove them from the next test release.

Yes knorke, it *could* do translucency, but I have more pressing issues (like coding for multiple extra pieces at once)

[Pressure Line]

New version 4.1

Minor change to config file & config loading to enable more than one add-on piece to be drawn.

Todo:

Make a better test package!

[FLOZi]

Perhaps you can? PL's code is the simplest implementation possible, putting possible performance issues aside, what doesn't it do that you require?

Would have to look into if it was compatible with jk's normal shader. As I have some custom shader stuff I want to do.

I have not had the chance to look at his code, did he change it from the old stuff that greatly?

Ah yes, that would be a problem.

[Pressure Line]

Could not get it work in my mod when copying over the stuff. (no errors, nothing showed up, i edited the config thing to use my unitnames)
Needs changes in gadgets.lua or other such files?

It needs a customparam in the unitdef, "unitdraw" (any value will work,its only used for an 'if(customparam:unitdraw != nil)' check) I probably should have mentioned that earlier

[knorke]

oh, i did not scroll down that far
hooray the tank-helicopter!

[Pressure Line]

Gonna have a crack at using Spring.UnitRendering to do this tonight. I'm just not sure whether I should load all the DLists at gamestart/gadgetinit or one by one at UnitCreated. I feel there are pros and cons to each approach:

GameStart:
pros:
all over and done with in one hit
cons:
possibly high memory use+waste from loading [potentially] many DLists that arent being used

UnitCreated:
pros:
probably lower memory usage (only Dlists that are needed are created)
cons:
possible cpu/gpu use spikes when the DList is loaded
having to do more checks to make sure lists aren't duplicated

anything I have missed? suggestions?

[knorke]

I guess it depends on the game this is used for?
eg do you have lots of different "pieces" but only a few will ever be used at the same time?
(say zK commanders, with each players commander picking 1 "weapon piece" out of over 9000 available)
Or are there only a few pieces but many instances of them will be used at the the same time? (say a spammable tank that you can equip with a radar)

[smoth]

I prefer as needed, should there be a situation where there are A LOT of options, if you load it all at game start

1: gpu memory suddenly becomes an issue
2: you stand a chance at triggering hand detection
3: you absolutely will load more than you need, I doubt that there will ALWAYS be a need to have more than 80% of the units built out.

[SinbadEV]

It would be ideal if you could asynchronously load the extra model and texture into memory while you are performing the upgrade that adds the new object... this stuff shouldn't need to be synced as it's an entirely visual change.

[zwzsg]

2: you stand a chance at triggering hang detection

Use Spring.ClearWatchDogTimer()

[Pressure Line]

I prefer as needed, should there be a situation where there are A LOT of options, if you load it all at game start

1: gpu memory suddenly becomes an issue
2: you stand a chance at triggering hand detection
3: you absolutely will load more than you need, I doubt that there will ALWAYS be a need to have more than 80% of the units built out.

This. Definately going for on-demand loading.

Current status!
Complete:
model loading
displaylist generation

To Do:
figure out why UnitDraw wasn't working last night
sanity check for loading models and generating displaylists (don't generate the same one twice)
comment code!

I guess it depends on the game this is used for?
eg do you have lots of different "pieces" but only a few will ever be used at the same time?
(say zK commanders, with each players commander picking 1 "weapon piece" out of over 9000 available)
Or are there only a few pieces but many instances of them will be used at the the same time? (say a spammable tank that you can equip with a radar)

In the case of the ZK commanders, it wouldnt matter if the gadget loaded the models at gamestart or when the unit is created because commanders are created at gamestart anyway. For that implimentation, the code would need to be modified so that it loaded the model/DList when the upgrade is selected, the current coding will only really work for units with a static need for 'extras'

eg: E&E units which have a common chassis but different turrets and weapons, but each unit retains the same model from the moment of creation to the moment of destruction.

In E&E I could use lvl1tankchassis.s3o as the base of the unit which is the model defined in the unit fbi/lua, set up with just the chassis of the unit, and empty point objects for the turret, barrel and firing point. Then in an s3o called lvl1tankturrets.s3o I have all the turrets and weapons used by the lvl1 tanks. in the config i write:

Code: Select all

lvl1cannontank={"lvl1tankturrets","cannonturret","turret"},{"lvl1tankturrets","cannonbarrel","barrel"},
lvl1missiletank={"lvl1tankturrets","missileturret","turret"},{"lvl1tankturrets","missilebarrel","barrel"},

[where the format is {"ModelSourceUnitDefID","ModelSourcePieceName","TargetPieceName"}]

which sticks the cannon turret and barrel on the cannontank and the missile turret and 'barrel' on the missile tank.

[scifi]

Someone give this man a cookie!

testing this stuff atm

[Pressure Line]

Not too much point testing at the moment, the gadget design has changed massivly from the last posted version (4.1)