Transparency rendering in Irrlicht

[rudy85]

This is difference between irrlicht and plib :

Up :Plib
Down : Irrlicht
The same material :

So I've tried another value in alpha canal :

But the result stay the same

[Auria]

Hi,

I believe the B3D exporter ignores materials completely. The currently supported way of having transparent surfaces is to texture them with a PNG that includes an alpha channel

[rudy85]

ok , I will try

[rudy85]

Yes and we have to edit material.xml

{l Code}: {l Select All Code}

<?xml version="1.0"?>
<materials>
  <material name="Wire.png" alpha="Y" light="N" collide="Y"/>
</materials>

[rudy85]

What are you thinking to do to improve transparency : It seem that an item into a transparent box or sphere doesn't appear
It' s a real limit for conception to making glass door, fish in lake or in aquarium , wine in a drink

3 of my track could not be ported to irrlicht

[Auria]

This seems to be a bug in irrlicht, unfortunately we cannot fix it, the irrlicht developers will need to

[rudy85]

I've send a question in irrlicht forum

[rudy85]

Thanks Auria for supporting me

[acme_pjz]

This seems to be a bug in irrlicht, unfortunately we cannot fix it, the irrlicht developers will need to

I don't think so. When rendering something with transparency, you need MANUALLY determine render order (render far items first, then near items) because after rendering near items with transparency the Z-buffer is updated, then if you want to render far items behind the near items it will fail to pass Z-test ... So maybe you guys forgot to change render order (or forgot to set a flags that tells Irrlicht to re-order items) ...

[rudy85]

Could you be more explicit please ?

[acme_pjz]

Could you be more explicit please ?

Well, it's too technical ... but it's not artist's fault

===========================

[EDIT] These are explanations:
What is Z-buffer
http://en.wikipedia.org/wiki/Z-buffering
The Z buffer doesn't work for transparent polygons.
http://www.sjbaker.org/steve/omniv/alpha_sorting.html

[Auria]

I don't think so. When rendering something with transparency, you need MANUALLY determine render order (render far items first, then near items) because after rendering near items with transparency the Z-buffer is updated, then if you want to render far items behind the near items it will fail to pass Z-test ... So maybe you guys forgot to change render order (or forgot to set a flags that tells Irrlicht to re-order items) ...

No, 3D engines normally do that automatically for you; we wouldn't use a 3D engine if we needed to manually tell it everything to do ^^

[hiker]

Hi,

irrlicht sorts the scene nodes by transparency/non-transparency. So try to export the transparent meshes as a separate object (set the properties: type="object', name="some filename" interaction="static" in blender before running the track exporter), and see if this fixes the transparency.

Cheers,
Joerg

[hiker]

Hi,

I had a good look again, and I think I understand the issue now, and it might actually not be an irrlicht problem:

irrlicht sorts the scene nodes by transparency/non-transparency. So try to export the transparent meshes as a separate object (set the properties: type="object', name="some filename" interaction="static" in blender before running the track exporter), and see if this fixes the transparency.

That was actually not correct Irrlicht registers scene node to be rendered in the transparent and/or non-transparent pass. If a scene node (e.g. a kart) has both, it will be registered in both passes, and only render the appropriate meshes in each of the phases. So irrlicht should be able to handle a model like this correctly.




So I had a closer look at the adiumy model: the problem is that the window mesh is not actually set to be transparent in STK, and therefore it is rendered in the wrong pass. When I quickly hacked STK to set all meshes of adiumy to be transparent, you could indeed see through the glass to the driver So that's good news

Unfortunately stk only supports setting the material properties (like transparency) for textured meshes, so there is no easy way atm to fix this in stk. But the following should work: can you assign a simple transparent texture to the windscreen? Then you can set the appropriate value in the materials.xml file for that texture, making the window transparent, and then triggering the correct rendering order. Then adiumy should work as expected.

There might be some support in the b3d file format for that, but I don't think the exporter can handle this atm.

Could you test the approach with the transparent texture and let me know how you go?

Cheers,
Joerg

[rudy85]

It's ok for me !