FreeGameDev

I'm currently updating the mine track. The track exporter works fine (I'm already able to drive around against the ai), but I have some problems:
- I don't manage to export separate b3d files. For example I have multiple candles in the track, and I want them to export to one b3d file. I've set the following properties to each model:
type: object
name: lamp1
The script adds references to the model in the "scene.xml" file, but it doesn't create the model file (which should be "lamp1.b3d"). Any ideas what's going wrong?

- Is it possible to have semi-transparency in textures? I can use textures with full transparency, but semi-transparent pixels become solid.

Varivar {l Wrote}:I'm currently updating the mine track. The track exporter works fine (I'm already able to drive around against the ai), but I have some problems:

Great!

- I don't manage to export separate b3d files. For example I have multiple candles in the track, and I want them to export to one b3d file. I've set the following properties to each model:
type: object
name: lamp1
The script adds references to the model in the "scene.xml" file, but it doesn't create the model file (which should be "lamp1.b3d"). Any ideas what's going wrong?

I am checking that now. One thing you can try: add a property 'interaction' and set it to 'static'. Does this help?

- Is it possible to have semi-transparency in textures? I can use textures with full transparency, but semi-transparent pixels become solid.

We are all still struggling with irrlicht materials. It should work if you define a materials.xml file containing a line like:

{l Code}: {l Select All Code}

<material name="XXX.png" alpha="Y"/>


Plus of course the xml header etc., just use an existing materials.xml file as template (and note that the materials.xml file in data/textures is not correct yes, it contains settings like alpha="0.8" etc, which are not valid). Let me know if this works or not.

Cheers,
Joerg

Hi,

forget what I wrote, it was a bug, and it's fixed now (r4490) - thanks! I've also updated the wiki pages, so you can download it from there, too - just make sure to refresh the page to get the latest version.

Let me know if you have any more problems.

Cheers,
Joerg

PS: Note that we are currently not sure that using this kind of static object will actually make stk faster, since the lights will not be part of the octree for the track. Testing this is still on our todo list - e.g. comparing if you just put a link in the track for all lights, having them several times, and exporting them as separate objects. It probably don't make a noticeable performance difference - but if you have very many lights it might actually be slower.

Thanks for you answer. Exporting b3d models works now. I did a test with around 20 objects (each ~70 faces) exporting to one b3d file. The game actually ran faster compared to having all objects in the same b3d file. I didn't really test very accurate though.

About the textures: I did what you said in your first post. Complete alpha pixels are shown correctly, but semi-transparent pixels are still shown as non-transparent pixels.

I'm having some trouble with animating as well. I tried to animate a cogwheel (turning around the y-axis), so I added the following properties:

I used an IPO curve to animate the cogwheel, but nothing happened. The script doesn't export a b3d file, and the cogwheel isn't rotating, just standing still. Any ideas?

