Page 1 of 1

Model texture assignment (s3o only)

Posted: 13 Jun 2009, 16:57
by 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.

Re: Model texture assignment (s3o only)

Posted: 13 Jun 2009, 17:17
by 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. ;)

Re: Model texture assignment (s3o only)

Posted: 13 Jun 2009, 17:20
by 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.

Re: Model texture assignment (s3o only)

Posted: 13 Jun 2009, 17:22
by thesleepless
Kloot wrote: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.

Re: Model texture assignment (s3o only)

Posted: 13 Jun 2009, 17:37
by Kloot
smoth wrote:doing this for every feature and unit, will it not cause slowdown?
thesleepless wrote: 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.
thesleepless wrote: 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.

Re: Model texture assignment (s3o only)

Posted: 13 Jun 2009, 17:44
by smoth
I am willing to try the solution kloot.

Re: Model texture assignment (s3o only)

Posted: 13 Jun 2009, 17:59
by thesleepless
Kloot wrote: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

Re: Model texture assignment (s3o only)

Posted: 13 Jun 2009, 19:05
by zwzsg
You do not need a RTS engine. At this point all you need is a Lua interpreter.

Re: Model texture assignment (s3o only)

Posted: 13 Jun 2009, 20:53
by 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.)

Re: Model texture assignment (s3o only)

Posted: 13 Jun 2009, 22:55
by thesleepless
Kloot wrote: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

Re: Model texture assignment (s3o only)

Posted: 13 Jun 2009, 23:39
by 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.

Re: Model texture assignment (s3o only)

Posted: 14 Jun 2009, 00:06
by smoth
this particular request really has more to do with me organizing files than anything else :P. 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.

Re: Model texture assignment (s3o only)

Posted: 14 Jun 2009, 09:19
by KDR_11k
trepan wrote: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?

Re: Model texture assignment (s3o only)

Posted: 14 Jun 2009, 09:26
by Forboding Angel
care to share that lua?

Re: Model texture assignment (s3o only)

Posted: 14 Jun 2009, 13:11
by yuritch
KDR_11k wrote: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.

Re: Model texture assignment (s3o only)

Posted: 14 Jun 2009, 13:48
by Tobi
'script' is the tag.

Code: Select all

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

Re: Model texture assignment (s3o only)

Posted: 14 Jun 2009, 14:33
by KDR_11k
cool, thanks.

Re: Model texture assignment (s3o only)

Posted: 02 Jul 2009, 05:22
by 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!!!

Re: Model texture assignment (s3o only)

Posted: 02 Jul 2009, 06:16
by 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.

Re: Model texture assignment (s3o only)

Posted: 02 Jul 2009, 17:21
by 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.