FunCollision v1.0 Source + Bin + Tutorials

Announce new projects or updates of Irrlicht Engine related tools, games, and applications.
Also check the Wiki
PI
Posts: 176
Joined: Tue Oct 09, 2007 7:15 pm
Location: Hungary

FunCollision v1.0 Source + Bin + Tutorials

Post by PI »

Image

Hello guys! Finally, 1.0 it's out! 8) Binary + source + tutorials for you!

From readme.txt:

Code: Select all

- FunCollision is a collision detection and response system for sphere and
  axis-aligned ellipsoid characters VS each other and static environment.
  It was created for Irrlicht, for C++. Designed to be really easy to use.

- It offers continuous collision detection. 
  No matter how fast your entities are, they won't pass any objects or 
  entities; also they won't sink into the geomery or stick into it. It 
  also means that it's a bit slower than dicrete collision detection, but
  the overall look-and-feel is much better. It's 99% jittering-free, the
  remaining 1% is caused by the maintanence vector.

- Collision response.
  Characters gets pulled out of each other or from the static geometry.
  Characters can push each other, what is affected by their mass and speed;
  they also can bounce. Gravity affects the entities as a constant force.
  There's a base friction currently only on the whole system level.

- Gives you framerate independent smooth motion.
  Due to syncronization, your characters will act the same way on every
  computer. And due to friction, they'll have a smooth movement, like what
  the commercial games has. Entities are moved by forces and impulses.
From changes.txt:

Code: Select all

Version 1.0 (09-12-SOON)

* Finished new map
* Contact generation done
+ Object exception to ray casting
+ Bounding box selector
+ Terrain selector
+ Triangle IDs stored in the contacts
- Discrete collision detection
+ Rewritten almost from scretch
+ Continuous collision detection
* Got rid of jittering for good
+ No high-speed passing through objects/entities
* Broad-phase is better (but it could be faster)
+ Forces and impulses, gravity
+ Jumping, jumppads
* Pushing characters restored
+ System-level friction
+ Spawning, teleporting
+ Mass and bouncing
+ Timeing syncronisation
+ Automatic sleeping for the entities to gain more FPS 
+ Remove_ functions
+ RestartTimer() and checkTimer()
+ Readme.txt and changes.txt

Known Issues:

- If the framerate drops really low (<= 10), jumping and gravity related 
  movement is slower. On slower computers this can be an issue. (But 
  playing a game which runs with 10 FPS isn't really a good idea anyway.)

- If the framerate is very high, (and there's gravity) entities doesn't
  want to sleep.

- It's general speed is approx. 3X slower than it used to be, which is
  really uncool. It's related to selection. But I have a solution for this.

- Also, due to this selection problem, theoretically it might be possible 
  at high speeds to pass an object without colliding into it. However, I
  haven't noticed anything like this.
Download here!

Cheers,
PI
Last edited by PI on Wed Dec 16, 2009 12:25 pm, edited 6 times in total.
zerochen
Posts: 273
Joined: Wed Jan 07, 2009 1:17 am
Location: Germany

Post by zerochen »

sry but the file is corrupted... can t open it with 7zip
vins
Posts: 51
Joined: Mon Aug 16, 2004 6:14 pm
Location: Sofia, Bulgaria
Contact:

Post by vins »

The file is fine here and opens with 7zip. Just make sure you're not using download managers and you're not clicking "Save as..." as it seems it's on a free host and it forbits that.

About the collision demo. It works fine. Haven't come to any bugs. But it would be better if there is some gravity in the demo.
PI
Posts: 176
Joined: Tue Oct 09, 2007 7:15 pm
Location: Hungary

Post by PI »

sry but the file is corrupted... can t open it with 7zip
I can archive it to another format, if you want. BTW it works for me after downloading.
About the collision demo. It works fine. Haven't come to any bugs. But it would be better if there is some gravity in the demo.
Well, I've found a large bug... After rotating and scaling an other mesh, I cannot get closer to it than a kilometer... I must have screwed the matrices up :) And yes, there will be gravity later, this is just an early little demo :)
Thanks for testing!

Cheers,
PI
PI
Posts: 176
Joined: Tue Oct 09, 2007 7:15 pm
Location: Hungary

Post by PI »

So, here's my issue:

- I thought it would be a good idea not to transform all the triangles, instead: transforming the player himself into the object space. (By only repositioning the object -and not scaling, rotating- it works nice)
- However, I've forgot the fact that a ball, when being transformed into a scaled, rotated space, will look like a stupid egg or ellipsoid. Not so nice.
- I've tried to transform the collision hit vector and calculate the sick egg's actual radius in that direction, but I've must have screwed something, I couldn't get closer to the object than a kilometer, and collision response was jumpy. Bah.
- Now listen up, what a silly solution I've made: I select the triangles in object space, and collide in world space. It works, though, it's not very nice. But, it's a good temporary solution, I can implement other features until I figure out a nice solution.

If anyone thinks he could enlighten me about a ball morphing into a crazy egg, I'd really appreciate his help!

Cheers,
PI
PI
Posts: 176
Joined: Tue Oct 09, 2007 7:15 pm
Location: Hungary

Post by PI »

*** Updated first post ***
shadowslair
Posts: 758
Joined: Mon Mar 31, 2008 3:32 pm
Location: Bulgaria

Post by shadowslair »

Nice job! It`s faster than the current Irrlicht system. The only thing that opresses me is the nasty jittering effect, which the "old" system had also. Isn`t there any way fixing this out? :cry:

Ah, when standing right above the center of the moving platform and using the capsule (appears with the other volumes too) and when it starts pushing us, it pushes us sidewards, not at the platform surface normal direction (right upwards). This isn`t right, is it?

I was thinking of creating some collision system myself (currently using physics, which works fine, but I dislike the license, so most probably I`ll stop using it), but atm I have way too many things in my todo list to start doing this and I`m in a lack of time.

Hey! How about adding a raycast with a billboard like in the 07.Collision example? I think it`d be even nicer. :)

