   Newton physics + HUGE world?
  Hi,I have a potential huge 3D world (lots of chambers, a little bit outdoor at some places). Let's say 4x4 kilometers. Now the problem/challenge is that alot of things can happen, without the player itself being there. For example, the player could fire a rocket that crashes on a random point at the other side of the game-world. All global objects are loaded and available (not for rendering, just a small entity with a position + info in which sector/scene it's located), so I could apply physics on them. Sorting out which objects are nearby that explosion is not difficult, but once their (Newton) physics start, they must have a world to collide with.Now I was thinking about making a static low-poly model of the entire world. Hollow boxes as chambers, sloped boxes for stairs, etc. A very rough estamation of the polycount would be 500.000 polygons, spread out over 4x4 kilometers.Now the question is, would a physics system like Newton be able to handle this (performance and also at a not too high memory price)? Does someone have experience with this?I know I could simplify things and skip the physics as long as it won't be in the player's sight anyway. But maybe this would work just as well? I must add that there won't be many objects using physics at the same time. Basically I have a small number of characters, plus the player walking through this big world. All the characters can interact with the world (collide with a barrel, trigger an explosion, fight together and die with ragdoll physics somewhere, etc.). So, there won't be hundreds of objects needing physic controls at the same time.Greetings,Rick   
  When i was writing flash games, i did something unique... i had around 10000 objects [sorta small squares] moving around colliding, my problem wasi hadfor(var i:Number = 0, i<=10000, i++){}obviously, this means 40000+ calculations per second, thats really bad....i split the map up into 25 sections (any number, its n^2)this lowered the loop DRAMATICALLYit was basicallyfor(var i:Number = 0, i<400, i++){}it increases stability BIG TIMEbut its hard to implement, theres also floating point errors and such.My question:What are you willing to sacrifice? performance? quality?Edit:I must also add, ignoring certain objects would be a smart idea... heres something i thought of:Cast a ray in the direction the object is going, there is no reason to check for collision with an object that is not near your objectMake a list of pointers to the objects that collide with your rayFor each object in your listUse the pythagorean Theorm to find teh distance between objects a and bif the distance is less than the total size of the bounding boxes combined [lengthwise, diagonally]that shold narrow it down by alotCurrently, ur having aroudn 500,000 checks PER OBJECTthats about249999500000 calculations total?*took a while, watching olympics :D*hth-warty   ;  Load Balancing, as I think warthog518 is suggesting, is a good technique.Also putting your environment into an Octree / Grid of some sort, and linking that to an 'Active List'.The Octree can cut huge chunks of activity from your updates as whole nodes without any activity can be ignored until there is activity in them.For example. If you launch a missile from one corner of the map and it lands in the other corner, you really only need to do physics on your launch location and then where the missile lands. If it travels across the map rather than up in an arc you just do each node it passes through each frame.The 'Active List' would allow ongoing calculations on objects and it's neighbors to be carried out until completion as a priority for objects that are already in motion / close to you / and so on. This does lead you with a small potential headache as any other objects those then interact with can have a domino or cascade effect on your system... But careful planning can avoid this, and it should pretty much be limited to a local region when neighbors touch etc.For the rest you can simply run their physics balanced over a few frames, or if it proves really efficient frame by frame.Judicial use of a timer will even allow delayed updates to have calculations compensated so that whilst movement is in lower resolution jumps, it is still tied to a 'real' timeline.   ;  I see. So far I always used the Newton physics engine with the "NewtonCreateTreeCollision"function for the static world. It does build an octree, or maybe BSP... I'm not sure which technique it exactly uses. They describe it as a "complex collision geometry tree". That works fine, and probably fast as well. But I was wondering if it can also be used for a gigantic world. Calculating collisions between a couple of objects won't be the problem in my case. I meant there could be ~500.000 polygons in the static world, or maybe a million. The object count is not that high, and most of them will be "in rest" 99% of the time anyway.But maybe the size or high polycount does bring some extra management cost, and/or a big memory hit... So far I only tried physics in the "current scene" which is relative small.My world is a little bit like the Halflfe 1 world, but instead of loading a small part of the world each time, the entire world will be loaded. Well, a low-poly version for physics (the detailed mesh/rendering only happens around the player).Thanks for helping!Rick   ;  You might want to try building a simplified collision solver, to find what objects are involved in the collision, before properly sending just those objects to be solved with your physics engine. The easiest way would be to build a collision box or sphere around each object, then store them all in an oct-tree. When the game runs, you can find what objects might touch each other (it's only rough because you're not looking at the actual geometry, just how close objects are), and then you can send just those objects to the physics engine to get solved properly and accurately. This way, the polycount doesn't make any difference.   ;  You'd probably be best posting this question on the Newton forums - Julio usually answers things like this very quickly and can give you info on how the engine works internally.I use Newton on a really huge world (hundreds of kilometers across) with no efficiency problems so far (although with a number of isolated islands of bodies, and no large static geometry.)   ;  Why don't you try it out?  Make sure you're using the beta of 2.0, preferably the double precision one (go to the Newton forums and PM Julio, just ask him to beta test the double precision Newton 2.0).  It might Just Work (or it might not), but there's no point in discussing any solutions if the problem is not confirmed [wink].Quote:Original post by methinksYou might want to try building a simplified collision solver, to find what objects are involved in the collision, before properly sending just those objects to be solved with your physics engineNewton already does that automatically.   ;  That sounds hopefull :) I can't just try it out yet though, the engine has no physical unit yet. But I think I'll use Newton again, it worked very well in the past. I already asked to prevent surprises. Also the AI, storage system and rendering part depends on how the world is made, so I wanted to be sure the size or polycount can be handled. But you guys are right, its best to ask it on the Newton forum. I almost forgot about those, it's been awhile :)Thanks for the tips and help!Rick   