As per discussion on the mailing list there is a request for detecting collisions with Cones rendered around the track surface.
This ticket is intended as a location for some quick proof of concept code.
The supplied track is attached, but has a problem that the first row of cones are grouped together (called 'Color_01.026') where as the others are separate rendered objects.
Locations (as imported into Blender) are described in attached files.
With the Simuv4 dumping the corner locations of the car, when almost hitting the 'Color_01.000: (197.95593, 218.97064, 0)' cone head on:
https://sourceforge.net/p/speed-dreams/code/HEAD/tree/trunk/src/modules/simu/simuv4/collide.cpp#l86
So it looks like the co-ordinate systems line up. We just need to work out how to evaluate the collisions and what to do when they actually occur...
First rough attempt/proof of concept
Some thinking out loud, regarding how libSOLID works
http://solid.sourceforge.net/solid2.html#SEC14
_nitially, the default response is nil and all pairs of objects have a default response. If for an object pair, one of the objects has an object response defined, then this response overrules the default response. A pair response overrules any object or default response. If for both objects there is an object response defined, then one of the responses is chosen. In this case, one of the responses may be forced to be chosen by defining it as a pair response. _
So at present we have a 'default response' (SimCarCollideResponse) and an 'object response' (SimCarWallCollideResponse). The 2nd is for Walls (fixed-objects) and takes presedence over car-car collisions (which defer to the 1st).
If we add another class of objects for the cones we will have to figure out how place them in the scheme of things, which probably means an 'object response'. Do we register all of the cones, or use our current concept of pre-selecting the ones near the car(s)?
If the cones become movable then that could get even more complicated.
Another patch, this one uses libSOLID to more accurately detect collisions
Stress test
Builds and works on Windows 7. Nice!
How to limit rotation on Windows
... its full of cones.
updated to adjust mat references
Blender and AC3D cones
I made some more appropriately sized cones in blender and exported to ac3d.
The edit the resultant file to add in the material lines from the cones and adjust the number the of kids.
alternating groups of cones on left and right
Got the 'flow' a little better. Can add cones quickly and easily to track.
1. Generate track
2. Add cones
3. Edit track to insert Material statements and change number of kids.
Since we're using a compiled in list of cones you have to copy the 'cones2.ac.h' and then rebuild
$ cp cone2.ac.h /storage/speed-dreams-git-svn/src/modules/simu/simuv4/ $ cd /storage/speed-dreams-git-svn/ $ make
You should then be 'good to go'.
Simon
Rotated cones appear OK in Blender, but not in game.
I started looking at how I could rotate (laying down) cones, and it appears that it's pretty easy
However the rotated cones do not appear in game (only the 'rot=0' ones do). Importing the '.ac' into blender shows that they are there.
Perhaps a bug in the speeddreams '.ac' reader.... the file has bits like
much less detailed cones (less faces/vertices)
Regarding rotation, it appears that order statements in '.ac' file is important. The following 'works', but rotates in game to opposite direction to that seen in Blender.