Hopefully we`ll see this build-in in Irrlicht. :wink:

PS: Why do you use the "D3DX81ab.dll"? And the update date is "Update! 09. 09. 22. " where it should be sth like 09.08.22.
"Although we walk on the ground and step in the mud... our dreams and endeavors reach the immense skies..."
PI
Posts: 176
Joined: Tue Oct 09, 2007 7:15 pm
Location: Hungary

Post by PI »

Nice job! It`s faster than the current Irrlicht system. The only thing that opresses me is the nasty jittering effect, which the "old" system had also. Isn`t there any way fixing this out? Crying or Very sad
Faster? Well, I think it's actually slower, and it's going to be even more slower, for a couple of reasons. But this will come with benefits. Then it's going to be optimised, but even then I dont't think it's gonna be that fast.

About the jittering: of course, I know about it. I've already reduced it since yesterday, but I have some other tricks to make it even less noticable. However, because of the way the whole system works, I think there will be glitches. It's highly iteration dependent (or, say: FPS-dependent).
Ah, when standing right above the center of the moving platform and using the capsule (appears with the other volumes too) and when it starts pushing us, it pushes us sidewards, not at the platform surface normal direction (right upwards). This isn`t right, is it?
Yeah, of course it's not good. I'll need to rewrite the collision between these shapes anyway.
Hey! How about adding a raycast with a billboard like in the 07.Collision example? I think it`d be even nicer. Smile
Sure, I just need to keep it in mind! But... what for?

You're right about the .dll! Since I don't ask the user which driver he wants to use, it's pretty useless to include it with the .zip! I'm using MinGW, btw. And yeah, the date. Correcting... thanks!

Thanks for testing, and for the feedback, shadowslair!
Cheers,
PI
shadowslair
Posts: 758
Joined: Mon Mar 31, 2008 3:32 pm
Location: Bulgaria

Post by shadowslair »

PI wrote: Faster? Well, I think it's actually slower
PI
Well, it`s faster for me according the 07.Collision example runs on 133 fps and yours first collision demo (my pc is old, but this way I do my best for optimization- just for the test- AMD 1,14 512 Radeon 128 :D )- at 214 fps. IMO this is faster. :wink:
PI wrote:Sure, I just need to keep it in mind! But... what for?PI
Umm... for raycast feature demonstration, for fun etc. If you create a collision system a raycast feature is a must and is easy to implement. I gave one fast collision system try some time ago, but getting proper result at high frame rate isn`t an easy task. I have some books about it and will read a bit when have some time.

One more question: Let`s say if it has its benefits than the current Irrlicht collision system and if the Irrlicht team approves it, would you like to propose it as a part of the engine or if not will it be open source? Because I`d love playing a bit with the source when have some time. :D

Looking forward for the no-jittering and raycast demo. Ah, and PM me if you are interested in some collision and physics programming books as .pdf-s. :wink:
"Although we walk on the ground and step in the mud... our dreams and endeavors reach the immense skies..."
BlindSide
Admin
Posts: 2821
Joined: Thu Dec 08, 2005 9:09 am
Location: NZ!

Post by BlindSide »

Are you using an octree or BVH or anything for this? I recomend BVH if you haven't decided on an acceleration structure yet.
ShadowMapping for Irrlicht!: Get it here
Need help? Come on the IRC!: #irrlicht on irc://irc.freenode.net
PI
Posts: 176
Joined: Tue Oct 09, 2007 7:15 pm
Location: Hungary

Post by PI »

@shadowslair:

Cool, if it's faster! I haven't spent too much time on optimizing it yet, so it's good to hear. I'm developing on an old laptop, too, and I'll try to keep the frame rate as much as possible! But even in the first release, I think there will be a million ways to optimize it even more.

Okay, I'm convinced about the importance of raycasting :) (I've got an idea for it: why not clipping the ray into segments, and selecting shapes against the bounding box of this segment, checking intersection, selecting the closest; and only if there were no intersection, advance to the next segment, etc. etc.? I think it'll be faster this way to find the closest point, and it also reduces the number of shapes to check, etc.)

>>I gave one fast collision system try some time ago, but getting proper result at high frame rate isn`t an easy task. <<

