[SOLVED] Clearing problem in Red/Cyan Anaglyph Stereo?

[Guillaum]

@CuteAlien: When testing other versions of the engine, from DEB, SVN, ZIP / 1.9, 1.8.1, 1.7.3, 1.6.1 ; there's no face to face point of comparison. But for 1.8.3, downloaded from [url=svn://svn.code.sf.net/p/irrlicht/code/trunk@5136]SVN[/url] (r5136) and downloaded from ZIP, i did exaclty the same steps of compilation (make) and installation (cp to /usr/local/), and compilation of the same app (g++ command line with -L and -I to /usr/local/). And the results are not the same:


I know that maybe there's no apparent reason, and maybe it is difficult to conceive. An error from me is always possible, but be confident i'm not a newbie, i program daily for 17 years and for 12 years under Linux. Be confident i'm quite sure of what i say and of what i did. Maybe it could be a good information if someone can take some time to reproduce this test (even under Windows)? I know that mongoose7 had, even if the versions of the engine were not the same, like me different results with this stereoscopic code when compiling under Windows with engine coming from svn trunk (no problem happens) and engine coming from zip archive (the problem happens).

Thanks,
Guillaume

[CuteAlien]

Yeah, I'll put it on my todo, thought as usual I'm stuck with some bugs as well. I didn't mean to say your bug-report is wrong. Just saying that in such a crazy situation where you basically compile the same code twice (as there should be no difference between zip and svn) it's sometimes not the code but the path it's run in that is causing the problem. The example I gave was just one of the cases I've run into that, there had been more actually (other cases were about soft-link/hard-link troubles). Can certainly be something else here - just couldn't think of anything else yet :-)

[Guillaum]

Great, thank you. I think like you, an include path or something like that, but i don't know how are released the archives. Could just be good if someone can try to reproduce, because i don't see.

I'm ok with this, because i can continue to work with the 1.9 compiled from SVN. But would be better to understand (if something is wrong!) what happen in official ZIP and DEB releases.

Thanks a lot for your work in Irrlicht (which is great!) and hope these remarks will help the project (and not make you loose your time).

[mongoose7]

@hendu: During all my code experiments, i already tried to restore the mask with ECP_ALL before clearing the depth Buffer (after the left eye drawing, and before the right eye drawing), but it was not changing anything.

You're doing it wrong! You have to reset the mask after drawing both eyes! (The mask must be reset before the beginScene call.)

BTW I was using 1.8.1.
BTW The SVN version of 1.8.3 is probably 1.8.4 before it is released.

Edit: I just looked at the code and you do reset the colour mask after rendering. So there is something else going on. Probably the mask is copied on render and, if there is no render, it is not copied. So it does look like a bug in Irrlicht.
(It probably worked in 1.7 but optimisations in 1.8 caused it to fail. It now works again in 1.8.4 and 1.9.)

[Guillaum]

BTW The SVN version of 1.8.3 is probably 1.8.4 before it is released.

The only modification, on the publication day of 1.8.3, was r5136 with the file "changes.txt", so i thought r5136 was the last of 1.8.3.

You have to reset the mask after drawing both eyes! (The mask must be reset before the beginScene call.)

I think i've tried all possible permutations about where to put these masks ! Just retried now with 1.8.3 from ZIP, by reseting ECP_ALL before beginScene() but i confirm it doesn't erase the problem.

[Guillaum]

(It probably worked in 1.7 but optimisations in 1.8 caused it to fail. It now works again in 1.8.4 and 1.9.)

No, i repeat i tested with ZIP archives of 1.7.3 (20.02.2012) and 1.6.1 (13.01.2010), and the problem was also happening.

[Guillaum]

Ah ah ! I've continued investigations (and put my nose in Makefile files to observe include paths) and i have some more news. Finally, i was not downloading the good versions with my SVN command.

I then downloaded roughly r5136 like this:
wget "http://sourceforge.net/code-snapshots/s ... leases.zip"
and obtained a Makefile for 1.8 begining with:

Code: Select all

VERSION_MAJOR = 1
VERSION_MINOR = 8
VERSION_RELEASE = 3

Then compile and install Irrlicht, compile my app, and the bug appears!

With my previous SVN command, even if precising @5136, i was getting 1.9! Sorry, because i'm not used to navigate in SVN branches and things like this.

Finally, I think we can confirm it was a bug in 1.8.x branch, which seems to have disappeared in 1.9. Quite good news then!

[CuteAlien]

OK, that makes a lot more sense :-)

[Guillaum]

Yep, everything is ordered now, can put to [SOLVED] !

Thanks to all of you

[CuteAlien]

OK :-) Thought it still would be nice to know exactly what it was in case we should backport it to 1.8 (probably not as it's likely to change existing apps which is generally not a good idea in point releases).

[Vectrotek]

Nice work guys! Shows you what teamwork can do!