Blitz Collision issue

Blitz3D Forums/Blitz3D Programming/Blitz Collision issue

Stevie G(Posted 2006) [#1]
I'm back working on my verlet vehicle program and have been in the process of adding back in the Train .. for those who remember.

The problem I'm having is that on a straight peice of track ( the grey line ) blitz collisions take between 0 and 1 ms.



When the train is going round a bend ... which consists of around 20 polys blitz collisions can take up to 16ms which isn't acceptable.




I've never run into anything like this before with blitz collisions but this kind of thing can almost half the FPS for what seems like no apparent reason. The entire world collision proxy mesh is no more than 2000 polys and only 16 pivots are checking for collisions here. The strange thing is that with my race track model ( approx 10k polys ) I never have this problem. It's kinda driving me insane :(

Has anyone come across this before and know the reason behind it? Suggestions , explanations and resolutions are most welcome :)

I'm using v1.87 btw.

Cheers
Stevie


big10p(Posted 2006) [#2]
That is odd. I know blitz sphere->poly collisions can get really slow when a large(ish) amount of polies are involved. That doesn't really explain why there's such a large discrepency when going around a bend, though. I suppose collisions are actually occuring a lot more when going around a bend - maybe this has an impact on speed, for some reason?

Are your collision pivots situated at the 4 corner wheels of each carriage, and you're just checking for lateral collisions with the side of the track? If so, I'd suggest having a separate, minimal proxy mesh of the track, and check for collisions with that. As you're only checking for lateral collisions(?), your proxy mesh onviously wouldn't need any polies on the top/bottom. Also, you could probably represent the track sides in the proxy mesh by just using a 'chain' of connected tris, instead of quads.

I actually had to implement this very method myself recently, to overcome a very similar problem, although I was only doing one collision check, each frame. It worked pretty well for me.

P.S. I know collisions were 'tweaked' some time after version 1.87, so it may be worth trying the latest version to see if it makes any difference.


Stevie G(Posted 2006) [#3]
I need to check collisions in all directions for each pivot. There are actually 9 per vehicle .. 4 x roof , 4 x wheels + 1 x center pivot. The track itself is as low poly as I can possibly get so I just don't get it!!!

I just updated to v1.96 and the issue is still present. What on earth can be causing this ... anyone?

Cheers
Stevie


Hujiklo(Posted 2006) [#4]
Have you tried rustling up some quick box collisions? Maybe the discrepancy disappears? Sometimes you just have to do stuff that you shouldn't have to do to get it working right.

Alternatively take collisions off for the track and use a path system instead.

Not ideal I know, but I bet a path would be the quickest of all methods for the track :(


Stevie G(Posted 2006) [#5]
Can use box collisions I'm afraid. The waypoint system I thought about but I like to avoid messy hacks where possible.

I made an decision to leave out the trains ... the only purpose they serve is to be re-railed as they aren't really worth driving. They were a 'nice to have' feature which was slowing down progress so they had to go.

I built in alot of hacks to prevent a random collision glitch I got with the other vehicles. It turns out that this was a bug in Blitz collisions present in v1.87 and below. After downloading v1.96 everything is working perfectly and I was able to remove all the hacks :) It p***es me off that I spent months trying to track it down when the solution was outwith my hands.

Cheers
Stevie


Hujiklo(Posted 2006) [#6]
One kast thing then..just to pin down the problem for sure. If you get time simplify the curve of the track by half the number of steps and check if there is a speed difference in m-secs. At least if you see there is you really know it's out of your hands!


Stevie G(Posted 2006) [#7]
I already did this as you can see in the above picture .. the curve is only 36 polys. Unless I know how blitz handles collisions internally then I'm not gonna waste any more time on this.

Thanks for your suggestions.

Stevie


Hujiklo(Posted 2006) [#8]
Oh yeh - sorry, the pics took a while to load and I skipped past them!


H&K(Posted 2006) [#9]
I dont Know, but questions

Are you checking for wheel vrs Track collistions or Train Vrs Track?

If you are wheel vrs track, are you collition detecting against the whole wheel? Or just a Flat Disc vrs track?

Whats the gap bettween wheels? Is it nearly the same as the track width. (ie are you checking left then right then left etc lots of times per frame?)

Dont you only need to check for the inside wheel collistions?


Vorderman(Posted 2006) [#10]
This might sound strange but have you tried INCREASING the number of polys in the curves, to make them smoother?


Stevie G(Posted 2006) [#11]
@ H&K .. I'm using blitz collisions sphere to poly. There is a gap between the wheels but it is a couple of times wider than the track mesh. I'm only checking collisions once per frame on each of the 36 pivots. For the train to steer itself it is necessary that the wheels on the inside of the bend are almost always colliding. Trains have no steering after all ;)

@ Vorderman, I've had the track with quite a bit more detail and it didn't work any better :(
p.s. How did you get on with the pivot thingy for the shadows?

Like I said, I've given up on it for now. For an object which was never gonna be an integral part of the game it wasn't worth any more effort.

==============================================================================

Now I do have one single intermittant problem. On the odd occasion the vehicle will kind of flash and some parts appear to be inside out. I say "appears" because it's so fast and rare that I've never been able to capture an image of it. This happens regardless of the camera view being close or far from the vehicle. I'm using 32 bit depth and the camera near and far range are proportionate to 1..1000, in fact slightly more accurate, so I can't imagine it being a z-order issue .. especially when most of the time all is fine.

I'm hoping that this is a driver issue as I've been unable to pin it down for months. I'm loathe to update my drivers too incase anything else is knocked out. Being a bit of a perfectionist it's extermely annoying and I can't help thinking it's something simple.

Unless anyone has any suggestions or have experienced similar then I'll have to ask all to look out for it when I release the next demo in a few weeks.

Cheers
Stevie


Vorderman(Posted 2006) [#12]
p.s. How did you get on with the pivot thingy for the shadows?


Haven't had a chance to try it yet, but I will at some point.

I'm sure you've thought of all these things, and most are probably unrelated, but I'll chuck around some ideas just in case -

1. What sort of collision do you have set for the pivots? Is it the sliding type? Perhaps the pivots are being pushed into the ground or into each other which is increasing the collision time.

2. Have you tried replacing them with spheres so you can observe what they do?

3. what happens if you give the edges of the rails a slightly off-vertical surface, ie. angle both edges inwards so the rail top is narrower. Perhaps the 90degree angle at the base/ground is causing problems.

4. are the pivots colliding with anything else by accident, perhaps the wheels or vehicle body or something is inadvertantly set.

5. how big is the mesh? Perhaps it's a size problem - could you scale the whole world down somehow to test it?

6. is the ground plane one large poly? Again perhaps a size issue so maybe breaking it into lots of smaller polys would help.

7. perhaps try a resetentity on each pivot to clear the collisions each frame?

8. Perhaps a huge number of collisions are being generated - have you tried debugging a countcollisions() to see how many are taking place?


Stevie G(Posted 2006) [#13]
Thanks Vorderman ..

1. Sliding
2. Yes, I have spheres in debug mode which change colour when colliding. They don't do anything untoward.
3. Have tried that .. currently the track sides are slightly sloped but top is smaller than bottom etc..
4. Using my debug mode I can see that the central body pivot is not colliding with the track, neither are the roof pivots which is what I would expect ...
5. Each tile is 256x256 units .. I don't think scaling this down would work ... and I'd have to scale down a load of other things.
6. The ground plane is one large mesh made from quads of the same size as my tiles so I'm already breaking it down.
7. This would only allow the wheels to fall through the floor so isn't an option.
8. I never thought of that .. I will give it a try and see what comes out of it.

Cheers for taking the time to look at this.

Stevie