Collision problems

[adibia0]

I spotted a following thing on the Carlswood, when I turned the steering wheel:


There is also a very weird bug, when you hit wall or X-tree from the thin side: your car sometimes gets stuck, flies few meters away or it is thrown hundred meters high. It may also drive through it. Some of you may say, that I have nothing better to do than hitting the walls, but I think that such bug shouldn't occur on the track, which comes with the game. Actually, I discovered it because I was driving to fast on turn 2.

I think it happens, because the thin side of X-trees and walls is 1 vertex thick (so it actually has no thickness). Perhaps making them thick would help.

 

[boomer541]

I think the tires showing thru the rail is due to the collision box not covering the tires/car properly.

The sky high bounce is something thats been around for far to long and needs a solution.

 

[Mr Whippy]

I think the tires showing thru the rail is due to the collision box not covering the tires/car properly.

The sky high bounce is something thats been around for far to long and needs a solution.

Don't flag trees as collision items? Especially X type trees where their polygons get all over the place... Worst case, we need a 'ghost' collide material which we can put up to stop people going places they shouldn't. I thought for most tracks that would be ideal... a kinda tunnel around the course to constrain you after so far.

Dave

 

[boomer541]

We do have the forbidden comand to prevent a car from going where it shouldn't.

 

[Mr Whippy]

But thats only surfaces isn't it?

I'm worried about people getting airborne, maybe with weird wing settings etc, and flying out into empty space

Not a huge problem for now I guess, but all my roadside X trees are not flagged mainly because their polys sit right into the road in plenty of places
The alternative is to add ghost polygons around the tree trunks with collide on... or just ghost collide a barrier all around the track after the verges etc have finished...hmmmm

Dave

 

[Cosmo°]

The first thing adibia0 describes is quite an important issue, but not for visual reasons. Wheels only have the contact patch point for collision detection, which is why clip through objects. More so, this causes jerky bump responses and sometimes getting stuck on a simple kerb or staircase. It's something that we keep asking Ruud about

Perhaps the other situation could be dealt with from the side of the author - the example with Carlswood's paperthin armco is not unusual, wouldn't hurt to simple add slight curve at the end, as in real life, maybe?

 

[boomer541]

It's the collision box that doesn't cover the tires when they are turned. Perhaps Ruud could make car tires do the same as a collision box.

 

[Cosmo°]

The thing is that we don't want the regular collision box to cover the wheels though, because the tyre in particular is a spring element that needs deformable boundaries.

What we have now is a single point that defines where the tyre interacts with the surface. The visual effect of that can be seen on your screenshot, but at least in my opinion that's the less important side of the story.

When we drive over an obstacle such as a sidewalk kerb, a rock or a road joint the behavior is first clipping of the tyre model through the collision mesh of the surface, then a sudden and violent vertical acceleration when the contact patch point "climbs" the obstacle. If we didn't have limits for peaks forces set in racer.ini (or we increased them, which I did in the past for heavy vehicles), we would see the wheels shooting up and not even being stopped by the bump rubber.

When we drive around a corner, body roll and geometric camber changes act over the contact patch point, not the full tyre width in touch with the road.

What we need is perhaps a slightly more complex and potentially framerate costly approach, where we define a hard limit that represents the rim (idealized, rims really also act as springs) - racer.ini.max_tire_penetration on a per car basis so to speak. The other part would be an elastic ring element that represents the tyre itself. Pacejka MF5.2 allows for more detailed stiffness characteristics than the current (fixed) car.ini.tire_rate, which could be used for the ring's springing properties.

 

[Mr Whippy]

Can of worms well and truly opened.

I think Racer is pretty good all considered if you don't expect TOO much from it.

Again it all comes down to what we let users get away with doing, and how much we fudge things so they can do what they want to get away with

Driving down stairs for example, Racer won't handle it so well, but it'll do a not so bad job. If we fudged it to work, we'd know it was a fudge, BUT, how many other sims/games do we even get to know how accurate it is in the first place?

