Some handy scripts

All about making tracks for MX Simulator
wheels1758
Posts: 4132
Joined: Tue Oct 21, 2008 5:20 pm
Location: Washington, USA
Contact:

Re: Some handy scripts

Post by wheels1758 »

haggqvist wrote:On the tech side; as it is now the fencing is split up into 14 parts for the GP-tracks, i.e. one .jm placed at 0,0 for every banner texture.
Would the collision testing be faster if the fence objects where split up even further e.g. with a separate .jm for every single continuous segment that has the same texture?
My idea was to place 2-4 spheres along the top edge of each fence segment and set up the collision values so that it's fairly easy to go across it at slower speeds while still making you crash when you run into it at higher speeds and lower angles of intersection.
I don't think it would necessarily be advantageous to split each banner into a separate object for collision testing purposes. If each banner segment is an object, the game will test for collision with a bounding sphere for each segment, each frame. This means there would absolutely be unnecessary tests each frame that could be minimized by keeping the banners in larger sets. Obviously, there will be more tests for the exact collisions since you would be testing against multiple banner segments once you collide with one of the bounding spheres. I think the exact optimized number of segments would depend on a bunch of factors like: track path (will you collide with bounding spheres of banners on other parts of the track), number of banner segments, and number of spheres per segment.

Assuming you only collide with max one bounding sphere at any given point, there are 100 banner segments, and each segment has 4 spheres:

100 segments as 100 objects: 104 sphere tests (100 bounding + 4)
100 segments as 25 objects: 41 tests (25 bounding, 16 object)
100 segments as 10 objects: 50 tests (10 bounding, 40 object)

So you could figure it out like that. Assuming anything I've said here was correct...
jlv
Site Admin
Posts: 14928
Joined: Fri Nov 02, 2007 5:39 am
Team: No Frills Racing
Contact:

Re: Some handy scripts

Post by jlv »

There are two culling levels, the first divides the track into an 8x8 grid and culls objects that aren't in the same grid cell as the bike. After that it culls using the bounding spheres of the objects. If the object passes both tests it will test against the individual spheres in the object.

For efficiency, you probably want about the same number of objects per grid cell as there are spheres in each object, while keeping the bounding spheres as small as possible.
Josh Vanderhoof
Sole Proprietor
jlv@mxsimulator.com
If you email, put "MX Simulator" in the subject to make sure it gets through my spam filter.
haggqvist
Posts: 352
Joined: Sun Jan 31, 2010 11:44 am
Location: Sweden

Re: Some handy scripts

Post by haggqvist »

Thank you!
Image
nioubie
Posts: 1107
Joined: Fri Jun 22, 2012 1:48 pm
Team: *eMc*
Location: France
Contact:

Re: Some handy scripts

Post by nioubie »

haggqvist wrote:
jlv wrote:
haggqvist wrote:Cheers WHEELS, now the track fencing will have extremely annoying collisions for the rest of the GP-series... :lol:
If you do that, try to break it up into multiple objects. One object with hundreds of spheres will be much slower than 10 obects with 10 per object since the bounding sphere test is per object.
It was mostly a joke as I probably won't have time to get it done for the tracks this year but cheers for the heads up.
I really wish there was time for it though as it would be a really handy way of keeping people on the track without littering the things with zillions of bales.

On the tech side; as it is now the fencing is split up into 14 parts for the GP-tracks, i.e. one .jm placed at 0,0 for every banner texture.
Would the collision testing be faster if the fence objects where split up even further e.g. with a separate .jm for every single continuous segment that has the same texture?
My idea was to place 2-4 spheres along the top edge of each fence segment and set up the collision values so that it's fairly easy to go across it at slower speeds while still making you crash when you run into it at higher speeds and lower angles of intersection.

ALL CAPS WHEELS wrote:....Banner Maker Helper Thingy For Blender....
Thank you for taking the time to finish this!

However, I would just like to add that since the release of Blender 2.64 it's really easy to import terrains and there's no need for the gamma-related voodoo of old.
There are now options for setting the color space for a texture in the texture panel i.e. it's now possible to use the source terrain.png from the trackfolder directly as a heightmap for the displacement modifier.
This is really handy because the .blend file for the terrain can now be set up at an early stage since all changes to the terrain.png will be updated automatically.

Here's a screenshot of the texture panel option, just set the value to linear.
Image
Could i have any help for importing the terrain png, tried everything, searched for tutorials but could not find it.
thx
wheels1758
Posts: 4132
Joined: Tue Oct 21, 2008 5:20 pm
Location: Washington, USA
Contact:

Re: Some handy scripts

Post by wheels1758 »

nickuzick
Posts: 3278
Joined: Mon Oct 14, 2013 9:42 pm
Location: Nova Scotia
Contact:

Re: Some handy scripts

Post by nickuzick »

BUMP!

Is there a script released for signup Supercross races? I thought it might me in here and it wasn't
Image
MX4EVER
Posts: 261
Joined: Thu Sep 13, 2012 5:49 pm
Team: MXS-Concept.com
Location: Switzerland
Contact:

Re: Some handy scripts

Post by MX4EVER »

FYI about the saf script, Python version 2.XX is required as 3.XX removed the path.walk module (just faced the issue)
Niko | Mouk Lab | Admin of MXS-Concept // MyMXB // MXBikes-Shop // among others. | YouTube
Image
Post Reply