Tracks for first irrlicht release

[hiker]

I know this problem, I have it too when playing with many ai carts or playing multiplayer mode. I can try to reduce the polycount, but I really hope the rendering performance will be improved. Is 15000 polygons acceptable for irrlicht? Just for comparison: Tux Tollway (the 0.6 version) still had more polygons than this track (around 30000) while it ran smoother on multiplayer mode (0.6).

polycount isn't the only thing that matters for performance. often stuff like overdraw affects it more. it would be good to have some statistics which shows where the time gets spent in the engine, so that people don't start to optimize wrong bottlenecks.

@sj04736: i have also provided 512x512 versions of the skybox images. they would look much better. 256x256 isn't really enough for a skybox. thanks for converting the track!

I agree. Atm I think we have two issues:

• Irrlicht always renders the whole track, no culling (since it's apparently faster to render everything with vbo support than using the octree for culling).
• Due to the character animations karts are not really optimised anymore (we previously had display lists). We probably need some advise here - one option might be to split the 'karts' in the karts (without wheels could use vbo) and characters, which need animations.

I've started to look at what stats irrlicht provides, and will add output of that later on.

Note also that at least some of the binaries (Macs) are not optimised.
...

but couldn't you check if changes got done to the track, and if yes, make new screenshots from some points at the camera fly-over? only if the track gets started for the first time after the changes got made. i always found it a bit cumbersome to update my screenshots after changes of textures and other details of my tracks. you have to start supertuxkart, somehow achieve a nice camera perspective (which can be hard), take a screenshot, rework the screenshot in gimp since the aspect ratio doesn't fit,...

OK, I'll put it on the todo list. But probably only for post 0.7 - once I've worked out how the camera flight over might work, it should be possible to add one camera position for the screenshot.

Cheers,
Joerg

[hiker]

is it already possible to add physics objects to the track?

Yes, to a certain degree. See description of track exporter.

for example it would be cool if it were possible to crash through a brick wall for a shortcut.

That's rather difficult. First of all stacking bricks is not trivial for the physics, but it will also cause some physics overhead to have really deformable tracks. It's not exactly the way I would imagine STK to go. Perhaps this could be done as some kind of animation (which would get started when a kart crosses a certain check line).

or the vulcano could spew rocks. this would need some kind of adjustable emitter object. and maybe it would also require to delete the rocks again once there are too many (or at least once they fall into water or something?) so that it doesn't get too slow after a while.

We've done some tests, and that should still work in STK: if a physical object gets a z position of less than -100 (or so), it will be re-spawned at the original position. We could add some initial velocity to the object, so that it will fly upwards initially. Or it could be done as an IPO animation. If you need more, we can add some kind of emitter, but we have to find a way of restricting the number of created objects.

Cheers,
Joerg

[hiker]

I believe you can do this with animations as well. You can add several animated rocks to the scene. This way you will have more control over the rocks as well.

i don't think mixing physics with animated objects works very well. the animated objects probably get seen as objects moved by infinite force by the physics engine. this can lead to all kinds of trouble like physics explosions or physics objects pushed through walls. at least this is my experience from working with other game engines...

That's the reason why I want to replace the current way of explosion/collision handling by a kind of animation (as mentioned elsewhere in this forum): it's fairer (since delays are the same and not dependent on some luck), has advantages in networking (more predicable movement means less synchronisation), and as you mention: allows better support animations. It's still probably best to make the rocks real objects (instead of IPO animated).

Cheers,
Joerg

[horace]

You don't have to use both, it can be done with animations only. It will be harder to make it look realistic though.

but isn't the idea that the rocks can hit the karts? then you would have interaction between animation and physics.

That's rather difficult. First of all stacking bricks is not trivial for the physics, but it will also cause some physics overhead to have really deformable tracks.

they could sleep until they get hit.

however, these were just some ideas. i will have to find some time first anyway for doing another track.

[hiker]

One small suggestion though: I think it would make the track even more interesting if the animated 'karts' (whatever they are called) would at one or two places cross the track or run on the track (and make them interact with the karts). This way karts would have to drive more careful to avoid bouncing into them. But even without this it's a great track!

I thought of this as well, but will the ai carts be able to avoid hitting the carts? This might be interesting for other tracks as well (like a track with a volcano shooting rocks on the track)

I wouldn't worry too much about this, since there isn't exactly much traffic on the road We can probably add some avoidance the AI, since it's supposed to already avoid hitting other karts.

Cheers,
Joerb

[hiker]

You don't have to use both, it can be done with animations only. It will be harder to make it look realistic though.

but isn't the idea that the rocks can hit the karts? then you would have interaction between animation and physics.

Yes, but as soon as the collision is detected, we would trigger the 'wild rotation' subroutine for the kart, and remove the rock - so no actual physics collision would happen, therefore avoiding the problem of 'uncontrolled' physics interaction (which we indeed have atm).

Cheers,
Joerg

[Auria]

Note also that at least some of the binaries (Macs) are not optimised.

Not true :P It has debug symbols, but it optimized

[portets]

in the 0.7 release, how do you unlock tracks? i edited the challenges file and replaced all falses with trues.

[horace]

in the 0.7 release, how do you unlock tracks? i edited the challenges file and replaced all falses with trues.

remove the challenge file from the track directory or try renaming it.

[Auria]

in the 0.7 release, how do you unlock tracks? i edited the challenges file and replaced all falses with trues.

that should do it, doesn't it work? (be aware that on many platforms, the user file locations moved with 0.7, so make sure you aren't editing the 0.6 file - on Linux, it moved from ~/.supertuxkart to ~/.config/supertuxkart; on OS X, it moved from ~/.supertuxkart to ~/Library/Application Support/Supertuxkart; and on Windows, it moved from the executable's directory to the new Windows Vista/7 standard, don't remember it by heart)

[portets]

okay, thanks. i edited the .6 version in /.supertuxkart

[Stevo14]

Hey everyone,
I just wanted to post here that I am (still) working on the island track. All that is left is to (re)texture map the rocks and add some items. I wanted to post here for feedback on the modifications. Also, any ideas to make the cave bit less monotonous (visually)?

[Varivar]

Hey everyone,
I just wanted to post here that I am (still) working on the island track.

Great work! I like it's style. The AI seems to have a lot of trouble though.

All that is left is to (re)texture map the rocks and add some items. I wanted to post here for feedback on the modifications. Also, any ideas to make the cave bit less monotonous (visually)?

Maybe you can improve the cave by using less repetitive textures. Also try Blender's fractal function (F9 -> Mesh Tools).

[Auria]

Hey everyone,
I just wanted to post here that I am (still) working on the island track. All that is left is to (re)texture map the rocks and add some items. I wanted to post here for feedback on the modifications. Also, any ideas to make the cave bit less monotonous (visually)?

Hi,

good job overall; the ship is a nice addition. But :
* i spotted a couple untextured or poorly textured road bits
* as already noted, the cave needs better texturing
* the sky mesh should probably be removed and replaced with built-in skydomes/cubes (and, in any case, it must not be affected by lighting effects creating shadows on it)

[Auria]

sj04736, do you have a more up-to-date blend for Canyon track? The latest one I see still has drivelines in the old format, etc...

[sj04736]

sj04736, do you have a more up-to-date blend for Canyon track? The latest one I see still has drivelines in the old format, etc...

I checked, but I don't seem to have one with updated drivelines (I thought I did?!). All of the items and whatnot should have properties set as per the current standard. I'm not sure why there is no object with the quads. Maybe the old driveline objects worked and I didn't even notice that I forgot to convert them? Perhaps I may have used the conversion script. I don't remember.

[Auria]

Thanks Stephen.

For some reason, I cannot get the textures paths fixed I only ever get the pink "no-texture" filling in Texture view. I don't understand why, even the script to fix texture paths won't work. Could you maybe do :
1) File > External Data > Pack into blend
2) File > External Data > Unpack into files
3) File > External Data > Make all paths relative

If I,m not too bad at blender, this should have copied all textures next to the blend and will be refering to them. If you can send me that, it would be easier for others to use after.

BTW, do you intend to update the drivelines, or should the task be marked as available to others?

[sj04736]

Sorry, I didn't realize that I left the paths as absolute. I only learned that this was bad etiquette when I started working on Snow Mountain. Fixed in attached file.

BTW, do you intend to update the drivelines, or should the task be marked as available to others?

I started to update the drivelines in the attached blend. You'll notice that the driveline object has *many* of the vertices joined to form quads, but they aren't all joined. It still exports properly though. The wiki page used to imply that this was required, but it no longer seems that way (new examples on wiki from when Amazon Jungle was converted). I can remove most of these edges if necessary.

Other changes: I fixed the order of the files for the skybox so the top is rotated properly too, and I removed quite a few redundant driveline vertices as I was joining them.

[Auria]

Thanks Stephen!

I committed the updated track, with a couple more changes by me :
1) deleted sky box, since we're now doing it with irrLicht, no more with a mesh in blender
2) edited the bridge to use the right concrete texture
3) removed the lap count line, since it's now automatically generated from the drivelines
4) marked curve/base objects as "ignore", so only the baked meshes get exported

So if you want to continue working on the track, maybe you should do so directly from the media repo, where textures are all setup properly now

[sj04736]

That's alright. I think I'm done all I know how to do with the Canyon track at this point.