Skin system/Multiple textures per item system for Workshop Uploads

Suggestions
1

First of all, before the actual suggestion: I don’t recall seeing anyone ever making a separate thread specifically for this - I only vaguely remember people discussing an idea like this in the past in some other posts on the forums, which is why I am the one to make a separate thread for this, and hopefully get this some more attention.

Now, for the suggestion itself: I think many people and Workshop creators would greatly appreciate having some way to add multiple skins/textures to the same Workshop object, whether that be an Accelerate vehicle, a player model, custom furniture/physics objects or other things like this. It would be really quite useful - Just add a bunch of main textures, like different colors, patterns, etc. for the same Workshop object, instead of having to upload, or subscribe to, multiple, minimally different versions of same stuff onto Workshop. Then, any player using any such custom content from Workshop would get an option to choose the skin/texture they want for an object or whatever else. Sounds like a pretty simple, convenient idea for everyone right? I have no idea how much something like this would take to implement on a technical level, but certainly everyone would benefit from this. I just made this thread because I think plenty of people would want such a thing, but not many have spoken out about it here, on the forums, that I know of at least. Soo, yeah, that’s it - That’s the suggestion. Vote if you agree, post a response if you wanna discuss any aspect of this, the usual stuff.

2

i dont see anyone replying to this, i highly agree with your suggestion, regarding the possibility to give all the props and PM the ability to have included in their file additional texture variants or even bodygroups… this is something that should have came with the basic Workshop Introduction but it’s being sadly overlooked, i hope more people find this post and vote it for the chance to have it in a soon-to-be patch.

1 Like
3

Thank you a lot! I’m glad to see at least some support. I also think this should have had come when Workshop came out at first, but I mean hey, if it comes now, it’s better late than never. If Tower devs consider this, it will be great. I’m already imagining people just being able to right click a Workshop item that’s spawned in and choose skin from a context menu the way Garry’s Mod does it, or in some other way.

1 Like
4

you have my full support on this idea. ill try to share it whenever i can

1 Like
5

The only issue with this is the workshop isn’t necessarily refined.

Workshop uploads have limitations for a reason, it’s to prevent large-scale models from borking down PCs, as TU uses a custom system to stream them in. This is why condos that use a lot of workshop items tend to be more bogged down in terms of FPS and loading times because the game has to actively subscribe, download, and unsubscribe multiple items at once, even if there’s a large number of Duplicates. Its the same for canvas data, albeit not as severe.

Multiple skins may be possible, but you have to be aware that adding those skins (plus any added normal/bump that goes with them) may increase the amount of data that workshop items have and can thus cause further issues.

Ultimately, it may be possible, but keep in mind it’d be a while before this could be tackled.

2 Likes
6

While I wasn’t aware of how everything related to Workshop system works technically in such detail that you provided, I do still believe it would be better if a system like this was in place, rather than not - By this, I mean the skins system. Although, now that you have made a sort of technical explanation on how Workshop stuff functions, it actually raises some rather important questions: Why go through all of this custom system nonsense? Sure, it may probably work better with their code rather than the pre-built solutions, but if the game actually has to actively load everything in, whether that be Workshop objects or Canvases, it really is no surprise that it’s struggling - Which, I should note, isn’t a sign of a solution that’s good, and instead one that should probably be replaced. For Canvases at least, there’s the Cache system, but if the game always has to subscribe and unsubscribe to items or data of Canvas images when you load in to a Condo regardless of that system, that’s just kinda pointless - It would have had been more beneficial and likely way more efficient to also make use of a Cache system of some kind - Save Workshop objects in a Condo, regardless of how many there are and regardless of level of detail that they might be in, once they are downloaded one time, and then load them from a file on a user’s machine. The current solution PixelTail uses just sounds incredibly ineffective and restrictive because of how poorly it is implemented, not because the large-scale or super detailed models themselves are a problem. Sorry, a bit of a rant I suppose, but I just hardly see the point of not sacrificing some storage on a user’s drive in exchange for better performance and faster loading times of Workshop objects and instead for always loading and unloading everything. Again, I’m sure there’s a reason for why they are doing things the way that they are, but by the sound of things and how everything is being handled right now, I do also believe that a future Workshop update focusing on reworking this whole mess of a system should be one of the next Workshop related top priorities. Having something like this in a full game, and we are slowly heading towards 1.0 release, to put it simply, just doesn’t sound like anything that’s going to work well long-term. Again, sorry for the rant, but I just had to bring it up when you put out this explanation of things, since what they are doing right now never made much sense to me.

7

The system has been improved in multiple ways over the years. It’s extremely robust.

Workshop is done in real time, meaning the content is downloaded in real time and loaded in real time.

This is done because we believe in having workshop player models be accessible in game, and players can click and instantly see them. Other Workshop implementations require you to restart the entire game for each new model.

Our workshop system is custom made. There is no way to dynamically load in skeletal meshes (player models) or static meshes (items) in Unreal Engine 4. This is technology we made ourselves.

Our system has to subscribe and unsubscribe because we use Steam workshop. You cannot directly download from Steam workshop without massively hitching the game, so we use subscribe which has no hitch to it. You also can only download one model at a time, a Steam limitation.

