Texture sharing

[DoctorFoo]

Apologies if this has been mentioned elsewhere or is redundant, but helldiver (creator of the excellent Kerbin Shuttle Orbiter System) has run into some very frustrating snags with Phases II and beyond of KSO:

From http://forum.kerbalspaceprogram.com/threads/68429-0-23-Kerbin-Shuttle-Orbiter-System-v1-13-aka-Kerbin-Mini-Shuttle/page157

"Having to copy textures that are shared by multiple objects was it for me (and yes if it weren't for Naz doing some workarounds, each station module would have had its own internals folder with copies of the same texture file), which pardon my French but is bull**** and demonstrates total lack of proper experience, design, and quality control on behalf of Squad. This needs to be priority number 1 before spending a dime on NASA inspired DLCs.

If you guys would like more quality free mods made by me, you guys as a community will have to request from the Developer the following:

-Textures must be able to be shared by multiple assets regardless of their designation, whether they are a prop, internal, or external. Preferably a dedicated Textures folders the way Skyrim and pretty much any Mod friendly game does it. This helps the issue of having to repeat the same texture on assets that share it. As it is right now (I've never seen an engine do such an inefficient and absurd method) each part must have its own Internals folder, and even if the same texture is shared, a copy of that texture must be in that internals folder, and a copy of that texture gets loaded into memory (I can't confirm that). That is absolutely absurd.

-Texture and Asset memory management. Folks are already cutting parts and mods off. An argument could have made that all the Phases in the KSOS could have been separate. But guess what? The savings you would have received by having it separate wasn't that much since all the parts shared the same textures. However, because of the way that KSP is currently configured, you would have had to re-download and install all textures used by the other phases shared by each other anyhow.

-Internals should be treated like any other object. Allow us to specify directly where the Internal geometry's textures are located.

-A workaround for texture lookup could be a Unity KSP export tool that allows the modder to designate specifically the location of an object's textures. The asset will always look in those folders first and then check the default folders if it doesn't find its texture. Alternatively, KSP should use a Textures folder with a part subdirectory. Modders place textures here and point to them in their exporter.

In the end these suggestions help everyone:

-Squad wins because it means more quality mods out there. It makes their own asset scalability and production cheaper and efficient.

-KSP owners can have more mods installed in a game lacking content.

-Modders have an easier time getting their mods to work on a variety of systems.

I have zero interest on further phases. That includes Phase III which includes the larger 2.5meter KSO, why? Because it shared assets from the first KSO and the other phases. Unfortunately that would mean having copies of the largest files (such as the cockpit textures) inside the internals folder of the Super 25. Same goes for the moon lander and pretty much any other IVA'ed object I create. And as you all know, my goal is primarily IVA'ed spacecraft and spacecraft components. I have very little interest in flying lugs, which sadly the SST has now become. "

I'm not a programmer or a KSP modder, but a long time ago I was heavily involved in aircraft texturing for MS Flight Sim 3rd party aircraft, so I do somewhat understand the issues at hand but only to a limited degree. KSP has a relatively short ceiling for modding at this time, and while it technically is still in Alpha, there is a risk of losing out on some amazing potential content with this current limitation. Correcting this sooner rather than later would prevent the communty from losing such skilled modders as helldiver and his associates.

[mostlydave]

Yeah, what the flip Squad? I don't think it's too much to ask for you to start showing the modders that making your game great some serious love.

Please for the love of all that's holy quit adding stuff to the game until you've got your house in order. Doctor Foo is 100% dead on, you're losing awesome mods left and right due to these issues.

[TerLoki]

With all the content that the 0.24 update and NASA pack are bringing, 0.25 seems like the perfect time to slow down and do some optimization work like this. And surely it wouldn't just be for improved mod support, something like this would almost certainly improve the stock game as well, particularly internals where a lot of controls and displays are shared between parts.

[helldiver]

Repost of the image I posted in the KSO thread

But Helldiver, can't you just break up everything into a bunch of props?

-No for several reasons. I use the same production pipeline used in triple AAA titles. This makes producing all the stuff fast and efficient. Don't like that the color of the SST is yellow? In one two seconds that's fixed. Need a better Specular? Generated in a matter of minutes. By having one large object on one UVW, I can produce all the needed baking in just a few passes.

-I am able to bake the lighting into the internals so it looks like everything belongs there. If things were individual props, it would take much longer to reproduce that. Additionally Nazari would have to place each prop more or less. This current method makes it much faster to do all that (a mater of days instead of weeks) and when Nazari gets it to put it in game all he has to do is assign texture, do the plugins, and export.

