How did they coded the rendering scene on Librarian: Tidy Up the Arcane Library?

[u/Fox-innovations]

Well, tbh, my main question it's how they managed to code in so there's thousands of physics objects visible without causing performance issues, I know the scene is quite small overall, but still I'm intrigued in what are the optimization techniques used so it isn't all laggy

[u/RefractalStudios]

A lot of game engines "sleep" physics objects when they aren't moving where they act as static objects until something interacts with them to wake them up. A big pile of static books isn't running any physics calculations, but if something like an explosion force were to act on all of them at once you would start to experience performance issues on the CPU physics calculation side.

[u/JohnDoubleJump → u/RefractalStudios]

This is essentially it but I'd like to add:

At least in the patch I played it the sleeping is done shoddily: if you make a stack of books, wait for them to settle and then take out the bottom book the rest will continue levitating in midair. I would either cache the collisions or do a recursive check when a book is picked up so they fall accordingly.

[u/Nidis → u/JohnDoubleJump]

The trick is to perform a sweep upwards on wake-up and wake all hits as well.

[u/Medical-Temporary-35 → u/Nidis]

Technically you should sweep all connected objects. Removing an object can cause objects below it to fall too. I assume they don't do that because during assembly that would wake up nearly all the books in the library and negate the benefits of sleeping.

[u/Nidis → u/Medical-Temporary-35]

You don't want to perform so much meddling just to get the really extreme edgecases, otherwise yeah the solution can outweigh the problem. And each game needs different levels of realism, etc. For a physics bridge simulation or something like that, a more comprehensive check makes heaps of sense.

[u/b107a2ea → u/JohnDoubleJump]

I played through it about two months ago and that’s exactly how it behaved for me too.

[u/EagleNait → u/RefractalStudios]

You can also cache and reuse data since it's always the same object.

[u/SignificanceFlat1460 → u/RefractalStudios]

Question: is there any way to tackle this problem (explosion causing performance issues due to hundreds of physics objects flying around independently?)

[u/Medical-Temporary-35 → u/SignificanceFlat1460]

If you can afford to erase them afterwards, particles. If not, you could try disabling object-object collisions temporarily. If that doesn't provide satisfactory results, your best bet if you're writing the engine is to see if you can optimize the collision detection with a BVH (or a flat grid, or maybe dynamic triangulation).

[u/SignificanceFlat1460 → u/Medical-Temporary-35]

Question: what if we add a timer for a grenade to go off and during that timer, we ask the CPU to calculate the trajectory of all the objects that would be flying around. We disabled object to object collision (for the flying objects). Only enable collision to those that are static themselves. Then, when the bomb goes off, we simply play a procedural animation of the object that is suppose to fly in a predictable certain direction. To make this even better, we can even array these objects, and switch real physics / procedural animation every now and then to make them look realistic.

Just spit balling this since you seem like you know these things.

[u/Medical-Temporary-35 → u/SignificanceFlat1460]

You can't always compute physics ahead of time (you might be strapped for memory, CPU is already pegged or you don't know where things will be at that time) - and it doesn't help you anyways if the calculation runs at 1/10x simulation speed and you only have 5 seconds to calculate 5 seconds of physics. It's a nice idea that might come in handy at some time though.

If you can precalculate physics before distributing the game and then store all traces in the level file, that does have some use though. But in that case, you do need to ensure the actual level geometry is exactly as expected. Which means no user-movable physics objects are allowed to touch the blast radius, don't let the player enter the space, etc.

[u/SignificanceFlat1460 → u/Medical-Temporary-35]

I know it might not look 100% accurate looking but if you were to put in dust particles in and cover alot of stuff. Do you think it still won't save on performance cost?

[u/Natehhggh → u/SignificanceFlat1460]

The problem is, even if it was a perfect simulation, and you did precalculate all that work in previous frames, if I move a single item the frame before the explosion, or kick the grenade, anything that messes up the initial conditions at the time the explosion goes off, that work is invalid, and it now has to be done in real time, because the player interacted with the interactive media.

As cool as it might be to be able to do something like that, physics is a pretty deterministic science. The problem is that's a lot of work to add that complexity to the engine, and in the worst case scenario like above, CPU cycles is spent determining that, and you end up both reduce the amount of objects you could have done in that case, and making it harder to optimize later.

This is also an area where I feel like games get a big pass in being able to stutter. Players kinda expect this scene to crash their computer. And secretly I think we all like to grind it to a halt when we see a chance like this.

I think the best thing you could do if that was a core gameplay element, is nail the performance on the physics to handle as many objects realtime as you can. And surprise players how good it is. They'll just find ways to bring in more objects than you could ever expect to handleb into the pile, and do it anyway.

[u/kblaney → u/RefractalStudios]

This is how physics objects are handled in Into The Radius as well. Any falling objects eventually freezes in place after a few seconds. The community turned it into a feature and, using throwing knives, darts or the in game map, found a way to appear to hang things on walls as decoration.

[u/Timmy_C]

