Author Topic: How is blockland optimized?  (Read 3158 times)



the problem with collision detection is, you have to check each pair of objects to check if they are colliding, apply calculated forces, etc. that would result in a calculation length proportional to the number of objects squared (in big O notation, O(n^2)).
using a thing like a KD/BIH/BVH/BSP tree you could accelerate the calculation by checking if the two objects are near enough (check whether their AABB/OBB overlap)(believe me thats possible using such trees)
« Last Edit: October 26, 2015, 06:36:24 AM by Klarck »

how would you determine collision when the two grids are non-aligned? imagine the number of calculations required to check if anything is colliding anything else at any one time. you can't assume anything with code; it doesn't work like real life blocks where atoms automatically repel each other if they get too close. in a game, there is no automatic - everything is programmed in. the more complex the task, the more computing power is required to make it work.

and its kinda naiive to think that the time grids would be next to each other is short-lived. what happens if people use moving bricks within a brick hallway to simulate a piston?
1. That is true actually. I suppose you'd have to generate collision boxes for each grid, then re-generate them each time it changed.
Perhaps some sort of system that just adds additional collision boxes and, if no changes are made for 30 seconds, combines them back all into one.
2. then there are a few faces that aren't hidden. It would take much more calculations to try and hide those faces.

1. That is true actually. I suppose you'd have to generate collision boxes for each grid, then re-generate them each time it changed.
Perhaps some sort of system that just adds additional collision boxes and, if no changes are made for 30 seconds, combines them back all into one.
2. then there are a few faces that aren't hidden. It would take much more calculations to try and hide those faces.
if you did the setup in 1), whenever you break a brick on a moving mass it will freeze up a sec as the game recalculates the collision mesh and updates the model, especially for big things. you can't just "add" collision boxes either; ramp collision works differently than block collision. the more points you have to keep track of that are moving (in this case all the vertices on the moving model's collision box), the more calculations are necessary.

and anyways, torque sucks at collision meshes, as you've probably been able to tell with vehicle physics. unless someone did an entire blockland port, it just wouldn't work.

torque
I actually am planning to start a project in Unity for a blockland in space. I know that torque definitely wouldn't be able to handle the stuff I'm talking about, and it would be impossible to mod this in. Even with .dll injections, you'd probably wind up rewriting the entire game.

So that means that it should be possible--in unity--. I could just add collision boxes as long as I make ramps work the same way, and then I could just wait till the grid stops moving and doesn't update for 30 seconds to redo its collision mesh back into 1.
See you in 3 years when I'm done!
« Last Edit: October 24, 2015, 06:03:43 PM by superdupercoolguy »

good luck with it. so far few to none blockland port attempts have actually succeeded. the only one i can think of is the one in games which is a replication of vanilla BL

60000 bricks is actually not much. Assuming worst case with no faces hidden that is only about 1 million tris. A modern engine can handle that easily while looking a lot better than blockland.

Moving bricks without sacrificing octree optimizations wouldn't be too hard as long as you don't need physics between grids. Imagine all the things you could do with them with just hardcoded animations, like rotating giant doors, etc...
« Last Edit: October 24, 2015, 06:13:31 PM by Zeblote »

blockland had optimizations? that's news