Page 7 of 7
Re: Some handy scripts
Posted: Tue Jun 25, 2013 3:27 pm
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...
Re: Some handy scripts
Posted: Wed Jun 26, 2013 1:11 am
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.
Re: Some handy scripts
Posted: Wed Jun 26, 2013 6:58 am
by haggqvist
Thank you!
Re: Some handy scripts
Posted: Thu Sep 12, 2013 4:06 am
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...
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.
Could i have any help for importing the terrain png, tried everything, searched for tutorials but could not find it.
thx
Re: Some handy scripts
Posted: Thu Sep 12, 2013 5:04 am
by wheels1758
Re: Some handy scripts
Posted: Thu Aug 13, 2015 11:55 pm
by nickuzick
BUMP!
Is there a script released for signup Supercross races? I thought it might me in here and it wasn't
Re: Some handy scripts
Posted: Sun Jul 10, 2016 12:10 pm
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)