• Hi Guest!

    We are extremely excited to announce the release of our first Beta1.1 and the first release of our Public AddonKit!
    To participate in the Beta, a subscription to the Entertainer or Creator Tier is required. For access to the Public AddonKit you must be a Creator tier member. Once subscribed, download instructions can be found here.

    Click here for information and guides regarding the VaM2 beta. Join our Discord server for more announcements and community discussion about VaM2.
  • Hi Guest!

    VaM2 Resource Categories have now been added to the Hub! For information on posting VaM2 resources and details about VaM2 related changes to our Community Forums, please see our official announcement here.

VaM 1.x Thoughts on competing community standards regarding large dependencies and duplication

Threads regarding the original VaM 1.x

Metix

Well-known member
Featured Contributor
Joined
Dec 5, 2022
Messages
131
Solutions
1
Reactions
418
Just some thoughts and observations about community customs regarding large dependencies in published resources and duplication of assets.

There are three primary community norms/standards that I keep brushing up against, each one coming from the intention of being a good steward of the hub, its resources, and the community.

  1. Avoid pulling in too many large dependencies if you can, otherwise many people will just skip right past your resource.
  2. Try hard not to unnecessarily duplicate assets, especially if no/minor changes have been made to them.
  3. Avoid spamming the hub with numerous tiny resources. This floods the new releases page and just reads as spammy, and generally bad form.
Let's take a look at VFX, particle effect packs, for example. They are usually published as a large collection of assetbundles in a single, from mid to in some cases a really large sized, VAR on the hub. Usually, if someone is going to use a VFX, they (me in this case) would likely only need one or two FX, but then you're pulling in an 80-400MB dependency for what might be an 8MB file.

But stripping out the assetbundle and putting it in your own release, even if it is CC-BY, is frowned upon because that creates duplicates, this is bad, and understandably so.

Theoretically, the original publisher of the VFX could release each asset as a separate resource, but that is also not good form, as it reads as spammy and clutters up the front page of new releases on the hub.

The end result of these three, well intentioned, standards is that a lot of good stuff ends up rarely getting used because each of these three factors are all playing against each other. Personally, I would prefer many small, specific resources as they would be easier to search for. Not really sure if there's a solution here, just airing my thoughts as I balance whether to pull in a large dependency or just leave it out entirely, not a choice I'm looking forward to making.
 
I am in the same predicament, good topic. I just tried to battle this problem in repackaging a pure skin set from a published look. As i want to reuse it several times, and as some people already used it, it was worth it i think. Got one negative review, stating it would be pointless, but i beg to differ.

But you are right that there are two sides of this coin. We had a discussion some months ago about it here on the hub, some creators even put existing clothes as a duplicate into their looks. It is awful to have so many redundant content, but on the other hand if someone removes their resource, you are in trouble. I am working on a scene for months now and a creator removed suddenly almost all of his environments, i used one of these and now it is gone. Lots of resources have vanished in the last months, whole pose collections and loads of environments for example. Dependancy can be a blessing, but also a curse at times.

I also want to use just some rain particle effect of a big collection, i am in the same boat as you described. What to do? Of course we can't repackage every single asset or resource for every resource out there, even if the license would allow it. I already feel bad because of the repackaged skin of someone else, it isn't my work.

It would be too cool if you could just reference a part of a ressource. It would be great if every creator would separate things in single vars within one hub entry, perhaps that would be the way to go. But i guess the current system would download all of it anyways. I tried to separate things in my last look using 3 vars, but each of the copies got downloaded multiple times anyways, because the system can't recognize if it already downloaded the same references within one resource download procedure i guess (?).


So, for the time being i would just reference other resources, even if they are big and you would just need a small part. Big beloved creators just throw all into their var and are done, and no one seems to care, quite the opposite. So though i am still conflicted between "best practice", avoiding clutter/redudancy and "the majority doesn't care", i think good standards are not that important to most users. Perhaps it is even a good idea to put everything into your var, so missing resources won't break it ever.


TLDR: lots of valid opinions and aspects, difficult topic, i still don't know the best way to handle it :D
 
use a VFX, they (me in this case) would likely only need one or two FX, but then you're pulling in an 80-400MB dependency for what might be an 8MB file.

The problem is with that example: I don't know why the hell there is a 80 to 400MB assetbundle for VFXs.

If you look at VAMStoryVFX, there are a crap ton of cookies, and there are several "prototype" assets include in it, still yet not available in the UI... and the bundle is 5mb.
I could probably pull 50+ different VFX with a package under 30mb without much effort.

Even tho I agree with your statement, I feel like you obviously need some "bundle" for VFX, because if you script a scene well, you're gonna use more than one in general ( let's assume we're going for an immersive scene ;) )

This falls down to the lack of knowledge on how to do proper assets and optimize them.
But if we just look at the dependency issue, you're completely right, pulling a 400mb resource for one smoke VFX is just annoying.


Avoid pulling in too many large dependencies if you can, otherwise many people will just skip right past your resource.

That problem has been stretched way too far. The original "many dependencies" issue started because of the insanely bad packaging behavior in some resources. But the "too many dependencies" forest hides a legitimate choice for having a high dependency count. If you give me a very very (very) cool scene with like 150 deps worth 2gigs of SSD space, I won't mind if the scene stands out. If you need these deps, to make something insanely great, then you shouldn't be afraid to do that. And people should chill and understand that making something great requires great content.

On the other hand, I still don't understand why appearances gets released with dependencies more than hairs and skin. A single appearance should have its hairs and eventually (if needed) the skin. The character should be naked and provide examples and suggestions in the release documentation for clothes and styles that fits the character.