We definitely cache workshop models once they are downloaded. Once they are downloaded, they are stored in a cache folder, just like canvases. We also cache them in memory (not all of them, a reserved amount of ram cache).

Once cached, we skip the subscribe and unsubscribe system completely and models load in. We do ping Steam workshop to check for any updates to the model as well.

This entire system is asynchronous and highly threaded.

The concern Alexer_Zoderia brought up is that workshop models are not always optimized by the author of the workshop model. As such, some authors do not compress their textures as much as they should.

The other concern is that when you have multi-body support, you will have to download all the bodies at the same time. You would also need to load in the body data in real time. It would be the same as loading two player models. This applies to workshop condo items as well.

Adding colorable materials is not a concern, but adding new body types means more model data to load in real time.

3 Likes
8

Alright, very sorry for making a lot of assumptions about how things worked and their efficiency - I can definitely say that much. What I will say though, is that while I certainly can see some of the benefits for actively subscribing and unsubscribing to things, I am still led to believe that doing it every single time dynamically is still a worse off solution than even a dated engine like Source 1 offers for games such as Garry’s Mod. The concern that you and Alexer bought brought up is both reasonable as well, but I believe still at least slightly exaggerated - I can definitely get behind optimization problems of custom models and everything, but even with everything laid out, I do not believe that a system like this is truly going to be better off for a complete game like Tower past 1.0 - It’s not something that would cut it for plenty of bigger games and teams, that much I’m relatively certain of, and even with optimized models, it’s still a struggle for everyone involved. The concern brought up, while I’m sure it is real, only really stems from the way the current system is implemented, even for all of it’s advantages. Regardless though, even though I don’t exactly agree with the way everything relating to Workshop support development is going, I do have to thank you for the detailed response and taking the time on writing it - The system in place, as already said before, does work pretty well for all of it’s problems - It’s just that it could have had been done a bit better in most aspects.

1 Like
9

You simply can’t have it any other way though. Either you dynamically download in real time and display the workshop models in real time like we do now. Or you require players to have to search and find which player models they want to see, then have to restart the entire game each time they want to use a new player model.
You’d also have to make sure you’ve manually downloaded the workshop models for everyone else.

Given how much players change and browse for player models in Tower, requiring them to predownload player models then restart the game would be game breaking and no one would be able to change their player model in the Plaza. I would even argue that players would not even use workshop at that point.

It also doesn’t always subscribe and unsubscribe each time. It only does that if you haven’t downloaded it before. The cache system will skip that step, similar to when you pre download a workshop addon from another game.

Also, changing it doesn’t solve the fact that workshop authors don’t always optimize their work - that just happens occasionally with user generated content. We could continue to inform authors to reduce texture usage a bit more, but ultimately an author could ignore everything and upload something unoptimized.

3 Likes
10

No problems, I think I understand at least a little bit better now. I may not agree with many things about the current system, and I don’t think anyone can really say that it’s perfect either, but it works for what it is and for the purpose you guys are using it for. I only really wish that, aside from having Workshop model authors optimize their models and textures, which is it’s own thing that, as you say, you can’t guarantee will even happen with all of them, it would have had been somehow made less straining on everyone by just adjusting how it works in some way internally. One way or another though, I do appreciate the time you guys are using up on all these answers - It’s not often that developers spend that much of their time on communicating with their community to this extent and generally taking active part in it so much, so it does mean a lot that you guys are different on that front, and that’s even when communication with your community might not always be the easiest.

1 Like
11

You’re very welcome, and we’re always trying to find ways to improve the system. It’ll keep getting better, I remember the early implementation, we didn’t have threading, or a lot of the async stuff we have today. If we find that workshop improves how their downloads work one day, we’ll switch over to using that method too.

2 Likes
12

By that time, if the system gets more optimized, would there be a slightly higher chance for the skin system to be considered? With all of the explanations, I can sort of see why doing it right now would have had been problematic for anything - Whether that’s player models, objects to use in a Condo or anything else that can be currently customized with Workshop support and so there isn’t really any pressure that it become the focus or be a high priority - It’s just something that could be nice to have eventually, depending on how the Workshop system you guys seem to be developing evolves in the future and how it works with the rest of the game performance wise - The main benefit a skin system would bring and the reason for this thread being made in the first place would have had been game’s Workshop being less flooded with copies of same items with a slightly different look, even if at the moment that could potentially bring out more issues, as compared to anything else. Basically I just hope this is kept in the back of your heads as something that could be looked into when more work is done in the future on what’s important right now, even if we can also live without it just fine - A quality of life Workshop related change if you will, since that’s what that would essentially be.

13

would it be possible to limit the amount of polygons a model can have or has this been already discussed in-team and left as it is because would make it more difficult for inexperienced people to post their content in the TU workshop ?

14

I don’t know about you, but I highly prefer not having to be limited with how detailed (polygon count wise) a model can be. Seeing them is already disabled by default, and you have to consciously choose to lift this limitation on yourself. It would be better to leave things as they are right now.