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:
- 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.
<material name="XXX.png" alpha="Y"/>
Varivar {l Wrote}: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.
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?
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 )
@Joerg: Now that's another thing we need to document! (the material.xml file)
Varivar {l Wrote}: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.
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.
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.
//! 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,
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 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.
//! 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,
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.
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).
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?
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?
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)
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?
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.
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
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.
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).
Users browsing this forum: No registered users and 1 guest