I love VAM. I love the team. But there is clearly some kind of O(N^2) or similar issue in VaM related to loading. There is no other app out there that takes more time to load with more unrelated files sitting around. Load up Pick VAM Produce 69 II and check the profile. The loading issue should be easily findable.
-
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 Dear VaM team, please pause V2 work for a day or two and fix the loading speed issues in V1
- Thread starter gernb
- Start date
Threads regarding the original VaM 1.x
- Joined
- Jun 1, 2020
- Messages
- 2,520
- Solutions
- 94
- Reactions
You are in an english speaking community, we tolerate foreign languages if the authors are speaking the same language in the same thread.
But out of respect for thread authors, follow the post main language and use Google translation if you are not speaking english. Thank you.
- Joined
- Dec 31, 2025
- Messages
- 5
- Reactions
The translation wasn't switched before pasting, which caused the issue... Thanks for reminding me.
- Joined
- Feb 4, 2021
- Messages
- 716
- Solutions
- 33
- Reactions
Vam isn't a "game" the way most are made. The built in stuff is well optimized. If you have a fresh install and use built in assets and textures, things start up and scenes load like lightning. The way it's set up to use community made content through vars is what takes scenes longer to load, and the more complex the scene the more dependencies you will have. Some content creators are better at optimization than others, but there are limits. If you have a lot of content in your custom folders or download every var you see on the hub to your addonpackages, then loading times suffer.
So running the visual studio profiler, AFAICT, every .var file is read at startup. No idea why. if it's actually loading the files that's bad. I'm going to assume it's just reading the. JSON. But why on every startup? Why not load them from the Cache folder on startup? Check the date. If the JSON file in the cache is newer than the VAR then just use the Cache?
Also, maybe profile the JSON parser, given you're reading 1000-2000 JSON files, if the JSON parser is slow or if the usage of it has a O(N) look up for properties instead of O(1) then that would also explain where lots of the time is going. Also if the JSON loader is loading the file piecemeal, that would be slow. It should be loading the entire JSON into memory and pointing to the string inline (though maybe that's not possible in .NET). It would still be possible to load it at once and parse from memory though (if it's not already doing that).
You could also consider Caching in a binary format so that it doesn't need to be re-parsed when loading from the cache. You could also consider using SqlLite or something and cache everything in an easy to lookup way. Because why read every single vam files JSON file.
At least in Visual Studio's Profiler it doesn't have any symbols so It's not clear where the time is going. For startup, it's clearly that it's reading so many files.
Also, maybe profile the JSON parser, given you're reading 1000-2000 JSON files, if the JSON parser is slow or if the usage of it has a O(N) look up for properties instead of O(1) then that would also explain where lots of the time is going. Also if the JSON loader is loading the file piecemeal, that would be slow. It should be loading the entire JSON into memory and pointing to the string inline (though maybe that's not possible in .NET). It would still be possible to load it at once and parse from memory though (if it's not already doing that).
You could also consider Caching in a binary format so that it doesn't need to be re-parsed when loading from the cache. You could also consider using SqlLite or something and cache everything in an easy to lookup way. Because why read every single vam files JSON file.
At least in Visual Studio's Profiler it doesn't have any symbols so It's not clear where the time is going. For startup, it's clearly that it's reading so many files.
- Joined
- Aug 5, 2023
- Messages
- 74
- Reactions
The big problem with everything, as always, is how VaM is made. I imagine it started out from a much more basic perspective, but in the end, people's creativity has gone much further, causing the ‘game’ to suffer as a result. We should definitely have a better system for basically everything. Using a base that is totally dependent on plugins and other external dependencies is a bad thing. Animation plugins should be integrated into VaM, as should many other dependencies that are standard nowadays for any type of scene. Let's hope that all this changes in VAM2, because VAM1 is currently an internal mess that makes it so slow and its performance so poor in scenes that shouldn't be a problem. VaM is made with Unity, I don't know why there are optimisation problems in scenes that simply have smoke effects, lights and other things. Even with an i9-13900k with a 4090, you cannot get high and stable performance in """complex""" scenes. Unity supports all kinds of particle accumulations, high-resolution assets, even raytracing and so on. As I said, unless VaM uses an ancient version of Unity I don't know what is causing all the performance issues that VaM suffers from, but hopefully they will be fixed in VaM2.
- Joined
- Jun 1, 2020
- Messages
- 2,520
- Solutions
- 94
- Reactions
It won't be ( fixed in VAM 2 ).
I'm not undermining Meshed work here, but simply the concept of optimization. Optimization is generally made toward your target. Your target is "most probable situations". People having 3TB installs of VAM is not "most probable situations", and is a nightmare to deal with.
People want to have 3TB installation and have instant loading. This is NOT possible... not matter how you look at it.
The cache situation is somewhat the same deal. If you rely on cache, you're leaving potential updates behind until your cache expires. So the best compromise is looking at files (vars) to ensure they're not newer than the cache... which leads to this read at the launch of the game to ensure cache is not obsolete.
More or less it's a compromise between people whining because "I have obsolete versions in my game" and "I have longer loading times". No matter your approach, you'll have one side or another complaining anyway.
Unless you're, yourself, controlling your VAM install size... it's unlikely you'd have a massive install running flawlessly. VAM 2 will probably bring improvements... but will at some point hit some diminishing returns as the installs grow in size.
And the second aspect is authoring. @Sizzle, you're mentionning particles at some point... I've checked most particles made by the community... more than 50% are made without understanding overdraw or GPU instanciation. This is beyond VAM's ability to deal with performances. If modders/creators release poorly made content, VAM can't do nothing about it.
On top of that, you could have proper VFX released, and scene creators slapping 20 instances in a scene without accounting for optimization either.
The amount of layers for optimization is so insane that you can't hope for proper perfs unless you are, yourself, understanding every aspect of the puzzle.
I'm not undermining Meshed work here, but simply the concept of optimization. Optimization is generally made toward your target. Your target is "most probable situations". People having 3TB installs of VAM is not "most probable situations", and is a nightmare to deal with.
People want to have 3TB installation and have instant loading. This is NOT possible... not matter how you look at it.
The cache situation is somewhat the same deal. If you rely on cache, you're leaving potential updates behind until your cache expires. So the best compromise is looking at files (vars) to ensure they're not newer than the cache... which leads to this read at the launch of the game to ensure cache is not obsolete.
More or less it's a compromise between people whining because "I have obsolete versions in my game" and "I have longer loading times". No matter your approach, you'll have one side or another complaining anyway.
Unless you're, yourself, controlling your VAM install size... it's unlikely you'd have a massive install running flawlessly. VAM 2 will probably bring improvements... but will at some point hit some diminishing returns as the installs grow in size.
And the second aspect is authoring. @Sizzle, you're mentionning particles at some point... I've checked most particles made by the community... more than 50% are made without understanding overdraw or GPU instanciation. This is beyond VAM's ability to deal with performances. If modders/creators release poorly made content, VAM can't do nothing about it.
On top of that, you could have proper VFX released, and scene creators slapping 20 instances in a scene without accounting for optimization either.
The amount of layers for optimization is so insane that you can't hope for proper perfs unless you are, yourself, understanding every aspect of the puzzle.
Similar threads