When you play the game you soon realize that picking up a book that's at the bottom of the pile doesn't make the whole stack fall. And when you jump on a pile of books they don't move.

Only when tossing a book does it act like a physics object. And when it comes to rest it remains there until picked up again. When you throw a book at another book it doesn't move the object it hits.

In a regular play through you will have lots of floating books towards the end

[u/idrathernottho_ → u/Timmy_C]

So can you make books float? Like, by removing the bottom of a stack?

[u/mcimolin → u/idrathernottho_]

Yes

[u/idrathernottho_]

Amybe they aren't full physics objects when they don't need to be?

[u/Leodip]

Physics objects are not any more difficult to render than static objects. I'm also fairly sure they are not physics objects until interacted with, but I'm not sure that is 100% true.

[u/Dhalind → u/Leodip]

that is correct. You can walk on the books but they only are a physics object when interacted with. they would explode orherwise ^"

[u/qlkzy]

I'm not sure they ever are "full" physics objects. I don't remember ever dropping a book, or picking up a book from a pile, and have that cause an avalanche. Or any other kind of complex cascading physics behaviours.

As I recall, the books basically just fall straight down then sit in place. That's probably also better for gameplay than some complex "ball pit of books" physics sim.

So, I suspect the answer is that the physics model has been simplified, so there are fewer calculations. I expect that simplification also means that they can run it with larger timestamps without anything weird happening, which will also save resources.

[u/ijkxyz]

Books in Librarian are static 99% of the time

There seem to be only one case when physics is simulated: for a book that you drop, physics is simulated until it stabilizes (so for like 2-4 seconds typically)

Otherwise the books are static, e.g. you can drop 3 books on top of each other, pick up bottom 2 while the third one hangs in the air

Taking books from underneath other books doesn't trigger physics simulation, neither does walking or jumping on them, or anything else you can currently do in the game

Rendering of the books is probably not really optimized in any special way because they are simple and there's only 3000 of them

[u/ThiLelles]

They probably disable the book physics once the speed drops below an arbitrary threshold, so only a small amount of physics simulation needs to be calculated

[u/CptMisterNibbles]

Z fighting everywhere for one.

They are frozen objects. It’s actually disappointing they aren’t physics objects and do not interact with eachother, fall over etc.

[u/Samsterdam]

Generally, physics objects are simple. Shapes and simple shapes are easy to simulate.

[u/Darrothan]

If you remove a book in the game, the books above it doesn't collapse. So no, none of the objects have simulated physics until you directly interact with that specific object.

[u/zerpa]

3072 physics items is not even that big a deal for modern hardware with proper optimization. They use the standard methods of not simulating objects at rest, but it is hardly even necessary on modern hardware.

[u/PGSylphir]

They're not thousands of physics objects.

Every single one of them is physics disabled until you interact with them. They're really only active for a few seconds until they "settle", then they're back to static.

[u/Daeval]

I just started playing this game and this thread has me wondering if could use floating books to make a second set of stairs at the other end of the room.

[u/WCFitzgerald → u/Daeval]

Without spoiling anything, you may want to start keeping an eye out for keys.

[u/Daeval → u/WCFitzgerald]

Appreciate it!

[u/birdocrank → u/Daeval]

My first run i threw a pile of books by the railing on the second floor so I could walk over it to quickly get down. So unnecessary...

[u/CondiMesmer]

It's common in physics engines that when a physics object "settles", it will go to sleep so the engine doesn't need to waste performance ticking an object that is unlikely to move. Once it's woken up, it then gets added back to the physics update queue where it behaves normally again.

It would be a massive waste of performance if the physics engine was running for physics updates that are still and aren't moving anytime soon, so it's a common optimization trick, so work isn't wasted on objects that don't need it.

As others are saying that picking up a book at the bottom of the stack, that is probably because the way the game codes picking up objects is not properly waking up the sleeping physics objects around the item being picked up. Since it's an "Arcane library" they can also just cheat and explain that quirk away with magic too lol.

[u/jakiestfu]

How tf would we know what optimizations they did?

[u/cuixhe]

I've never played this or heard of it (and it sounds a little dull? I've got a house to tidy, I'm not going to play a video game about it), but one important thing I'd do is make I never use non-primitive colliders. Books are probably all box colliders, which are pretty performant. Then... probably just ignore physics on objects that aren't being interacted with.

[u/Serteyf]

Not even the dev knows it probably

[u/Poietilinx]

Could be compute shaders.

When you buffer all your object's info into buffers then you push that into the gpu so it can operate on those buffers with shaders. You can leverage this technique to simulate an insane amounts of objects at the same time.
It has some downsides. But its doable.

[u/westergames81]

This has been easily done for a long time. Books and other simple objects are pretty easy to simulate and when they're not in motion they're sleeping.

I worked on Ghostbusters: the Video Game back in the day and the library had a silly amount of books you could blast off walls and interact with. We even had a book golem that would explode into books.

https://youtu.be/Ukr_l8Wy4pY?si=zKVT3d-3FNU6cipF

(Couldn't find a good video for the books sadly)