Model texture assignment (s3o only)

[smoth]

Right now(to my knowledge) there is no way to assign a model texture that is somewhere other than /unittextures/. There is also no way to just assign a texture(as far as I know).

This gives 2 issues:
The first is that models which have alternate textures need an extra model file so there can be an alternate version.

directory bloat, having all the textures in one writhing mass in one directory.

please allow us a tag in features and unit defs to specify the unit textures.

[Kloot]

You do not need such a tag. A better solution (even though you may not like to hear it) is rendering S3O's with Lua gadgetry. That way you can assign any textures you want any time you want to any model you want, from whatever VFS directories you want.

If you want, I'll demo it.

[smoth]

doing this for every feature and unit, will it not cause slowdown?

At this point kloot, if I have to, I'll do it.

[thesleepless]

You do not need such a tag. A better solution (even though you may not like to hear it) is rendering S3O's with Lua gadgetry. That way you can assign any textures you want any time you want to any model you want, from whatever VFS directories you want.

If you want, I'll demo it.

what's the overhead of that? is that using lua to render it each frame?
or does lua just assign a new texture once and leave it to the engine to render it?
because yes it does seem silly to have the textures specified in the model, much better to have it in the unitdef IMO.
adding a tag may be annoying but it doesn't slow things down every frame.

[Kloot]

doing this for every feature and unit, will it not cause slowdown?

what's the overhead of that? is that using lua to render it each frame?
or does lua just assign a new texture once and leave it to the engine to render it?

It's using Lua to bypass the engine rendering pipeline a bit. The engine still does all the drawing, just with different textures bound. There is no overhead that you could measure involved.

because yes it does seem silly to have the textures specified in the model, much better to have it in the unitdef IMO.
adding a tag may be annoying but it doesn't slow things down every frame.

Having the textures pointed to by tags is not really more flexible, since models are still specified per-unitdef. It saves a bit of disk space (no duplicated .s3o files), but multiple unitdef.{fbi, lua}'s IMO aren't any better.

[smoth]

I am willing to try the solution kloot.

[thesleepless]

Having the textures pointed to by tags is not really more flexible, since models are still specified per-unitdef. It saves a bit of disk space (no duplicated .s3o files), but multiple unitdef.{fbi, lua}'s IMO aren't any better.

not really sure what you mean.
each unitdef represents one unit so there's nothing extra there.

you can use one model for multiple units with different textures without any overhead.

one unitdef for each unit
one texture for each unit
all using one model

[zwzsg]

You do not need a RTS engine. At this point all you need is a Lua interpreter.

[Kloot]

smoth: PM'ed.

sleepless: the point is that you would have to introduce new copypasta unitdefs just to assign variant textures, ie.

// unit_red.lua

Code: Select all

mdl = mdl.s3o;
tx1 = red.png;

// unit_green.lua

Code: Select all

mdl = mdl.s3o;
tx1 = green.png;

// unit_blue.lua

Code: Select all

mdl = mdl.s3o;
tx1 = blue.png;

for otherwise identical units (presumably the biggest use case), so tags would be trading one inelegant mechanism for another.

zwzsg: try to come up with some fresh snippets of sarcasm, that one is getting particularly old. (Not that it was ever funny to begin with.)

[thesleepless]

smoth: PM'ed.

sleepless: the point is that you would have to introduce new copypasta unitdefs just to assign variant textures, ie.
...
for otherwise identical units (presumably the biggest use case), so tags would be trading one inelegant mechanism for another.

Okay i see your point, although I think duplication the unitdef is better than duplicating the whole model (unitdef is also much easier to change)

In this case what i propose is a way to programmatically create units!

rather than needing a unitdef for each unit. we can use a lua loop to create similar units.

have a unitdef structure that can be passed to a createunittype function...

Code: Select all

for i = 1,3 do
  if(i == 1) then
	  UnitDef.name = "GreenUnit"
  elseif(i == 2) then
	  UnitDef.name = "BlueUnit"
  else
	  UnitDef.name = "RedUnit"
  end
  UnitDef.texture = "unitTex" + i + ".dds"
  CreateUnitType(UnitDef)
end

also being able to modify the unitdefs ingame? (is this already possible)?
that way we could have damage textures amongst other things

[trepan]

1. You can use lua "class" OO techniques to generate a large
number of similar unitDefs easily. The gamedata/system.lua
file even contains reftable() to show you the way...

2. Per-unit damage textures can already be accomplished using
the lua based LOD rendering setup, iirc.

[smoth]

this particular request really has more to do with me organizing files than anything else . However, because I realized it was useful for other things as well I decided to make the request.

Kloots lua definitely answered that question and gave me a way to do what I wanted.

[KDR_11k]

1. You can use lua "class" OO techniques to generate a large
number of similar unitDefs easily. The gamedata/system.lua
file even contains reftable() to show you the way...

Reminds me, can we "duplicate" the COB files for that?

[Forboding Angel]

care to share that lua?

[yuritch]

Reminds me, can we "duplicate" the COB files for that?

There was a talk of adding a CobFileName tag, and I see there is such a parameter in UnitDef.h now, but looks like it's not used anywhere else in the code... At least that's based on current source in git.

[Tobi]

'script' is the tag.

Code: Select all

	ud.scriptName = udTable.GetString("script", unitName + ".cob");
	ud.scriptPath = "scripts/" + ud.scriptName;

[KDR_11k]

cool, thanks.

[SpikedHelmet]

I would like this as well.
Using a more fleshed-out lua code would allow for more cool things like models using multiple textures (which someone, I believe PL, showed a long time ago), changing a texture during the game, and even adding/removing/changing decals maybe even!!!

[smoth]

would be nice and IMO should be part of the unit def. While kloot's solution works I still feel the engine should handle this better.

[CarRepairer]

+1

I have encountered this as well. I am not bothered by the extra S3Os causing filesize bloat as they are small, and even the managing of large amount of files is not so much concern to me. My concern is it's a pain to set up and maintain in upspring.