#29 Add Collisions with Foliage Objects and Road Signs

[marsch84]

The attached patch adds the ability, that the vehicle crashes with foliage objects and road signs beside the track. This is a first implementation that can be seen as a start point for more advanced collision handling. However, I think this already much better than to magically drive through trees and road signs. This change gives the player a more mature impression of the game, so it should already be included.

One more idea for improvement from my side is, that different foliage objects show different crash behavior. For instance hitting grass or a bush should have a different impact than hitting a tree or road sign. However, this requires an extra attribute in the "foliageband" nodes in the "level" files that does not exist yet.

Please get back to me with further suggestions and issues you find with this implementation.

[Onsemeliot]

I am so very happy that you take on so many tasks, Martin.

when I try to build the game after appling your patch I get the following error:

$ make

current values of user-set variables:
    DESTDIR      ?= 
    prefix       ?= /usr/local
    exec_prefix  ?= /usr/local
    OPTIMS       ?= -march=native -mtune=native -Ofast
    WARNINGS     ?= -Wall -Wextra -pedantic

resulting values of build variables:
    CXXFLAGS     += -std=c++11 -Wall -Wextra -pedantic -march=native -mtune=native -Ofast
    CPPFLAGS     += -DNDEBUG -DUNIX -DPACKAGE_VERSION="0.6.7" -I'./include'
    LDFLAGS      += -lSDL2main -lGL -lGLU -lGLEW -lSDL2 -lSDL2_image -lphysfs -lopenal -lalut -lpthread -ltinyxml2

g++ PEngine/app.cpp -> PEngine/app.o
g++ PEngine/audio.cpp -> PEngine/audio.o
g++ PEngine/fxman.cpp -> PEngine/fxman.o
g++ PEngine/model.cpp -> PEngine/model.o
g++ PEngine/physfs_rw.cpp -> PEngine/physfs_rw.o
g++ PEngine/render.cpp -> PEngine/render.o
g++ PEngine/terrain.cpp -> PEngine/terrain.o
g++ PEngine/texture.cpp -> PEngine/texture.o
g++ PEngine/util.cpp -> PEngine/util.o
g++ PEngine/vbuffer.cpp -> PEngine/vbuffer.o
g++ PEngine/vmath.cpp -> PEngine/vmath.o
g++ PSim/engine.cpp -> PSim/engine.o
g++ PSim/rigidbody.cpp -> PSim/rigidbody.o
g++ PSim/sim.cpp -> PSim/sim.o
g++ PSim/vehicle.cpp -> PSim/vehicle.o
PSim/vehicle.cpp:9:10: fatal error: collision.h: No such file or directory
 #include "collision.h"
          ^~~~~~~~~~~~~
compilation terminated.
make: *** [GNUmakefile:166: PSim/vehicle.o] Error 1

Is it possible that you forgot to include "collision.h" into the patch?

I think it is essential that we actually have at least some degree of variation in rigidity. Since it would be very strange to smash against grass like against a rock. We could use three levels (weak, medium, solid) or something that can be adjusted as a continuum from zero (like air) to one (solid). I would prefer the second (if possible).
We could also pre-define the rigidity value for each vegetation sprite but then we would probably need a xml file for vegetation sprites comparable to the level or event files since it should be easy to add new vegetation sprites without the need to alter the actual program code.

[marsch84]

You are correct. I actually missed two files in the patch. I attached a second patch that includes the missing changes.

I also thought of a continuous parameter, e.g. from 0.0 to 1.0. Less rigid objects like grass would receive a lower value and only slow down the vehicle. For solid objects like trees it would be set to 1.0.

I also do not see other options to add the rigidity parameter to the game than the two we brought up so far. I think the advantage of your idea with the XML file is, that there is no need to adapt all "level" files. However, this would lead to the effect, that level designers will have less choice and that there will be an additional config file that must be updated frequently. However, this would make the game more coherent, e.g. bushes will have the same effect in all tracks.

Either way, if the information is missing in the level files or in the new XML file, the affected objects should have no rigidity. So the game should behave the same as so far. Only if the parameter is explicitly added, then the objects will receive rigidity.

Both options can be implemented. I am not sure yet which one to choose. Maybe there are better solutions than the two above. Let's see.

[marsch84]

Please use the third patch that I attached below this comment. It adds the little crash noise whenever a collision with a road object occurs.

[Onsemeliot]

I applied the third patch and it works flawlessly. But I didn't hear any crash sound. (Shouldn't I have an additional sound file? Or did you use a sample already present in our data folder? Maybe I turned down the sfx volume to much to actually hear it.)