If you're an appearance creator. You could have some sort of HZMDemos like I do, with like a big "gallery" of all your appearances with clothes dependencies for THAT demo var only. But the appearance itself should have the most minimalistic footprint on a scene when you include it.


If you want my really subjective opinion on this:
  • Creators should spend more time learning how to bundle things efficiently and properly. VAM is borderline gamedev in some situations (appearances, hairs...) and litterally gamedev in others ( plugins, scenes, etc )... and this requires you to know what you're doing.
  • Creators should choose wisely what they use. If they see a somewhat very bad packaging, instead of using it because "IMA WANT IT IN MY SCENE", just find an alternative well packaged.
  • Users/Players should chill on the dependency issues and eventually give feedback on very badly packaged elements. Not on scenes that DO need a high dependency count.
  • Give kind and respectful feedback on content that seem wayyyyyy too big for what it is. For instance: I'm litterally never considering a 8K texture set for characters. It's pointless due to the texel resolution especially in a gameplay situation, and no one does macro virtual photography in general. You could for instance suggest to release a "game" version at 4K max and a virtual photography version at 8K.
 
As an experiment, I recently released a look with just nude appearance presets, and a separate release of clothing presets for that character. I didn't get many downloads of either, but they were pretty balanced. That says that almost everybody who wanted the look wanted the clothing too. These were pretty lightweight releases, tho. One reason I did this is the problem where somebody releases a look with a piece of clothing referenced from somebody else's scene, and it pulls in the whole scene. In game, the program doesn't know about sub-dependencies, it just downloads everything.

As I see it, the big problem with duplicate clothes (or hair) on the hub is when a scene creator adds the item to their scene not realizing that the one they grabbed is one of the dupes that pulls in other stuff, instead of the OG one that's standalone. Bad packaging isn't just disk space bloat, it's also stuff that's completely unnecessary to the current scene.
 
  • Creators should spend more time learning how to bundle things efficiently and properly. VAM is borderline gamedev in some situations (appearances, hairs...) and litterally gamedev in others ( plugins, scenes, etc )... and this requires you to know what you're doing.

The main issue, and this is also apparent on platforms like Sketchfab (1million polys for a wooden stick!?!), is that there are no consequences for packaging content poorly. When working on a game, say for a console, you have hard limits on memory size, storage capacity, and performance/framerate. And since many asset creators tend to specialize, they rarely see the downstream effects of how they author and package things. In a studio you would have either a producer, or a lead on you within the hour or a bunch of bug reports you would have to deal with. Also, a lot of those actual lessons are hard won. Celebrating shaving 5ns off of script load only comes after having to rebuild something multiple times from scratch because it can't ship as is.

I think this could be addressed by encouraging people to release individual assets rather than large bundles, but this can also cause other issues. I think it's something to consider as VaM2 continues to develop, that fostering a healthy ecosystem can be just as important as the tech behind it. Not really sure how such things could or should be enforced, or even encouraged. Ultimately you're right, that the community itself sort of has to be responsible for it, as the mods can only do so much. I think this is a discussion worth having though.

Another side of this is that there are far, far more users on the hub who never release anything than creators, so this issue doesn't affect them quite in the same way as someone wrestling with whether or not to pull in a large dependency for their resource or not. And while they vote with download statistics (feedback being far more rare than DLs), the effect is less visible.

The lens that I'm viewing all of this from is as a creator though. And it's pretty clear that sane packaging and resource publishing doesn't just benefit creators, but the hub and the entire community, as more and better quality content would be the result of well packaged and organized resources.
 
Last edited:
Sketchfab (1million polys for a wooden stick!?!)

Yeap, and people port those :p


is that there are no consequences for packaging content poorly

And it probably never will ( Sketchfab or any other, like VAM ), because you can't moderate the content at its root. We already have a shit ton of moderation to do with the legal issues that can arise on a porn game. Imagine having to go through assets and go "bro, your thing is not game ready and 12 millions polys, redo that". It's not doable at Facebook's scale, or Sketchfab's scale, so imagine at the hub's scale.


I think this is a discussion worth having though

This obviously has been already discussed :p
When you think of something that "hits you in the face" on the hub, we generally already have moderated several problems or side effects before you even saw it. The discussion about the legitimacy of a creator doing poor ports/creation is not for us to decide and as mentionned above we can't do that on a wide scale. The only way is to let the "resources" be "moderated" by the community (ie, as you say: download, review, reports to the creator).

But to give you an idea, this does not change much. Being there since the beginning, pre-hub and all. I've reported several times over the years broken assets, scripts, scenes and never got answers nor fixes for them. And I'm not talking about inactive creators, I'm talking about active creators, not answering, ignoring feedback and going on with their lives releasing other bad stuffs. I litterally had the case two weeks ago on a plugin.
The result is, you have a (or multiple) resource, here, on the hub... available to everyone which does not work. Trust me, it annoys me as much as it annoys you : )

At some point, it's something you gotta make peace with.
You have people dedicated to learn the game dev craft and do things properly. And you have people just wanting to release things for the sake of releasing... to get I don't know what... internet points maybe?
Ultimately, it's like drawing, playing music or anything that requires investment... overall, you have to dig in an ocean of mediocre stuffs to find the good stuff and rare hidden gems : )

That being said after all these years, I'm still facepalming on bad stuffs... probably something you can't really ever be at peace with if you are dedicated to the craft :p
 
Back
Top Bottom