FunCollision v1.0 Source + Bin + Tutorials
-
- Posts: 758
- Joined: Mon Mar 31, 2008 3:32 pm
- Location: Bulgaria
I`m really happy you`re progressing. Indeed using a box or real cylinder for character collisions ain`t that useful. A sphere and ellipsoid shapes are fine but don`t drop the capsule shape, since it has it`s advantages for character collision, and hopefully will be improved in time. Having the cylinder and box volumes as an alternative at least for static objects will be nice- a tree trunk, a barrel or a street lamp base will be "cheaper" as a cylinder, and some boxes, small houses etc will be better for the box shape(in comparison with a triangle shape-capsule shape collision). Just don`t push`em outta the todo list. Here are some things I think will be nice to be implemented (probably I`ll frequently add some more):
1. Raycasting (yep, once again- it`s a must even for a basic Collision System)
2. Collision Groups (or Collision Group Filtering)
3. Using Collisions Manager (or somewhat) object and easy access to the collision data
4. You may give your collision sytem project some more specific name (PIColSys etc.)
Don`t hasitate too much giving some info about your progress, asking for opinions, tests, sympathy with the math problems (kidding), some test levels etc.
1. Raycasting (yep, once again- it`s a must even for a basic Collision System)
2. Collision Groups (or Collision Group Filtering)
3. Using Collisions Manager (or somewhat) object and easy access to the collision data
4. You may give your collision sytem project some more specific name (PIColSys etc.)
Don`t hasitate too much giving some info about your progress, asking for opinions, tests, sympathy with the math problems (kidding), some test levels etc.
"Although we walk on the ground and step in the mud... our dreams and endeavors reach the immense skies..."
Thanks for supporting, shadowslair!
- I use "Selectors" for selecting triangles from a polygon soup, practically from a static object. There are 2 types of selectors: simple mesh triangle selector and octree mesh triangle selector. I've planned to add BVH selector and a very simple one, a box selector (for smaller meshes). Here's where the cylinder, and maybe other shapes should be put.
- For the moving characters ("Entities") I use "Samplers". Samplers are used for colliding against what the selectors have selected, therefore defining the character shape. There are two shapes that are working (more-or-less) correctly: the sphere and the ellipsoid.
Sooo... maybe even if only couple of shapes could be used for characters, it might be good to have a larger variety of shapes for the objects... Okay.
Cheers,
PI
I've got your point, however, for some reason, I keep forgetting about it. Probably because I've been concentrating so much on character-character collision. Anyway, I've added them to my todo list. Currently it looks like this:Having the cylinder and box volumes as an alternative at least for static objects will be nice- a tree trunk, a barrel or a street lamp base will be "cheaper" as a cylinder, and some boxes, small houses etc will be better for the box shape
- I use "Selectors" for selecting triangles from a polygon soup, practically from a static object. There are 2 types of selectors: simple mesh triangle selector and octree mesh triangle selector. I've planned to add BVH selector and a very simple one, a box selector (for smaller meshes). Here's where the cylinder, and maybe other shapes should be put.
- For the moving characters ("Entities") I use "Samplers". Samplers are used for colliding against what the selectors have selected, therefore defining the character shape. There are two shapes that are working (more-or-less) correctly: the sphere and the ellipsoid.
Sooo... maybe even if only couple of shapes could be used for characters, it might be good to have a larger variety of shapes for the objects... Okay.
All of these points are already on my todo list, but thanks Don't hesitate to share more of ideas!1. Raycasting (yep, once again- it`s a must even for a basic Collision System)
2. Collision Groups (or Collision Group Filtering)
3. Using Collisions Manager (or somewhat) object and easy access to the collision data
4. You may give your collision sytem project some more specific name (PIColSys etc.)
Cheers,
PI
Thanks!
It would be nice to hear how it performs on other systems. I'm especially interested in "simulation time".
Since the debug info focuses on the map itself, it'll report wrong numbers of the "selected triangles". It won't add those are selected from the dwarf model, for example. Going near the dwarf model, the real number of selected triangles can go up to 300-800. If the other entities are also near to it, the number of triangle tests go very high. Even in this situation, on my older laptop the "simulation time" is between 2-6 ms. On my rather faster PC, it's between 1-3 ms. Not bad at all, regarding that the dwarf has a simple mesh selector (no acceleration), and not an octree, like the map.
One thing I've forgot to mention about the current demo: don't be afraid, this is not the final gravity! It's just a -Y vector for testing, until I implement impulses and forces!
It would be nice to hear how it performs on other systems. I'm especially interested in "simulation time".
Since the debug info focuses on the map itself, it'll report wrong numbers of the "selected triangles". It won't add those are selected from the dwarf model, for example. Going near the dwarf model, the real number of selected triangles can go up to 300-800. If the other entities are also near to it, the number of triangle tests go very high. Even in this situation, on my older laptop the "simulation time" is between 2-6 ms. On my rather faster PC, it's between 1-3 ms. Not bad at all, regarding that the dwarf has a simple mesh selector (no acceleration), and not an octree, like the map.
One thing I've forgot to mention about the current demo: don't be afraid, this is not the final gravity! It's just a -Y vector for testing, until I implement impulses and forces!
-
- Posts: 758
- Joined: Mon Mar 31, 2008 3:32 pm
- Location: Bulgaria
Lol! New version! This is much better! I lke the idea of the sphere and ellipsoid following our "character" shape. Just one more thing: you may give the user the option to enable/disable gravity. I wanted to test some "nice" corners, but I weren`t able to. I managed to stuck under the stairs every time I tried with the ellisoid, but it`s ok for now. Here`s one question I have: Do you use the model`s meshbuffer data for collisions or you transform it somehow?
Once again- (clap)
PS: I`m getting 60fps when "me" and "my pals"- the sphere and the ellipsoid are colliding the small dwarf, average of 140 fps and about 200 fps when collision is off. (test made on AMD 1,14 512 Radeon 128)
Once again- (clap)
PS: I`m getting 60fps when "me" and "my pals"- the sphere and the ellipsoid are colliding the small dwarf, average of 140 fps and about 200 fps when collision is off. (test made on AMD 1,14 512 Radeon 128)
"Although we walk on the ground and step in the mud... our dreams and endeavors reach the immense skies..."
Thanks! So you were able to download it? I think I've just seen a post complaining that the download link is broken. I've just uploaded it to rapidshare Download from rapidshare
Thanks for testing, guys!
PI
Okay!enable/disable gravity
Oh that's not really good... I'll try to do something about it later.I managed to stuck under the stairs every time I tried with the ellisoid, but it`s ok for now.
Which model? By the way, yes and no. For the early tests, I just transform a bounding box to the object space, then I transform the selected triangles to world space, then if the collider is an ellipsoid, I transform it further. This is true for the static objects, like the level, and the 2 dwarfs. But if you're asking about the 2 fellow entities, there are no triangles at all.Here`s one question I have: Do you use the model`s meshbuffer data for collisions or you transform it somehow?
Thanks for testing, guys!
PI
I've just seen your test results. I think they're ok. Could you please check how much the "simulation time" goes up in this situation? I'm particularly interested in this value because the FPS can be highly influenced by the rendering, for example, so it's not the best indicator for me.
Yesterday I've tried to reduce jittering even more by analyzing the contact results and creating a new position for the entity according to them. The overall result was really good, but the side effect killed the whole effort: the more triangles the entity was touching, the more slower was moving around.
I think I should rather take the contact normals, we'll see.
The next step is implementing a collision "director". Not a manager, there's one already. (Maybe the two will be combined.) This director will instruct the entities when they should collide, where and how. It will avoid unnecessary tests, and will control the correct time steps. It will ignore very small and very large movements. Currently, if you'd have an entity with high speed, it would simply fly through everything.
Yesterday I've tried to reduce jittering even more by analyzing the contact results and creating a new position for the entity according to them. The overall result was really good, but the side effect killed the whole effort: the more triangles the entity was touching, the more slower was moving around.
I think I should rather take the contact normals, we'll see.
The next step is implementing a collision "director". Not a manager, there's one already. (Maybe the two will be combined.) This director will instruct the entities when they should collide, where and how. It will avoid unnecessary tests, and will control the correct time steps. It will ignore very small and very large movements. Currently, if you'd have an entity with high speed, it would simply fly through everything.
-
- Posts: 758
- Joined: Mon Mar 31, 2008 3:32 pm
- Location: Bulgaria
I realy had some problems dowloading it the first time, but probably there were some issues with my crappy connection. (I believe this is what I get for 7 euro per month )PI wrote:Thanks! So you were able to download it? I think I've just seen a post complaining that the download link is broken.
Course. You`re simply doing some checks with one radius for the sphere and some transformations for the ellipsoid. Doing triangle-triangle checks for those would be quite senseless...But if you're asking about the 2 fellow entities, there are no triangles at all.
Of course. Well, worst case (both sphere and ellipsoid and me pushing towards our poor fellow- the small and tiny dwarf) - 10-11-12. Some medium simulation (only the sphere and the ellipsoid colliding the small dwarf) 5-6. And best case- no triangle checks, except with the level mesh- 0-1.Could you please check how much the "simulation time" goes up in this situation?
As a whole- not bad, keeping in mind this has no acceleration structure yet- neither OctTree, nor BVH, which IMO will decrease the simulation time like: worst case: 9-10-11 medium: 4-5 and best case: really close to 0. In fact some optimisation will give the opportunity of having some more triangle object meshes and bigger and more detailed level meshes to use, but will not decrease the simulation time too much. But as I said- it`s rather ok. You may need to focus on the static not AA Box checks and improve the stability even if it would cost you some simulation time. Like- what`s the point of a game running at 200fps, when you stuck every time go get close to solid objects, and your character`s jittering to death, right? And you start asking yourself: "Is he THAT scared?!
The collision director is a good idea, it depends on how he`s doing his job, or he`ll get fired. It`s very important to create your funCollision sytem out of the box of Irrlicht, which would mean that no modified .dll would be needed. And for the fast moving objects you may need to add something like TOI collision checks- just like if we have a sphere with radius of 0,5 units (1 unit in diameter) and let`s imagine it`s a projectile moving with the velocity of 100 units per step you run 100 times (worst case) through a loop and do 100 checks for each step to make sure our projectile don`t penetrate something solid. Which process may become optimized a lot, but for now you need it working no matter of the check time. Take a look here (this is just a very fast idea): http://pics.data.bg/categories/1/%d0%be ... bmp_image/
"Although we walk on the ground and step in the mud... our dreams and endeavors reach the immense skies..."
Thanks for the test results!
By the way, in most modern games they do not use the same geometry for rendering and collision detection. They have highly simplified meshes. K-dops, convex hulls. I've got convex hulls already on my todo list. They're also using blocks in some situations, for what the planned box selectors will be perfect. Also, there are some situations where they render the mesh, but it has no collision geometry at all. Think about small things on the floor, or very thin pipes on the wall, etc.
Here's an updated .exe, just copy to the funCollisionDemo3 folder. No improvements here, I just have added the ability to turn "gravity" off, and increased the minimal vector length that is ignored. This will result a little bit more "squared" movement, but it also should reduce jumping. You can also turn the info off and see how it performs.
Once again, I've made some tests with the previously collected contacts to reduce this unwanted effect, but unfortunately I didn't make progress: where moving was smooth previously, it became worse.
But we still have options:
1# The current solution, what the updated .exe does. This reduces jittering on a close range. The strength of this solution is still, the speed. The higher the FPS is, the smaller the jittering is. Cons: squared movement, does not solve complicated situations.
2# Like what 1# does, but add a user controllable "maximum number of iterations" value. This would make it a bit slower in complicated situations, but more accurate.
3# Precalculating. Simplifying the geometry, and then saving the data. In the very beginning the system worked like this. The simplification itself is very slow, but it just have to be done once. It would remove about 80% of the jittering, I guess.
4# Turn the whole system into continous collision detection. Pros: 95% less jittering, even in complicated situations; no worrying about moving with high speed. Cons: this solution will reduce FPS pretty much.
Anyway, I don't worry about this too much. I've seen many commercial games with this unwanted "feature" . (For example, the Unreal Tournament series) And, in normal situations, it's still less noticeable than Irrlicht's. I've just tested it. (And, in complicated ones, it's much worse . Irrlicht would simply stop the character there, make it "stuck")
Thanks for the link! I've planned something similar.
The level itself is accelerated with octree. The 2 dwarfs could easily have octree, too. For the larger one, it might worth it. But for testing purposes, I let them alone with a simple mesh triangle selector. You also need to know that this selector should only be used for low polygon meshes. (so the dwarf with it's 2000 polygons is not the best example... )As a whole- not bad, keeping in mind this has no acceleration structure yet- neither OctTree
By the way, in most modern games they do not use the same geometry for rendering and collision detection. They have highly simplified meshes. K-dops, convex hulls. I've got convex hulls already on my todo list. They're also using blocks in some situations, for what the planned box selectors will be perfect. Also, there are some situations where they render the mesh, but it has no collision geometry at all. Think about small things on the floor, or very thin pipes on the wall, etc.
Here's an updated .exe, just copy to the funCollisionDemo3 folder. No improvements here, I just have added the ability to turn "gravity" off, and increased the minimal vector length that is ignored. This will result a little bit more "squared" movement, but it also should reduce jumping. You can also turn the info off and see how it performs.
Once again, I've made some tests with the previously collected contacts to reduce this unwanted effect, but unfortunately I didn't make progress: where moving was smooth previously, it became worse.
But we still have options:
1# The current solution, what the updated .exe does. This reduces jittering on a close range. The strength of this solution is still, the speed. The higher the FPS is, the smaller the jittering is. Cons: squared movement, does not solve complicated situations.
2# Like what 1# does, but add a user controllable "maximum number of iterations" value. This would make it a bit slower in complicated situations, but more accurate.
3# Precalculating. Simplifying the geometry, and then saving the data. In the very beginning the system worked like this. The simplification itself is very slow, but it just have to be done once. It would remove about 80% of the jittering, I guess.
4# Turn the whole system into continous collision detection. Pros: 95% less jittering, even in complicated situations; no worrying about moving with high speed. Cons: this solution will reduce FPS pretty much.
Anyway, I don't worry about this too much. I've seen many commercial games with this unwanted "feature" . (For example, the Unreal Tournament series) And, in normal situations, it's still less noticeable than Irrlicht's. I've just tested it. (And, in complicated ones, it's much worse . Irrlicht would simply stop the character there, make it "stuck")
You can bet on that! It's just a couple of h and cpp files, no modified dlls at all.create your funCollision sytem out of the box of Irrlicht, which would mean that no modified .dll would be needed
Thanks for the link! I've planned something similar.
i'd have an idea for quick raycasting (from camera only)...
its API specific though
you read back ONE pixel from the depth buffer at the point of the ray (i.e. middle)
then you do this
pixelposition.xy*2.0-1.0 // to convert into -1 to 1 range
pixelposition.z*FarValueForCamera
pixelposition.xy*pixelposition.z // screenspace coords before division by W coord
matrix = getProjection(PROJECTION)*getProjection(VIEW)
otherM
matrix.getInverse(otherM)
otherM.transformVect(pixelposition)
and you get a world space coordinate at that point in the scene. VERY acurate!!!! FAIL SAFE.
its API specific though
you read back ONE pixel from the depth buffer at the point of the ray (i.e. middle)
then you do this
pixelposition.xy*2.0-1.0 // to convert into -1 to 1 range
pixelposition.z*FarValueForCamera
pixelposition.xy*pixelposition.z // screenspace coords before division by W coord
matrix = getProjection(PROJECTION)*getProjection(VIEW)
otherM
matrix.getInverse(otherM)
otherM.transformVect(pixelposition)
and you get a world space coordinate at that point in the scene. VERY acurate!!!! FAIL SAFE.
-
- Posts: 758
- Joined: Mon Mar 31, 2008 3:32 pm
- Location: Bulgaria
CSceneCollisionManager::getRayFromScreenCoordinates(); does this just perfectly and it`s a build-in function. I think there`s no much sense "reinventing the wheel". It returns two world coordinates to cast the "traditional" ray.
Still we will need some things like filtering, having shapes marked as "detail flag"- with no collision checks and on...
Using the buffer is a nice idea- I`m kinda sceptic about that though...
PS: I wanna see that working...
Still we will need some things like filtering, having shapes marked as "detail flag"- with no collision checks and on...
Using the buffer is a nice idea- I`m kinda sceptic about that though...
PS: I wanna see that working...
"Although we walk on the ground and step in the mud... our dreams and endeavors reach the immense skies..."
-
- Competition winner
- Posts: 1123
- Joined: Sun Jun 10, 2007 11:14 pm