Tracks for first irrlicht release

[hiker]

Hi all,

since we have finally managed to release a first alpha version of stk - 0.7, we would like to get as much help as possible from 3d modeler to add more tracks to stk 0.7. Be it by simply converting an existing track to irrlicht, by improving an existing track to make use of more features, or by making completely new tracks.The most important documentation would be the http://supertuxkart.sourceforge.net/Irrlicht page. It includes a link to the track exporter, and details about how to define special effects (like transparency) for textures.

It might also be a good idea to give some ideas on what new features can already be used in tracks. While I am certain that not everything will work out of the box, atm we are focused on fixing any bugs you find asap. And at the same time we try to include any new feature you might want to use as well. In terms of track we would very much like to make the tracks in stk more interesting, less static. Some examples which you can already use:

• Animations - that can be a mixture of skeletal animations (e.g. for an animal walking) and IPOs to move/rotate things.
• Alternative ways, and perhaps hidden shortcuts. Give people something to discover in many tracks.
• Make better use of physics, e.g. add slow-downs to certain part of the track, and add a ramp so that by driving properly you can jump across it. While I agree that the current physics are far from ideal, we want to do a 0.7 release with the same physics (to save us some time so that we can get the 0.7 release out earlier), and then after this release start improving the physics.
• More particle effects, e.g. grass being thrown in the air. We have some effects already in place (water splashes), but are happy to add more.
• Perhaps special sound effects - e.g. different sound when driving over a wooden bridge, ... - of course we would need the sfx, too.

And more - we are open to suggestions, and while we can't promise that we will/can do everything you ask for, any feature that would be used in several tracks would obviously receive high priority It would be good if we could get a sample of what you want to do if we need to implement something. For example, while ramps should work (just model a ramp with a zipper texture), I am sure we need additional tuning. So please send/post any .blend files since it saves us a lot of time creating a test case.

If you want to work on converting a track, please post here so that we don't have several people working on the same track. Also let's do some brainstorming on what features would be nice to have (esp. if you already have a track that is ready to use this features, instead of a theoretical idea of things).

Cheers,
Joerg

[sj04736]

I've started on Canyon, and I have *almost* everything working. The things that aren't working are the lap-counting lines (checklines) and items (which I assume are being placed above the skybox).

The main problem I'm having is that all the items are at z=10, and I couldn't actually find the items to move them, but if I remove the z coord from the scene file, then they do get placed above the skybox.

Also, the lap-counting checkline works, it is the second checkline that is the issue.

I'll attach an archive later today when I have access to that computer...

[EDIT] Attached file
[EDIT2] Woops, forgot I actually had disabled the skybox in that version. Attached new one.
[EDIT3] Fixed items, using irrlicht's skybox, fixed lap-counting. TODO: re-export when zipper support is added to the track-exporter (blend work is already done, just needs re-export)
[EDIT4] New version with zipper locations exported (not displayed in 0.7 alpha 1 or SVN) TODO: Re-export when direction information is exportable

[Pixel]

Hello.

I'm not sure if I can help with track conversion right now, but if it's alright I'd appreciate a binary and libs only package of the alpha release. I can grab the rest from SVN.

As far as new features go, I'd like to see the ability to use frames of the race action as textures on other objects. MarioKart64 used something similar to simulate a "stadium screen" in a couple of tracks. Basically, a track frame was copied onto another object (a screen) on the track.

I've heard in the past that nVIDIA GPU hardware had trouble doing this operation quickly. A frame-for-frame copy would probably be too resource intensive regardless of the hardware. MarioKart64 copied a small number of frames over for every second of game time. That might do well enough.

Are moving textures implemented yet? If not, that would be very handy.

Custom connect point for parachute item. On my Pickup, it attaches at the back of the cab, rather than the tailgate.

A way to make credits for karts and tracks more detailed, and easier to update. Maybe, one section for kart or track name, another for the author(s)/designer(s), and a third for contributors.

This last feature I think would really be beneficial.

[horace]

The main problem I'm having is that all the items are at z=10, and I couldn't actually find the items to move them, but if I remove the z coord from the scene file, then they do get placed above the skybox.

i am the creator of the canyon track. i always use several layers in my .blend files. probably the items are in a hidden layer?

EDIT:

[EDIT2] Woops, forgot I actually had disabled the skybox in that version. Attached new one.

do you still use the modeled skybox? it would be better (since it would avoid problems with the far clipping plane of the camera) to use irrlicht's native skybox feature and simply specify the sky textures. is this supported already by the current alpha version?

[Varivar]

The conversion of the mines track is nearly done The zip archive contains all files to play the track. Besides converting the track to irrlicht, I also added some animations, replaced almost all textures and I made the track a bit harder to drive and longer. If you find any bugs, please report them here. I know some karts are having trouble with this track (e.g. Gooey always crashes at the first cave with water)

I will probably update the track soon, especially if light mapping becomes reality.

[Auria]

Hi Varivar,

GREAT job I am adding the track to SVN at the moment.

Just a quick question though : you used a couple jpeg files; do you have the originals in lossless format? We like to keep a lossless verison of everything saved saved in lossy formats

[Auria]

do you still use the modeled skybox? it would be better (since it would avoid problems with the far clipping plane of the camera) to use irrlichts native skybox feature and simply specify the sky textures. is this supported already by the current alpha version?

I know skydomes are; for canyon, we'd need a sky cube. @Hiker, is this implemented?

I will probably update the track soon, especially if light mapping becomes reality.

It would be cool that it does, but I really can't promise it will be "soon"

As far as new features go, I'd like to see the ability to use frames of the race action as textures on other objects. MarioKart64 used something similar to simulate a "stadium screen" in a couple of tracks. Basically, a track frame was copied onto another object (a screen) on the track.

There was a discussion about this. It is feasible, the main problem is that it can put a high load on the graphics card, so we'd need to also add facilities to deactivate that kind of effect

Are moving textures implemented yet? If not, that would be very handy.

Yes they are, check the links to the wiki in my post about the release

Custom connect point for parachute item. On my Pickup, it attaches at the back of the cab, rather than the tailgate.

Maybe, but my favorite solution at the moment would be to completely remove the parachute, and add a nicer weapon instead

[xapantu]

The new tracks mines is GREAT. I like very much it. Animations are very impressive

[sj04736]

I agree. The new mines is incredible. Unfortunately, it brings my frame-rate down though

[Pixel]

When you say "weapon", do you mean replacing the 'chute in both the gift box and banana peel situations?

I'm inclined to agree - It was a nice weapon, but I can tell by the way it worked it's going to be difficult to implement with "real"
(parachute-like) physics. From running older versions it felt pretty clear the chute was not actually causing air resistance. If an
affected kart flew over an edge into open space, it would start speeding up with the chute still attached. I do think some detailed
aerodynamics in STK wouldn't hurt, but making the chute play nice with that would be tricky.

Instead, what about about capturing a kart in a bubble and letting it drift above the track for a few seconds? Perhaps if another kart
touched the bubble, it could pop and drop the affected kart instantly?


I suspected the "stadium screen" concept (could it be called "framebuffer copying"?) would cause a lot of work for the video card.
A true "frame-for-frame" copy would likely be too much work for quite a few cards, especially with refresh rates over
60 Hz. I was thinking once every third frame or less.

MarioKart 64 copied very few "frames" from what I could tell- perhaps less that one "frame" out of four (actually "fields" on
interlaced TV, but basically the same idea.)

As for turning it off, what should be done to the object face that would otherwise show the framebuffer texture? Should it be left untextured,
or a neutral color? Should it display a "default texture" (either the STK logo, or an alternate texture of the track designer's choosing)?
Maybe just the track mini-map scaled to a percentage of the size face's size?

Were this to be implemented, I like the "default texture" idea best myself.


What do you think about more detailed credits in the kart/track information? It might be easier to display when multiple authors
or contributors work on the same track or kart.

[horace]

you mean render-to-texture? it has nothing to do with copying the frame buffer and isn't really slow. just like rendering a second camera view (but it can be in a much smaller resolution, render less details,...). it should be very doable even on older cards. don't know how good irrlicht's support for it is though.

[hiker]

do you still use the modeled skybox? it would be better (since it would avoid problems with the far clipping plane of the camera) to use irrlichts native skybox feature and simply specify the sky textures. is this supported already by the current alpha version?

I know skydomes are; for canyon, we'd need a sky cube. @Hiker, is this implemented?

Yes, but I haven't tested it (since I had no model to test), and it's currently not supported in the track exporter. The sky-dome is done by setting id-properties (and I only now realised that this is not documented in the wiki), what's the best way to handle sky-boxes in blender? The same (i.e. a list of 6 texture names, perhaps in a property called sky-box), or should I take them from a mesh (the problem wit this is that it's a bit difficult to define which side is forward etc. The vertices in blender are basically unsorted, so I would have to compute the normal, which leads to problems if the normals are reversed, or compare the coordinates with a certain epsilon (e.g. what if the sky-box is not parallel to the axes)).