It indeed is very odd that grass behaves like solid rocks. I don't want to actually upload the present state as a new revision since it causes serious problems with some maps where cars actually need to get through grass. Could you implement the vegetation xml file option in a reasonable amount of time?

I am only uncertain how to deal with custom sprites I am using in some maps. Would the game just use certain rigidity values based on wich vegetation sprite is loaded – no matter if it was loaded as a vegetation sprite or as a road sign? In some cases I used vegetation sprites instead of road signs because I wanted to place trees at certain spots on the map in a clearly defined size.

And I used some castle sprites I placed as huge traffic sign sprites in the distance. In those cases it might be better to have a flat rigid body the with and height of the actual sprite instead of just a rigid core. (But on the other hand such use cases aren't important and a dirty hack anyway. It is probably better to keep the code simple and to ignore such special cases in favour of having the intended behaviour in most cases.)

Indeed it would be best to add the new feature by giving zero rigidity to all sprites except defined differently in the new XML file.

[marsch84]

I reused the "bang.wav" sound file for the crash, so there is no need for a new audio file. If the vehicle.cpp file contains the line below, the sound should work:
CLAMP_LOWER(crunch_level, crashforce.length() * 0.00001f);

Can you give me the names of maps that contain special use cases for sprites?
Maps in which the cars need to get through grass.
Maps with vegetation sprites are used as road signs.
* Maps with castle sprites

I will have a look at all these special use cases to find the best mechanism to add the rigidity attribute.

[Onsemeliot]

Interesting, I indeed have only the following line (1083):

CLAMP_LOWER(crunch_level, perpforce * 0.00001f);

Should I replace the line? (Maybe this happened because I applied the patches after another not returning to the original revision before.)

In many maps grass sits to close to the road to be an actual obstacle. For example:
* Mountain Pass
* Between Rocks
* Blue Noon
* Brittania
* Dark Bushes not grass but thick leafes that should have some rigitity
* Mudbath
* Pulp : cars can fly (plugin race) it actually contains a passage though grass

There are for custom sprites in the following race:
* Castle Rock (the castles in the distance)
Unfortunately, other such cases are only found in events that need to be unlocked.

Vegetation sprites for technical reasons placed as traffic signs:
* Slip here the momentray behaviour is actually beneficial.
* Vast Through palm trees in some curves ... but probably hard to find in this huge map
Other such cases are found in the event "Smooth Globe" that needs to be unlocked.

[marsch84]

Did you apply "collision2.patch" instead of "collision3.patch"? I checked the "collision3.patch" file attached above and it contains the line of code responsible for the crash sound.

I checked the races above and I think all use cases could be solved through the additional XML file. I attached a sample XML file. The file would list textures with a specified rigidity. The sprite attribute will be used to match the texture against the same attribute in the "level" files for either "foliageband" or "roadsign" nodes.

By the way, the race "Slip" does not seem to work. The game crashes soon after the race is started.

[Onsemeliot]

I first applied "collision2" and then "colission3". I probably should have reversed "collission2" before I applied "collision3".

all use cases could be solved through the additional XML file.

I think so too. Great, the XML you propose looks very clear to me.

"Slip" does not seem to work.

Are you sure? It is a rather performance hungry map because I positioned over 800 "post.png" sprites in there – twice every few meters along the road on both sides (as road signs) in order to get these regular posts that are common on country side roads. You could remove those in the level file to see if the issue is just a performance problem on your system.

Maybe you have an idea for a better way to implement something like this. In the past I tried to achieve a similar effect by using the foliage map but that positioned posts randomly and in different sizes. Therefore the result was not very satisfying. In this map I tried to use brute force – which was really a lot of work since I needed to position each post at exactly the spot I wanted it to sit in. But as a result the map probably needs more ressources than any other map.

[Onsemeliot]

Now I pulled down a clean version of the latest release and applied your last patch again. Now the sound plays too. :)

[marsch84]

I attached a new patch that contains the rigidity feature. I renamed the XML file and some of the identifiers inside, because the new wording seems to fit better. The current XML file can be tested with the "Warm Up" level from the "Trigger Cup" event. I added the foliage of the level to the XML file and chose some values that feel ok for the gras and the palms. I assume, that you have to revert to revision r990 before you can apply the new patch.

I can try to find out why the "Slip" level crashes on my machine with a debugger. Maybe there is a possibility to fix the issue.

[Onsemeliot]

I tried to use: "svn patch --reverse-diff collision3.patch" to undo the patch before I applied your new patch and it looked fine but I actually needed to download the original revision again before I could apply the patch in a way allowing me to carry out the make command afterwards again.