-Had the KSO been separate props, the size of the installation would have ballooned to near double the size. By having a single texture we can compress that (using the texture compression mod) or do what ever. Individual prop textures would have actually added up to much larger than a single 2048x2048 (keep in mind that what makes the large one look good with some loss of visual clarity are the shadows baked in).

Can't the KSO Super 25 (Phase III) be a separate download?

-Yes, and if I muster up the enthusiasm to do it, it will be separate. However, the majority of folks are like me, they're going to want both the KSO and the KSO Super 25 (KSO for their normal service missions, Super 25 for hauling the large 2.5meter components). That means we're back to the problem at hand; i.e. copies of Cockpit_Interior.tga in KSO/Spaces/InternalKSO and KSO/Spaces/InternalKSOS25. Nazari can't simply point the Super 25 to the KSO's internalkso files because the Super 25 for being bigger has a different IVA (not that different, but enough to need its own MU file). The savings for -you- was in reusing the textures. Which has been lost do to this moronic method of handling texture data.

[frizzank]

A workaround is make your interior part of the exterior, then only the camera and the seats are in the interior .mu file. The interior view doesn't occlude or throw away anything while in interior view so the performance impact is dependent on the complexity of your IVA.

I think this is just one of many optimizations that need to take place (A lot of the stock components could share textures). That being said, the community as a whole throws a temper tantrum when new content is not apart of an update. The reason for that is that most are consumers of mod content rather than producers. I would also like an update to be focused on optimizations and performance, specifically better handling of mods.

KSP modding is far from perfect but in my personal opinion it is doing a pretty good job compared to other games.

[vger]

Every custom asset needs its very own texture files and can't share them with other assets? You've got to be kidding me. Yes, change this.

[Payload]

Are we sure that a copy of the texture is being used? If the file has the same name it seems to me that KSP would just use the one that is in memory already. Though, I actually have no idea how KSP works on an engine level. If indeed we are getting something like TexIVA.TGA being used for internal of one shuttle and then another TexIVA0001.TGA being used for another shuttle IVA, with both files loaded into memory, then that would be a bad thing.

However, if both are using just the latest file to be loaded into memory then what we are really talking about is a SOD issue and it's not really of much concern.

With a centralized texture folder, I can see using a lot of smaller seamless textures for all things and not just IVAs. That saves a lot of black space. Currently, my textures have to be a lot bigger than I would like. I feel that no matter what I do, my use of them is in-efficient at best.

I think before we get our panties in a bunch over this, we need more information about how this is handled by the actual game. Maybe this isn't so much a Squad problem as it is a Unity one.

[Nuke]

i recently figured out how to share textures between multiple parts in my mods. i have 4 wing parts that all share one texture. i also had a set of structural parts, each one having a copy of the same texture, which i have resolved. its certainly possible to do this. it may just be that the artists at squad are busy with other stuff and have yet to go through and optimize all the old assets. or perhaps it still has some bugs that need to be resolved and they are being directed to not use it pending some bugfixes. it also seems that the devs would want assets needed to test new features that they have implemented would take priority. i think this may be one of those cases where the community's need for new stuff is taking time away from older stuff that needs to be worked on.

saying that they are being negligent is kind of an overreaction. this is a game in development and as such it is expected that some things would be in a completely unpolished state. now if this game was declared final tomorrow, i would have words to say.

[Frank_G]

Optimizing too early kills every project. Graphics can be optimized when there is a clear look on what will make it into the final gameplay. Currently there isnt even a clear graphical style established... Far too early for optimizations.

[Daemoria]

i recently figured out how to share textures between multiple parts in my mods. i have 4 wing parts that all share one texture. i also had a set of structural parts, each one having a copy of the same texture, which i have resolved. its certainly possible to do this.

Would you mind sharing your method to achieving this?

[Justin Kerbice]

Would you mind sharing your method to achieving this?

I'm interested too. Please guys, share share and share too.

And regarding issues discussed here: one point is KSP is designed and optimized for pure stock mostly (the only issue is part counts, but maybe noone at Squad have ever imagine building a 1000, 2000, 4000 or more parts vessel) as I can figured out. Mods are very welcomed but not so much backuped.

@Frank_G: doing so might kill a project, but not doing it early enough can achieve the exact same result !

I think IMHO Squad could do even release for adding features mainly (and some serious bugs fix), and odd releases for fixes & optims ONLY.