We can sometimes be critical of Racer because we understand it's limitations, but perhaps many things are quite limited but because we don't understand how they fudge the systems to work better, we might assume it's an elegant solution.


I think Ruud had looked at some system using contact patch frequency to filter out things due to a real contact patch having an actual size, not just a finite point contact patch. It's not ideal, but imo something similar may be all we need. An elegant fudge might be enough to cover the situations we need this response to be accurate.


After all, Racer is simulating driving on asphalt for the most part right now, and it does it pretty damn well. I'm all up for Racer being improved with better systems, but there is no need to go crazy just so that we can get a physically accurate system for driving down stairs or over cobbled streets, if we don't need it to be accurate doing so

I'd prefer time to be invested in tangible improvements for the things we notice 95% of the time

Dave

 

[Cosmo°]

Well, you don't need to go offroad to experience issues with the point based wheel collision - a manhole cover or speedbump will do, just like a detailed bump on a country road will.

For me, an improved wheel collision system is more important than body mesh collision, because we drive on wheels and they are after all the only connection we get our (force) feedback from. That you could then also properly drive your virtual Land Rover over a a fallen tree, or your monster truck over a Smart, just an added bonus.

Obviously, I'm not suggesting this to be on the agenda for v0.9.0 I made my point because boomer brought up the collision model for wheels - and I felt that it's better to mention the potential complications with such an approach now, rather than later.

 

[Stereo]

You can of course fake steps, like anything else. Black is the step, blue the wheel center. Based on the radius of the wheels, just draw an arc around the peak of the step and you get the path of the contact point. Modeling the blue path is easy.

 

[Terden]

I believe my problem belongs also in this thread because it probably has something to do with the collision box.

In banked corners I get sparks from the lamborghini with sounds and handling to match.
This corner has about 15 degrees banking.
In the other corner, wich is banked 10 degrees, there isn't any problem.

 

[boomer541]

I think the collision box is a bit low and look at how fast you are going!

I have had the Lambo scrape the road on carlswood in the 2nd turn.

 

[Terden]

Well if I bought a supercar in real life I want my corner speed to be limited by the amount of grip the tires allow me to, not by the scraping of the bodywork across the road.
But if that is the fact with the lambo, I'll have to cancel my order

 

[EAP3D]

I believe my problem belongs also in this thread because it probably has something to do with the collision box.

In banked corners I get sparks from the lamborghini with sounds and handling to match.
This corner has about 15 degrees banking.
In the other corner, wich is banked 10 degrees, there isn't any problem.

Guessing it's because the road is too low poly.

 

[Alex Forbin]

Actually it's a problem with the collision box near the rear wheels.

Alex Forbin

 

[Mr Whippy]

Not kept up to date with the collision stuff these days.

I believe the Lambo uses a four or five year old shadow box model (low poly), as the collision box, ergo it's not ideal for collisions


What is the current best logic for collision boxes, ie, poly count, and how do we define them?

I'm working on the Lambo for v0.9, this is just one of those jobs that may as well get fixed while I'm at it!

Many thanks

Dave

 

[boomer541]

For a collision box I take the body mesh and take out the insides and extend it down to just about the ground clearance and make sure the tire/wheels are covered. The front wheels/tires do turn out of the box and will show thru rail or other thin object it hits.

 

[camsinny]

Wheels/tyres shouldn't be included in the collision mesh. They tend to move around a bit
A low-poly shadow model would work, just try to get as much curve data as possible with as little polies as possible (if your weapon of choice is 3ds Max there's some Havok content creation tools that includes a convex hull tool, works well and lets you define # of polies for the mesh. A nice quick, dirty way to make a hull...

 

[Ian Strom]

Actually I let a tiiiny bit of some parts of the car stick through the collision mesh to kind of imply that you might have just collapsed the outer edge of your bumper or the most pokey-out bits of your fenders. I also leave out the air dam because those are not really that solid and would not stop the car dead if caught on a sidewalk or something.. but they could rip off and then your car might overheat. >_>
The exhaust too, that gets left out.