I am amazed how fast you are able to figure out how everything fits together and help out in such an essential way in this project. In r991 added rigidity values for the other sprites (but not the castle and other non-standard sprites yet).

Now I finally can create sensible maps with trees that are actually obstacles without the need to oddly abuse the heightmap for doing so like in "Alps Trophy's" map "Dark Forest" or as in "Swamp".

However, when testing it I discovered that the car sometimes hits in jumps sprites that end clearly below the car. Do the rigid bodies maybe not scale with the sprite size? In "Garden Dare" there are several jumps in curves where the car should fly over some bushes but still get knocked out mid air.

[marsch84]

You are right. The collision detection as it is implemented right now is basically a 2D thing along the map surface. So if you jump over sprites, they will still affect your car. This is certainly something that I will change. There should be a way to get the height information of an object. After all different objects of the same kind already have a different height when placed on the map. Then I can change the collision detection from 2D to 3D.

[marsch84]

So here I am with another patch. I changed the collision detection to 3D. I did a few jumps in "Garden Dare" and it seems to work fine.
The crash behavior also changed a little bit, because the force is now applied in the center of the vehicle in Z direction. Before it was applied at the lower end of the foliage object. This made more sense to me.
If you have further findings like this, please let me know.

[marsch84]

Please use the new patch below. I found an issue in the terrain.cpp file in the previous patches.

The posts in the "Slip" track behave quite strange, because they are essentially two posts at the same place with different angles. So the force of the crash is applied to the vehicle twice. I think the cleanest solution would be add a "spritecount" attribute to the "roadsign" element in the XML file. This would also reduce the work for the track designers. What do you think?

The crash in the Slip level seems to be related to the 3D graphics part of the game. I have a Linux Nvidia Optimus setup and the game works well, if I run it with the Nvidia card. However, if I use the Intel chip, the game crashes. Maybe the Intel hardware has some limitations which are not handled correctly by the game. I will look into it.

[Onsemeliot]

I think the cleanest solution would be add a "spritecount" attribute to the "roadsign" element in the XML file.

I would welcome this. But what would the "oridegrees" value then do? Setting the rotation value for the first/base sprite? Would all base roadsign sprites be placed with zero rotation if the "oridegrees" attribute is omitted?

And would you add this "spritecount" attribute to the "roadsign" tag or to the "location" tag? (I suspect the first option would be more practical.)

I tested and added your most recent patch in r992. The sprites in "Garden Dare" behave very well now.

In addition I prepared Slip for your proposal by removing half of the posts (those just rotated 90 degrees). And in addition I optimised some rigitity values in rigidity.xml. It seems any value above "0.2" is pointless because even with this low value objects can not be penetrated. It seems higher values do only increase the force. To me more force does feel less realistic.

[marsch84]

The attached patch fixes the crash with the Intel graphics card on Linux when starting the "Slip" track. The issue was, that the GPU was out of graphics memory, because the game stored the sprites of the road signs in the memory multiple times too often. I assume the original creators of the game engine did not expect so many road signs within one level, so they did not see this as an issue. I vastly reduced the number of copies of the road signs in the graphics memory, so now it works.

I agree, that the "roadsign" tag is the best place to add the additional attribute for the spritecount. I think the goal is, that all signs of the same type look exactly the same. In case of multiple sprites the attribute "oridegrees" defines the angle of the first sprite. The other sprites should be placed in relationship to it based on the "spritecount" attribute. I am not sure how the game handles the road sign object right now, if the "oridegrees" attribute is missing. Maybe there is a default orientation. In this case the other sprites can just be rotated based on the default orientation.

[Onsemeliot]

You again seem to have successfully solved a problem in r993. This time the heavy overuse of memory for roadsigns. (Roadsigns are a relatively new feature in Trigger Rally that wasn't present in the original version of the game. So the original developer Jareiko isn't responsible for how road signs are handled.)
In the mean time I have checked that indeed roadsigns are placed with zero rotation if positioned without the "oridegrees" attribute. I changed the "Slip" map to omit this value and instead prepared the map for using the "spritecount" attribute by including it into the "roadsign" tag. This way you should already have a test case for implementing it in code.

[marsch84]

Thank you very much for preparing the level file. That was an easy one. The code to have multiple sprites for road singns has already been there. It was basically deactivated. I just had to activate it and add the code to read the new attribute from the XML. As usual the patch is attached below.

[Onsemeliot]

Allright, I didn't find any issues either and just added your patch in r994.
Now I wonder if it would be a good idea to create objects like rocks as sprites. Or if we want to even introduce real physical objects in order to allow things like houses or walls.