Irrlicht Engine

Hey there!
I had just downloaded v1.3 and wanted to check it out
But in the PerPixelLightning example I came across with some bugs, which i haven't got in v1.2.
I used OpenGL. Unfortunately I can't check out if it works with DX because of my directX driver that has got some strange bugs

http://www.kram-hochladen.de/download.php?id=NTIxMjA=

This video shows the bugs:
- Lightning (strange flickering)
- Particles (watch the "fireball")

Maybe it's just my computer -.- but in v1.2 everything is great
Hope it's nothing disastrous

Cya

Some light flicker was already reported by bitplane, but we could not track it down, yet. Since it was not really a major bug we decided to release 1.3 with this bug.
I could not watch the video (probably wrong codec) so I cannot say anything about the particles.

Here's SS of the particle bug from his video -

Hi,

I have this Bug too on a Mac. - also using OpenGL -

Here is a list of the other example tests:
Quake3Map: some white stairs and walls (mentioned before in the svn bug thread)
Custumscenenode: OK
Movement: some clipping errors
Userinterface: OK
2DGraphics:OK
Collision:models stays white
SpecialFX:clipping errors
Meshviewer:OK
Shaders:OK - but high level shaders does not work
PerpixelLightning: clipping errors
Terrainrendering:OK
RenderTotexture: cant see the model - only a blue cube with something that looks like the model on its texture
Demo: no irrklang

I could also work on svn if you need someone to do testing. But first Opengl should work on windows.
mamba

I could also reproduce the billboard transparency bug, I just did not recognize it before as it is view angle dependent.
Which kind of clipping errors do you get?
The texture problems could also be clipping problems, or render state bugs. These are more difficult to track as they don't show up under Windows or Linux.

Hi,
I just start with this engine. I can also try it on Win and linux on the same computer with openGL. But I need to be back home.
mamba

On windows I have also this pixel lightening bug. But all other examples are fine.
mamba

now this might be the fault of zbuffer test . Apparently some texture is droven over the particles, it seem somewhere some comparing testing against z buffer messes up because of not considering the clippings of far plane and near plane, that is beacouse z buffer is a 16BIT surrface mostly on all cards. so it stores range of 1000.0f to 0.f or range od 1.0f to 0.f...
To avoid this all , you never test A VALUE against z buffer, you can test ONLY a value in a zbufffer to a value in a zbuffer (some previous one).
<b>rendering a particle vertex<b>
Transform 'particle point'
...Lock Z Buffer
...Get Z buffer value from transformed particle point's x,y
...Unlock the Z buffer
...Render the particle center as a completely transparent vertex
...Lock Z Buffer
...Get the Z buffer value from the transformed particle point's x,y
(...Unlock the Z buffer)
...If the rendered point is DIFFERENT FROM the previous value, THEN D3D or OGL HAS NOT FOUND A PIXEL BETWEEN THE PARTICLE AND THE VIEWER, AND YOU render the PARTICLE ( DON'T FORGET TO RESTORE OLD Z-VALUE ); IF THE Z-VALUE IS NOT ALTERED BY NEW VALUE, THERE IS SOMETHING BEFORE THE PARTICLE, STOP HERE.

I can confirm, I have exactly the save behaviour on my linux box. The driver is ATI.