-
Notifications
You must be signed in to change notification settings - Fork 79
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RAM usage #369
Comments
C&B already merge, the model for each block, each face in the model, and the voxel data is de-duplicated in ram. However if C&B is the cause of your issue I can only imagine that the issue lies in the final rendering model size. Since that cannot be de-duplicated. Each chunk must have its set of vertex data at the last minute, and breaking that up would destroy preference by increasing render call count by a large volume. I'm quite shocked by the 16GB number, even the most complicated map I've looked at in the past used less then 1GB without any other mods / texture packs. ( its scary how fast mods and textures and pile up when you start adding things ) You can try disabling enableModelCompression and see if it uses more or less ram, in my experience it improved things significantly, but sometimes these things vary. Beyond what I've explained, I can only offer to look at the save if you can get me a copy, I might be able to use it to find further ways to reduce ram usage, Several of the optimizations in C&B were only possible because of maps given to me by other ambitious users. I can't promise anything obviously beyond looking at it to see what might be improved. |
Hello,
Here's everything you need to run the map (150MB) I hope the map serves as good research object xD |
Thanks I'll try to take a look over the weekend. |
I do believe that there are quite a few more unique blocks then you imagine, possibly due to placing off the block grid, rotations, or some other reason. I think that my heap dumps recorded around ~4k unique blocks. So that means there are about 4k models, and fairly complicated models at that, at least by minecraft standards. That being said there might be some good news, This is certainly the most memory heavy map I've encountered by a fair bit, it shows that in general, the compression system I was using doesn't work that well in the large scale with more models. So I've worked out a new one, though it probably uses more CPU cycles, on the plus side those CPU cycles are spent in the multi-threaded part of the renderer. I would suggest you give it a try, and let me know how it works out for you, I saw C&B's polygon memory footprint drop from around 2.4GB to 900MB and it removes the existing framework that was in use for compression. All in all my tests show that memory usage of the new build is around one third what it used to be on the map. https://www.dropbox.com/s/ekdb8vnmf560oc5/chiselsandbits-14.13.jar?dl=0 |
Wow this really helped alot 👍 Thanks! |
@AlgorithmX2 Just a bystander, but thanks a lot for your ambitious, selfless work on this project. It really makes Minecraft a whole new experience. I appreciate your attention to detail on matters like this! |
Also removes previous model compression algorithm.
Thanks for the map and testing, this should be in the next release. |
Hello,
over time the ram usage increased more and more until we had to allocate 16G on the clients.
I know that worldedit and this mod can escalate really quickly, but there's something
i like to ask/mention.
So my question is, why does the ram usage increase if i copy/place the same kind of c&b block?
Sure, i don't know how the rendering works, but would it be possible to kind of share the memory between c&b blocks that are made of the same bits, or does it work already like this?
Here's one building for example: https://i.imgur.com/FKP7UX5.png
The text was updated successfully, but these errors were encountered: