Quote: "Yeh but you couldn't do that in real time. calculating collisions with thousands of points is not feasible in real time.
"
Here's a theory. It's probably not perfect, and it requires some setup, but I'll give this issue a go.
How do we check for collision now? We use rays. Rays are slow. So how do we make this process faster? We set up a 2x2 grid of the map. Furthermore, we break each box up into smaller grids. We then use quick calculations to see what grid (and grid layer) our player is in and only check that part of the map for collision and not the rest.
This same theory can be applied to a brick object with 500,000 atoms. All of those atoms don't need to be thought of all of the time.
Hypothetically speaking, if we have several normal polygon boxes inside a 10 yard radius, on perfectly flat ground, and we simulate a vertical up and down jerking of the ground, why would we need to run separate physicals calculations on each box? Couldn't all of it be reduced by simply grouping those objects together and then running the physics on the group?
Back to our brick example, which consists of 500,000. A brick, obviously, is comprised of many atoms that are bound together to create one entity - the brick. Just like my normal polygon box example above, they are treated as a whole but comprised of the individual. So to run physics on this brick, you are really dealing with one object.
Now, the argument might be, you'd still need to worry about moving around all the other atoms if the brick is say... thrown. Thus the calculations still need to be ran on all of them. I would disagree. I'm not entirely sure on the math behind it, but you could probably use some sort of mathematics, like the one in the rotation expansion for DBP, to simplify all of it.
Since I don't know the facts on the math, I'll argue this: It's already being done to a degree in normal polygon graphics. To manually create a cube you would make 6 separate faces, each having 4 vertices. That's 24 vertices. What happens when you bring those faces together to form the cube and weld? Those corners become one and you end up with 8 vertices. They are still there, IIRC. The vert just has more properties than it would if it were alone.
So I start to think that each of these atoms could be used like a vert. When we rotate an object, we don't rotate verts, we rotate the object and the verts follow. The same sort of math will be done.
Also, if have a box 5 units wide... how does the space in between the box get filled in? How do those lines get drawn, shaded in and eventually textured? That area in between the vertices still has to be calculated when physics is applied. One face of that 5 unit wide box really has to worry about 25 units of space (5^2). What if a bullet hits the center? What if all that in between was called atoms?
Speaking of bullets, and coming around full circle from my opening grid example, what if that 500,000 atom object get's shot? What about collision and the breaking apart of the brick? What about the shrapnel? Normally we use that grid approach to reduce calculations along a plane, but we can apply that same technique three dimensionally on the brick object. A bullet hits the top left quadrant of the front of the brick? Apply the usual calculations as you would now to simulate bullet damage in games, delete the relevant atoms and leave the rest in tact.
I speculate, of course. Now I get several of you telling me I'm wrong
"If I have seen a little further it is by standing on the shoulders of Giants" - Isaac Newton
Current Project:
http://strewnfield.wordpress.com/ (Last updated 06/11/09)
