Irrlicht Engine

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.

Thanks for supporting, shadowslair!

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'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:
- 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.

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.)

All of these points are already on my todo list, but thanks Don't hesitate to share more of ideas!

Cheers,
PI

*** Updated first post ***

wow, great one!
when i'll back from travel i'll look more at this wonderfull stuff
keep making good things and let the force will be with you

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!

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)

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

enable/disable gravity

Okay!

I managed to stuck under the stairs every time I tried with the ellisoid, but it`s ok for now.

Oh that's not really good... I'll try to do something about it later.

Here`s one question I have: Do you use the model`s meshbuffer data for collisions or you transform it somehow?

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.

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.

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.

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 )

But if you're asking about the 2 fellow entities, there are no triangles at all.

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...

Could you please check how much the "simulation time" goes up in this situation?

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.
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/

Thanks for the test results!

As a whole- not bad, keeping in mind this has no acceleration structure yet- neither OctTree

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... )

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")

create your funCollision sytem out of the box of Irrlicht, which would mean that no modified .dll would be needed

You can bet on that! It's just a couple of h and cpp files, no modified dlls at all.

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.

Hey thanks for the idea, devsh! It wouldn't be bad even if it's only casted from the camera (although we still need the traditional raycasting too). But how would I access the depth buffer?

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...

*** Updated first post! ***

Wish I could download, but your site is "under review."