I believe alpha="Y" enables alpha testing, NOT alpha blending (yes, the name is a little confusing, but that's a bit because Joerg is not very expert on computer graphics I believe )
I think what you want is transparency="Y"

@Joerg: Now that's another thing we need to document! (the material.xml file)

Varivar {l Wrote}:Thanks for you answer. Exporting b3d models works now.

Great! Thanks for testing!

I did a test with around 20 objects (each ~70 faces) exporting to one b3d file. The game actually ran faster compared to having all objects in the same b3d file. I didn't really test very accurate though.

That's quite interesting and not really what I would expect. The oct tree should cull the unused objects more efficient than separate objects (basically separate objects means one more object to test for culling, so the amount of work increases linearly with number of objects, while in the oct tree it should add less work). I might ask a question about this in the irrlicht forum.
...

I'm having some trouble with animating as well. I tried to animate a cogwheel (turning around the y-axis), so I added the following properties:

properties.jpg

I used an IPO curve to animate the cogwheel, but nothing happened. The script doesn't export a b3d file, and the cogwheel isn't rotating, just standing still. Any ideas?

Yes - I forgot to remove some old part of the documentation (which I am fixing now). Set the type to 'object' (and leave interaction the way it is), that should be all (the IPO should then be automatically detected).

Cheers,
Joerg

Auria {l Wrote}:I believe alpha="Y" enables alpha testing, NOT alpha blending (yes, the name is a little confusing, but that's a bit because Joerg is not very expert on computer graphics I believe )

That's most certainly correct
...

@Joerg: Now that's another thing we need to document! (the material.xml file)

Yes, good point. And we have to make all materials.xml files consistent, too - there are many 'alpha="0.8" ' entries still around. Also someone should think about the best names to use - and that should certainly not be me E.g. perhaps instead of transparency use 'blending'? Suggestions?

Cheers,
Joerg

Maybe

alpha="blend"
or alpha="test"

or

alpha="Y"
or alphaTest="Y"

(/me is quite used to the wording "alpha testing", from OpenGL, but I believe irrLicht doesn't call it like that, so maybe collect a few more ideas first

Now, re-checking the code shows that transparency is for alpha testing (alpha>127 and a pixel is shown), while alpha='Y' should enable alpha blending - so it should have worked. Can you just post (or email to me) the blend file, textures and materials.xml then I'll have a look.

Cheers,
Joerg

Thanks for your help. I solved the alpha problem (alpha="Y" did the trick) and the animation problem, both work fine now. For some strange reason the export script swaps the y and z-axis of the object. Not a big deal, just a bit annoying. Some documentation about the materials file would be very useful indeed

I have a new problem (hopefully the last) I don't manage to export nitro containers. I use "type:nitro-small" for them, but they don't show up in the game. It adds references to the "scene.xml" file however.

And a question: will there be support for some sort of lightmapping in the future? The mines track could really benefit of this. I believe Irrlicht can handle this.

Hi Varivar,

check http://supertuxkart.sourceforge.net/Irrlicht, near the bottom there is a link to a new page documenting the material.xml format

About nitro, I'll let Hiker answer, since I don't know this part

About light maps : yes indeed, there are many eye-candy features we could use. I was also thinking of using splatting, and dedicated ground managers with LOD, to have less blocky ground without ending up with huge and slow meshes. But I guess this will not make it to the first 0.7 release since it'd be too much work for our current capacities - best release something first

Hi,

Varivar {l Wrote}:Thanks for your help. I solved the alpha problem (alpha="Y" did the trick)

Ha auria - so much for me not being an exprert in computer graphics (though I admit you are usually right ).

and the animation problem, both work fine now.

Good news. So far I have only done simple test cases - to know that a real example works as expected is really great - thanks!

For some strange reason the export script swaps the y and z-axis of the object. Not a big deal, just a bit annoying.

That's done on purpose. Unfortunately bullet and irrlicht use a different orientation for their coordinate system, so we have to switch axes. I would have to check the details, but it _should_ work out of the box, i.e. without the need to change anything in the created files. If that is not the case, then something is wrong
...

I have a new problem (hopefully the last) I don't manage to export nitro containers. I use "type:nitro-small" for them, but theydon't show up in the game. It adds references to the "scene.xml" file however.

Gee, indeed - the names in the track exporter (nitro-small) and in stk (small-nitro) do not match. I've fixed the exporter, r4503 in svn, or from wiki (refresh!).

And a question: will there be support for some sort of lightmapping in the future? The mines track could really benefit of this.I believe Irrlicht can handle this.

I had a quick look. irrlicht supports different materials for lightmapping, and I just quote their docu here:

{l Code}: {l Select All Code}

                //! Material type with standard lightmap technique
                /** There should be 2 textures: The first texture layer is a
                diffuse map, the second is a light map. Dynamic light is
                ignored. */
                EMT_LIGHTMAP,

                //! Material type with lightmap technique like EMT_LIGHTMAP.
                /** But lightmap and diffuse texture are added instead of modulated. */
                EMT_LIGHTMAP_ADD,

                //! Material type with standard lightmap technique
                /** There should be 2 textures: The first texture layer is a
                diffuse map, the second is a light map. Dynamic light is
                ignored. The texture colors are effectively multiplied by 2
                for brightening. Like known in DirectX as D3DTOP_MODULATE2X. */
                EMT_LIGHTMAP_M2,

                //! Material type with standard lightmap technique
                /** There should be 2 textures: The first texture layer is a
                diffuse map, the second is a light map. Dynamic light is
                ignored. The texture colors are effectively multiplyied by 4
                for brightening. Like known in DirectX as D3DTOP_MODULATE4X. */
                EMT_LIGHTMAP_M4,

                //! Like EMT_LIGHTMAP, but also supports dynamic lighting.
                EMT_LIGHTMAP_LIGHTING,

                //! Like EMT_LIGHTMAP_M2, but also supports dynamic lighting.
                EMT_LIGHTMAP_LIGHTING_M2,

                //! Like EMT_LIGHTMAP_4, but also supports dynamic lighting.
                EMT_LIGHTMAP_LIGHTING_M4,


Which one do you need (if possible the one offering the best performance of course ) - if you need to test several, let me know which ones. We have then to see if the b3d exporter exports two textures correctly, if they are loaded as expected, and then how to handle this in irrlicht (I'd guess that we need a new 'lightmap=Y' setting for materials.xml for the main texture). If you could create a test case including the lightmap, and send me/post here the .blend file with the textures, I can have a look at this.

Cheers,
Joerg

hiker {l Wrote}:

For some strange reason the export script swaps the y and z-axis of the object. Not a big deal, just a bit annoying.

That's done on purpose. Unfortunately bullet and irrlicht use a different orientation for their coordinate system, so we have to switch axes. I would have to check the details, but it _should_ work out of the box, i.e. without the need to change anything in the created files. If that is not the case, then something is wrong

I did some more tests and the swapping doesn't affect the animation, the in-game animations are the same as those in Blender.

I had a quick look. irrlicht supports different materials for lightmapping, and I just quote their docu here:
"*******
Which one do you need (if possible the one offering the best performance of course ) - if you need to test several, let me know which ones. We have then to see if the b3d exporter exports two textures correctly, if they are loaded as expected, and then how to handle this in irrlicht (I'd guess that we need a new 'lightmap=Y' setting for materials.xml for the main texture). If you could create a test case including the lightmap, and send me/post here the .blend file with the textures, I can have a look at this.

I'd go for the first one:

{l Code}: {l Select All Code}

 //! Material type with standard lightmap technique
                /** There should be 2 textures: The first texture layer is a
                diffuse map, the second is a light map. Dynamic light is
                ignored. */
                EMT_LIGHTMAP,

This is the most simple light mapping technique which has (I guess) the best performance. However, first I have to find out how I can generate a lichtmap in Blender (which is possible).

Btw, I think I will post a beta version (without light maps) of my track this evening. Work is nearly done

I've uploaded the track, have a look here. I upload the blend file here, place it in the same directory as the game files, as it needs the textures.

I tried to export my track, but the driveline seems mirrored (left-right reversed) with respect to the track.

Is that a known bug?

Thanks, answered on the other thread.

About AIs crashing into the walls : my guess is that the drivelines probably go to close to the walls and sides of the bridge. Maybe you could leave some space between the driveline and the wall? AIs assume that they can drive *on* the drivelines, so if they're close to a wall they will bump in it

Varivar {l Wrote}:I did some more tests and the swapping doesn't affect the animation, the in-game animations are the same as those in Blender.

OK, good!
...

I'd go for the first one:

{l Code}: {l Select All Code}

 //! Material type with standard lightmap technique
                /** There should be 2 textures: The first texture layer is a
                diffuse map, the second is a light map. Dynamic light is
                ignored. */
                EMT_LIGHTMAP,

This is the most simple light mapping technique which has (I guess) the best performance. However, first I have to find out how I can generate a lichtmap in Blender (which is possible).

OK - let me know when you are done.

Cheers,
Joerg

asciimonster {l Wrote}:I tried to export my track, but the driveline seems mirrored (left-right reversed) with respect to the track.

Is that a known bug?

No - is it really mirrored, or are just the axes 'wrong' - as mentioned elsewhere we have to swap the axes. And does it work in stk, or not at all? You can start stk with --track-debug, and it will show you the drivelines in the game (also you can check with the minimap, which is based on the drivelines).

Cheers,
Joerg

hiker {l Wrote}:No - is it really mirrored, or are just the axes 'wrong' - as mentioned elsewhere we have to swap the axes. And does it work in stk, or not at all?

I think the minimap in my screenshot will answer you question. The track is bigger on the plates and there is a second around the tap.
I can play the track, but the AI can't. Logically, laps are not counted and the game never ends.

This is a problem I know from the 0.6 version. There I always had to adapt the exported numbers according to:
(x,y,z) -> (x,-z,y)

asciimonster {l Wrote}:I think the minimap in my screenshot will answer you question. The track is bigger on the plates and there is a second around the tap.
I can play the track, but the AI can't. Logically, laps are not counted and the game never ends.

This is a problem I know from the 0.6 version. There I always had to adapt the exported numbers according to:
(x,y,z) -> (x,-z,y)

I remember having a similar issue with the mines track. Be sure to have the start and the ending of the driveline as close to (0,0,0) as possible, they shouldn't overlap each other. Can you upload the blend file?

I managed to generate a lightmap in Blender. It's a very simple lightmap, if it works, the first tunnel (with the moving cart) should appear green, and the other parts yellow. If this works I will make a real lightmap. The zip archive contains a lightmap (in png format) and the blend file with the lightmap applied to all faces. I hope you can use this.

Varivar {l Wrote}:I remember having a similar issue with the mines track. Be sure to have the start and the ending of the driveline as close to (0,0,0) as possible, they shouldn't overlap each other. Can you upload the blend file?

No, I had taken care of this and it is still going wrong. And yes of course I can upload the blend.

The problem is that the driveline is below z=0, which causes a mirrored driveline. Be sure to have all driveline vertices above z=0.

Even with the fixed driveline, the ai isn't able to play the track. I think you should improve it's drivability, the ai doesn't manage to cross the first shelves. I also think every vertex of the driveline should approximately be at the same level as the track (ofcourse above z=0).

Varivar {l Wrote}:The problem is that the driveline is below z=0, which causes a mirrored driveline. Be sure to have all driveline vertices above z=0.

That's quite weird, I think it's another bug for Hiker

Auria {l Wrote}:

Varivar {l Wrote}:The problem is that the driveline is below z=0, which causes a mirrored driveline. Be sure to have all driveline vertices above z=0.

That's quite weird, I think it's another bug for Hiker

I'll have a look at the mirroring problem and the lightmapping - not sure if I will have time before Wednesday though.

Cheers,
Joerg

Varivar {l Wrote}:The problem is that the driveline is below z=0, which causes a mirrored driveline. Be sure to have all driveline vertices above z=0.

Correct - I've fixed that in svn, but till we make another release I'd recommend to move everything up enough for the driveline to be positive.

Even with the fixed driveline, the ai isn't able to play the track. I think you should improve it's drivability, the ai doesn't manage to cross the first shelves. I also think every vertex of the driveline should approximately be at the same level as the track (ofcourse above z=0).

Not really sure what's causing this problem - once I have the track with textures (sorry, white on white makes it pretty difficult to drive) I can have a look.

Cheers,
Joerg