To test this, add the following lines to the scene.xml file:

{l Code}: {l Select All Code}

<sky-box texture="texture1 texture2 ... texture6"/>


With just the name of the 6 textures (just repeat one texture for the bottom) - order is top, bottom, left, right, front, back.

I will probably update the track soon, especially if light mapping becomes reality.

It would be cool that it does, but I really can't promise it will be "soon"

Neither can I, but I will certainly try to add this asap when I get my hand on an example

Cheers,
Joerg

[hiker]

The new tracks mines is GREAT. I like very much it. Animations are very impressive

I agree - and it's great to see that the track exporter and irrlicht work so far. I only ever tested it with small examples, never had something real.

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!

Cheers,
Joerg

[hiker]

When you say "weapon", do you mean replacing the 'chute in both the gift box and banana peel situations?

I'm inclined to agree - It was a nice weapon, but I can tell by the way it worked it's going to be difficult to implement with "real"
(parachute-like) physics. From running older versions it felt pretty clear the chute was not actually causing air resistance. If an
affected kart flew over an edge into open space, it would start speeding up with the chute still attached. I do think some detailed
aerodynamics in STK wouldn't hurt, but making the chute play nice with that would be tricky.

No, there is no aerodynamics implemented, and I don't actually intend to do this (i.e. the upper kart speed is an artificial enforced limit, not an effect of the air resistance).

Instead, what about about capturing a kart in a bubble and letting it drift above the track for a few seconds? Perhaps if another kart
touched the bubble, it could pop and drop the affected kart instantly?

Or if you shoot a cake it would explode the bubble. I like this idea, might be a nice replacement for the anchor, since you would have an option to reduce the effect (if you store a weapon for this).

I suspected the "stadium screen" concept (could it be called "framebuffer copying"?) would cause a lot of work for the video card.
A true "frame-for-frame" copy would likely be too much work for quite a few cards, especially with refresh rates over
60 Hz. I was thinking once every third frame or less.

While it would have some performance impact, it could certainly be done, and we already have a means to change the graphics detail level.

Give me a track that uses it, and I will see what I can do.

Irrlicht can render to texture, so it's mainly a thing to add to the exporter (separate camera position), and then to stk.

