models sharing a texture.(yes this is a question for devs)

[smoth]

Ok, I am working on a model, it has several parts that could be shared by another unit. rather then use several different textures for each model, I realized I could place several units on one map saving texture space on redundant parts.

So I proposed the question, if I did this, say 4 models sharing one texture.... does the texture get loaded for each model that uses it? As in there will be 4 copies of the texture in memory? Or would it load the texture only once?

This is important both for some features I have planned and for my current work.

Thanks in advance.

[Argh]

It only loads the texture once, which is why a big DDS file causes a teeny halt when you load up a new unit the first time.

However, I think that the fillrate costs probably mean that you don't gain a lot of performance from this. Dunno, depends on the amount of overlap, probably, I'll have to look that up.

[jK]

meh argh was faster.
but the reason why you should reuse textures is not a performance increase, it is to avoid a performance _decrease_, which happens if the vram is full and textures needed to be cached in the sysram.
Also like you said loading of (huge) textures can cause a halt, so you should always try to minimize it .

[Argh]

Meh... while we're on this subject... Lua loads the textures the same way that everything else does, right? So, maybe I could write a texture preloader Gadget... do it all at GameStart... is this rational, or just a goofy idea?

[jK]

unit texture preloader?

1. trepan already wrote something like that (widget)
2. it is a bad idea (trepan says the same), cuz:
2.1 it can causes desyncs at the start of the game
(-> longer loading time -> it can take >3s until the client answers the host for the next gameframe -> solvable if you move it across multiple seconds, but then the user will see it right at the start of the game -> annoying)
2.2 it loads many unneeded textures (not all units are build in a match), so it waste (a lot) vram

[Argh]

I was going to do it as a Gadget, during GameStart. Haven't had problems <crosses fingers> with desyncs... but meh, you're right, it's probably a waste of VRAM, and older cards would get hosed when they ran outta texture memory. Nevermind, that was a terrible idea- I was hoping I'd stick them into RAM somehow, for faster fetching, but you're right, that can't happen, the Spring loader doesn't work that way

[reivanen]

If the only problem is "wasting" memory on the gfx card, then i see no problem at all. Just make it optional for people who want to use this ?

I for one would fancy one longer wait instead of the small hiccups during the game. And lets face it, if you are not running a prehistoric gfx card the memory wasting won't be an issue.

[Peet]

My 640MB 8800GTS has run out of vram in spring on several occasions.

[Das Bruce]

Just throwing this out there, but would it be an idea to have spring load units and their associated data when the thing that can build them is created? ie when a k-bot factory is created it loads all the kbots in that factory, the loading could be done during spare cycles to prevent a pause but if there arn't any it could just load them when they themselves are created, with a small pause?

Just an idea.

[AF]

That is how it originally worked.

[Das Bruce]

What was the reason for change?

[AF]

I do nto believe it did change, instead lots fo things made the engien load all units at start.

For example,a t one point the AIs started loading all the untidefs and building data structures from them, but in doing this, it sidestepped lazy loading by making the engine load everything at the start so the AIs could do work on it.

There was also the noticeable slowdown when clicking on a build icon where it would load the unit and the screen would momentarily pause.