As with the incoming .24 + NASA pack, the majority of players who don't care enough about reliability and efficiency will be fed enough for quite some time, it might be a good idea to start the "dirty work" (cleaning, fixing & optimizing)

[Nuke]

i initially had trouble getting texture overloading to work. but then i just did the following:

1. in unity every material that is shared should have the same name across all models.

2. export all models that share a texture to one directory (the texture and all models that use it should be in that directory)

3. do not try to overload the textures in the cfg, i could never get that to work. this leaves me to believe that a system is being worked on, but is still too buggy for showtime.

you cant use a chair texture from one url and a panel texture from another. but you can group several parts into a single texture atlas. this is in effect the same as just using more smaller textures of smaller resolution. for example, i got 4 wing parts into one 512^2 texture, which means i could have just done 4x 256^2 textures. but it worked out because i wanted seamless uv mapping, and doing this with a long object like a wing wastes a lot of space (unless you break it up and create a bunch of seams). of course in this way i still have space for another delta wing and another control surface, since i am a really efficient uv mapper.

the first commandment of uv mapping:

thou shalt not waste texels.

Edited March 14, 2014 by Nuke

[Space_Kraken]

Eureka! You've found it! I must share this thread with all my favourite mod makers!

Edited March 15, 2014 by Space_Kraken
British Spellings :P

[Nuke]

i just filled in the remaining space with 2 more parts, so thats six parts sharing one texture. now i just need to fill in said texture with more detail than a pattern fill.

[Hurry- Starfish!]

Optimizing too early kills every project. Graphics can be optimized when there is a clear look on what will make it into the final gameplay. Currently there isnt even a clear graphical style established... Far too early for optimizations.

How many players and modders does this game have by now? It isn't even close to being "too early" anymore. Though you might have misunderstood; this isn't about graphics, but an improvement in terms of performance, memory usage and development convenience.

[Nuke]

depends on what optimizations. anything that would make the code hard to read, or would be hard to debug should be avoided until all features are fleshed out. then you can profile the finished product find the slow spots and address those. it is not time for that kind of optimization. but there are things you can. you could add some code to bitmap management to check for duplicate textures and remove the extra copy. and this might not be a coding problem, it could be an art assets problem. i can understand why bitmap management would take a back seat, especially since it works, and ksp doesn't break until you install a couple gigs of mods. i would certainly expect it to be something that would be resolved before ksp 1.0 comes out.

[RSF77]

So... assuming KSP doesn't, or somehow could be made to, not require a path for parts and whatnot (KSP/Gamdata/<mod>/<parts>/etc) then in theory could you just install every texture, model and cfg into the base mod folder (with no individual folders for things) and have everything able to use everything else there?

So we have:

Gamedata/mymod/<every cfg file>

Gamedata/mymod/<every model file>

Gamedata/mymod/textures/<every texture file>

.... and so on with every part able to use every texture, model or sound it needed? I am unsure just to the extent that the directory structure for mods is coded into KSP or where it is able to look in order to find them, but it seems like a pretty simply solution for squad or maybe even for modders if possible.

-OR-

Use one individual part folder and cfg for every part in the mod?

/Gamedata/mymod/parts/mymod/part.cfg

/Gamedata/mymod/parts/mymod/<every file for every part>

Possibly even separate .cfgs because I believe they can have unique names instead of just part.cfg, I think I remember some mods doing this. Might be pretty messy as far as file structure is concerned but maybe it could be some kind of workaround?

This is pretty much an uneducated theory and I may not be understanding something basic here, but having to load multiple copies of the exact same thing a bunch of times sounds more like some kind of virus than a game. Fixing this could be something just as simple as a file structure issue, that can't take too long to fix even if they just put one guy on it. What? maybe a day?

If I'm not mistaken the /Gamedata directory for mods is relatively new being updated for only a few KSP version ago, so maybe they intend to do it better but for some reason are just working on other stuff that IMO is probably much less important concerning your everyday KSPer or modder. Squad should probably be more serious about that seeing as a strong modding community can make a game about something as silly as cubic blocks into an award winning game. There is decades old games still active today because of this, and KSP has this potential if it is realized fully.

Edited March 16, 2014 by RSF77

[Nuke]

it doesn't matter what folder things go in. it all ends up in the game database anyway. you can find any piece of data you want with the url (which probibly gets resolved internally to a reference to make lookup faster). i think the problem is that there is a lot of subsystems in the game that still dont use all the features the game database has to offer. i would bet that bitmap management is one of those subsystems. but its just one of the millions of things on squad's todo list.