As for turning it off, what should be done to the object face that would otherwise show the framebuffer texture? Should it be left untextured,
or a neutral color? Should it display a "default texture" (either the STK logo, or an alternate texture of the track designer's choosing)?
Maybe just the track mini-map scaled to a percentage of the size face's size?

Or just one frame - we create the texture once at runtime (before starting the game), and just not modify it. Or perhaps more a static picture - whenever a player kart crosses a certain check line, a picture is taken and displayed.

Were this to be implemented, I like the "default texture" idea best myself.

We can have scrolling stk advertisings there. Or mention other open source games. Or perhaps even a picture from the last race (i.e. each race would have a certain picture spot, and we keep the last picture in memory, and use it for this (we still need a default in case that it's the first race).

What do you think about more detailed credits in the kart/track information? It might be easier to display when multiple authors
or contributors work on the same track or kart.

It would be good to have this, but not with the current design. Ideally (but after 0.7) I would like to have an introductory 'fly over' a track, so we can show of some noteworthy parts of each track, and the (then longer) credits could be displayed while this is being shown (of course the intro can be skipped).

Cheers,
Joerg

[horace]

It would be good to have this, but not with the current design. Ideally (but after 0.7) I would like to have an introductory 'fly over' a track, so we can show of some noteworthy parts of each track, and the (then longer) credits could be displayed while this is being shown (of course the intro can be skipped).

i really like the "fly over" idea.

would it also be possible to automatically generate the track screenshots from this fly-over? this really would be convenient for track creators.

[xeno74]

Hi,

I've published a video of Old Mine -> http://www.supertuxkart.de/stkvideo4.html

[hiker]

would it also be possible to automatically generate the track screenshots from this fly-over? this really would be convenient for track creators.

Not really, we have to display the screenshots in the gui without loading the tracks first. Not sure if we can easily add a screenshot feature to stk: press a key, render to texture, save the texture (irrlicht has some image writer included, but never had a look at that). But that would be done later.

Cheers,
Joerg

[hiker]

Hi,

besides the option of having a 'monitor' in a track showing the race happening, I had one other idea that would be easy to add:in addition to an animated texture, you could also define a force acting on the karts. This would allow us to have a conveyor belt, or a fast streaming river (through which you could drive and be faster if you drive with the flow - we already have some water splashing effects), ...

Just as a suggestion If we have a track that can make use of this, we will try to implement this.

Cheers,
Joerg

[Pixel]

Or if you shoot a cake it would explode the bubble. I like this idea, might be a nice replacement for the anchor, since you would have an option to reduce the effect (if you store a weapon for this).

That sounds good. Should the bowling ball be able to impact it (if the bubble drifts low enough or the physics send the bowling ball into the air)? Should the player firing the cupcake (or maybe bowling ball), be impacted in some way if they are too close? Will the freed kart just drop, or should the physics of the explosion be modified by the bubble popping?

We can have scrolling stk advertisings there. Or mention other open source games. Or perhaps even a picture from the last race (i.e. each race would have a certain picture spot, and we keep the last picture in memory, and use it for this (we still need a default in case that it's the first race).

I think we should give the author the option to provide their own default texture instead of the framebuffer, then use a built in default if the author doesn't provide one. For my part, I'm afraid much of the discussion about the framebuffer is theoretical ATM- my GPU isn't really suitable for any 3D modelling . It'll barely play most 3D games anyway.

[hiker]

Hi,

[EDIT3] Fixed items, using irrlicht's skybox, fixed lap-counting. TODO: re-export when zipper support is added to the track-exporter (blend work is already done, just needs re-export)

How did you fix the lap-counting? It might be worth adding this to the documentation if it was an easy to make mistake.

I've added support for zipper to the track exporter. Zipper won't show up in stk yet (I think), but I'll work on that.

Cheers,
Joerg

[sj04736]

How did you fix the lap-counting? It might be worth adding this to the documentation if it was an easy to make mistake.

I'm not quite sure, but I think the second checkline was slightly too far below the track. All I did was move it up slightly.

Zipper won't show up in stk yet (I think), but I'll work on that.

No, it does not show up yet. And unfortunately, because the zipper is an actual model that doesn't rotate, the header (I think that's the right term... hpr) needs to be exported too, and the track also relied on pitch and roll being calculated during the race because there were zippers on slopes. For now, I'll edit my post above and attach a version with the (currently not-displayed or rotated) zippers.

[Varivar]

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 agree. The new mines is incredible. Unfortunately, it brings my frame-rate down though

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).

Instead, what about about capturing a kart in a bubble and letting it drift above the track for a few seconds? Perhaps if another kart
touched the bubble, it could pop and drop the affected kart instantly?

I like this idea. However, I think this is more suitable for a banana than as a weapon.

Just a quick question though : you used a couple jpeg files; do you have the originals in lossless format? We like to keep a lossless verison of everything saved saved in lossy formats

I have Gimp files of some textures, I just need to find them. I didn't really see any graphical difference between the png and jpg textures, so I decided to use jpg to keep the file size down.

[horace]

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!

Not really, we have to display the screenshots in the gui without loading the tracks first. Not sure if we can easily add a screenshot feature to stk: press a key, render to texture, save the texture (irrlicht has some image writer included, but never had a look at that). But that would be done later.

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,...

[horace]

i always found the noticeable repeating pattern on the track.* and track2.* textures a bit annoying. i overhauled them. what do you think? are they better than the old ones?

[Varivar]

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.

That would be very useful.

i always found the noticeable repeating pattern on the track.* and track2.* textures a bit annoying. i overhauled them. what do you think? are they better than the old ones?

I think they look very good and realistic. Great work

I improved the driveline of the mines track and removed some objects the ai was running into. Now the ai is able to complete a full lap without crashing