Entity Culling Fabric/Forge

Entity Culling Fabric/Forge

80M Downloads

Conflict or poor optimization.

stels9fox opened this issue · 22 comments

commented

I often used the mystic staff of explosive mana condensation, but if you add this mod.
When using the mystic staff of condensation of explosive mana or the scroll of Rho ​​Aias from Mahou Tsukai, the fps drops to 1 and there is ~ 600 ms per tick
However, the Mahoujin Projector does not affect the FPS.
Item from botany that also very much squander FPS shard of Laputa(during operation, a ray of mana is created for each raised block).
Setting the number of particles does not affect the lags or has little effect.
These are just the items that I have checked, possibly others that create a lot of moving particles can lead to lags.
If you remove entityculling then fps does not drop when using mystic staff of explosive mana condensation.
01

commented

The culling doesn't happen in the main thread, so even if it's at 790ms that doesn't affect the fps and just makes stuff slower to react to when it's visible/hidden. So it should be the exact same fps drop without the mod. Also try to update the mod, this is an older version with performance issues.

Note: particles are completly ignored/untouched. So changing settings there has 0 effect to this mod.

commented

tr7zw in my case, the problem is in this mod, since without it the staff of explosions from mahou tsukai works fine. In the sense that the drawdown due to heavy animation goes up to 10 fps and not a slideshow 1 frame every few seconds.
Perhaps there is a conflict of mods, since Mahoujin Projector works fine although it creates roughly the same animation. but when using an explosive staff, minecraft lags as shown in the picture. Even if the staff creates not particles but entities, the problem in any case is that the EntityCulling mod creates too many requests, which most likely kills the FPS.

commented

Like I said the issue is that the EntityCulling mod physically can't cause fps drops since it is not linked to the render thread. If you can link me to a modpack(best-case on curse) where I can recreate this, then I can take a look into what the hell is happening. Alternatively, you could try to create timings over all threads using Spark https://www.curseforge.com/minecraft/mc-mods/spark /spark profiler --thread * over the lag and then send that.

commented

The modpack I'm using is TNP Limitless 3 - v1.9.8b
Perhaps the problem is not EntityCulling but multiple mod conflict or forge errors.
Upd: I will try to use the spark, not the fact that I will do everything right.

commented

Spark Attempts Report.
I created a separate superflat world and using the command
/ spark profiler --thread
used the mystical staff of explosive mana and after not the scroll of the spell rho ajax
after used
/ spark profiler --stop
and got it
https://spark.lucko.me/3zEJgEcoo2
An interesting point in the direction of the gaze does not affect the lags, the very fact of the animation from mahou tsukai is important
01
02

commented

I think you missed the * in the commend, the report is empty. Also like I said update the mod, you have some older version. I'm currently trying to recreate it.

commented

Hm, shard of laputa from botany works fine if you use it once, but if you press on one place several times, then some symptoms appear
image

Reworked spark report
Now I will try to repeat with a newer version of the mod
https://spark.lucko.me/Gur7vSxhme

commented

Ok I am able to reproduce it and it seems to stop when toggling off the culling. The issue seems to be the Memory getting flooded with crap, so it's constantly cleaning it(which takes ages with your 14gb allocated ram). Now going to test it with the correct version of the culling.

commented

https://spark.lucko.me/DfdVfTLkKF
Submitted on the latest version of the mod.
If I correctly understand the mechanics of the mod, then it creates something like a filter that either allows rendering of an entity or prohibits it, and animations from mahou tsukai create just a host of thousands of small entities, which leads to lags. In theory, this is a problem with the productivity of iron and will always manifest itself with a certain number of entities. Which, in principle, is solved either by a more advanced filter algorithm or by a direct limitation on the number of operations.

commented

Hm using a profiler it seems that using the item somehow causes a crapton of vectors/arrays to be created. This might take a moment to figure out what exactly is happening.

commented

https://www.youtube.com/watch?time_continue=46&v=Bd-ww-BDQMA&feature=emb_logo
If you look at how the animations work in this video, you can see that this is not one object that is rotated, but a set of simple vectors for vector graphics. This can be seen especially clearly at 1.00-1.05 where an explosive staff is used.
So maybe the problem is not in EntityCulling, but in how it creates its own animations of mahou tsukai.
But even if so, the problem with a large number of objects for this mod has not gone anywhere, just very few mods create so many objects that are processed by EntityCulling so that problems begin immediately, but for very developed bases where dozens of automatic setups can work, this can make this mod meaningless since winning in FPS for the freshly generated world does not make sense if, with the development of the base, the FPS will gradually fall until that hell begins that one staff of explosions can cause.
Note:In general, you can simply add the entire mahou tsukai mod to ignore and not try to solve the issue fundamentally. Or remove any vectors as an exception, since this means something from the mods that is supplied by the player and does not need processing.
Upd question: You can get an answer about what kind of strategy will be taken to deal with this situation. I can be active on the network for another 1 hour, and after that I will have to go to bed.

commented

I'll check this more tomorrow. My guess is that the visual box of the animation is really giant or so. I'll have to see.

commented

I did add the limiter(and set it to 50 by default), but I also redid some parts of the internal logic to not allocate any arrays/vectors anymore. Then set the limit for testing to 500 made it still lag-free. So I guess the issue was just the fact that it accidentally allocated 2 cubic arrays that were fine for 3x3x3 hitboxes(just one slot wasted), but really caught fire with the 128x128x128 hitboxes 😅.

commented

My guess is that the visual box of the animation is really giant or so. I'll have to see.

Yes that is the case. Maybe a blacklist config to ignore certain entities/mods would be useful? I tend to have huge visual hitboxes on my entities as they're often things which should be visible from many many blocks away, and also from behind the player, which often doesn't happen if the hitboxes are normal sized.

commented

Currently, BlockEntities can be whitelisted. I guess I'll add a whitelist for entities too, but also add a hard limit that hitboxes larger than x are not worth trying to cull. Also noteworthy: https://cdn.discordapp.com/attachments/811998801304617037/825500486169395210/nD2oyypsyH.mp4 here you can see in the debug info when the animation spawns there are temporary entities that get rendered, but after that while it is charging all entities are culled, yet the animation is still there. So maybe the incredibly large hitbox that doesn't seem to be needed for the animation can be removed in general?

commented

Yes, I can do that for some of my entities - I've moved some to RenderWorldLast since in general it functioned better than rendering them normally, so for some at least I can probably make that change without it affecting the render. :)

commented

I'll put out a new version later today that will also fix it by ignoring the giant hitbox. Might I ask how big they are? From a gut feel I'd have placed the limit at 50 in width, height or depth, for now, so anything that is larger than that just doesn't get checked.

commented

public static final AxisAlignedBB bb = new AxisAlignedBB(-64, Double.NEGATIVE_INFINITY, -64, 64, Double.POSITIVE_INFINITY, 64);

This is the bounding box I usually use, lol

commented

so a 128x128x128 bounding box. If you are diagonally up or down to it the culling mod has to calculate and then ray trace potentially up to 49.152+ positions * 1-8 points every 10ms. Yea I can see where the issue is 😅

commented

well... yes. that could pose a problem. seeing as bounding box size affects the ammount of raytrace points directly.

commented

yeah that's 100*50k*3*4 bytes every second -> 60MB/s of memory alloc at worst?

commented

I did the rough math and I think it can be up to 3.7gb/s of allocations. That is bad 😅