What do you mean? High frame rate isn't your best friend in a collision system? :)

Sure, I'm going to release it with source, but only when I have some good results. Today, for example, I think I'll rewrite the samplers for all the shapes. This is why I haven't released the source yet, because I change whole parts of it day by day.

Well, I think it really differs from the whole structure of Irrlicht, but it might change. I won't, but somebody might want to "Irrlichtize" it. It won't be that difficult.

Yeah, I'm interested, I'll definately PM you soon, thanks! But I'm only interested in low-level things, because the current system is surprisingly low-level, small and simple!


@BlindSide:

I had to google up "BVH" so that now I know what the abbriviation stands for (so obviously I had no idea about it :) ) I'm going to read more about it. Why do you suggest it, by the way? Currently, I'm using a stupid little octree, which always creates less node than Irrlicht's (who knows why??).


Thanks for the input, guys!
PI
BlindSide
Admin
Posts: 2821
Joined: Thu Dec 08, 2005 9:09 am
Location: NZ!

Post by BlindSide »

BVH is usually a lot faster to build and easier to code/maintain. I'm not sure about speed but there is probably not that much difference between the two in terms of traversal performance. Also Bullet uses a BVH so there must be another good reason.
ShadowMapping for Irrlicht!: Get it here
Need help? Come on the IRC!: #irrlicht on irc://irc.freenode.net
PI
Posts: 176
Joined: Tue Oct 09, 2007 7:15 pm
Location: Hungary

Post by PI »

Blindside, what I like about it (I'm reading it currently) is especially that it's a lot faster to build. Because the octree is good for static objects on triangle-level, BVH seems to be a good choice for static/moving objects on object-level. But I need to learn more about it. Thanks for the hint!
offmonreal
Posts: 6
Joined: Sat Feb 09, 2008 7:12 am
Contact:

Post by offmonreal »

Source? :D
The user not speaking GOOD on EN
PI
Posts: 176
Joined: Tue Oct 09, 2007 7:15 pm
Location: Hungary

Post by PI »

Wow, it's been a month since I've been in this topic! I did not have as much time for coding as I wanted. But the last two weeks I've been struggling to deal with some issues.

The first and most important is, that I've decided to go for a simple character-collision system, and not a general one. Although a general collision system could be used as a good base for a little physic system, I've realized there's no need to do so. There are several very good wrappers for physic libraries around, so anybody who needs a bit more complicated than walking around with a character will be recommended to use one of them.

Ok so far, I've started with the jiggling. This was mainly due to the fact I've been using the built-in FPS camera. It was updated as here follows:
- The FPS camera received input from the user,
- The FPS camera was updated to it's new position,
- The scene was rendered,
- The collision system updated the FPS camera to it's new position.
So the rendering was always before the collisions would have been taken into account. Therefore, it was quite jumpy.
Making an own FPS camera practically has got rid most of the jumpiness.

Next thing was to repair the collisions for the shapes. In the second demo, all the shapes were treated like spheres, even though they have different shapes. This "cheating" made it very comfortable to move around the characters. As a side effect, they could penetrate into the faces pretty much and a little bit into their edges. Well this is not very good. So I've turned these shapes into real ones.
But a real cylinder would not be able to climb stars, and also the box would be very uncomfortable to move around with. I've dropped these two. The capsule walks around like a grandpa, cannot step through small objects and walks very slowly up the stairs (or stops). Bah.
Then I've gone back to the previous solution, and tried to make a hybrid that allows the player to move around nicely and does not ruin the shapes. Not too much luck yet...
Maybe I'll just erease all the shapes and keep only the spheres and ellipsoids, these two are still the most comfortable and stable in all the situations.

Allright, I've been talking too much :)

@offmonreal:
I'll provide the source when I've finished with it. (And if it's good for anything...)

Cheers,
PI
Post Reply