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

[Vectrotek]

Glad you like coding as much as I do! Keep up the good work!

[mongoose7]

Your code works for me (Windows).

[Guillaum]

Ok, thanks mongoose7 ! Good to know. So camera positionning, masks, order of steps, etc. must be ok !!

It is not really my code, but more the one proposed in 2009 by Luke, with small modification to update absolute position:
http://irrlicht.sourceforge.net/forum/v ... =9&t=33463

Also, it could help if you answer some questions about you configuration:
* are you using Irrlicht 1.8?
* sure, you didn't compile with DeviceType = EIDT_X11, but did you compile with DriverType = video::EDT_OPENGL?
* what graphic card are you using? with laptop or desktop?

I will try a Linux desktop PC next week (different hardware, without NVIDIA OPTIMUS, but same software configuration), and tell about the results.

[mongoose7]

I used an old trunk version (4978). Trying it with 1.8.1, I get smearing of the blue. Is this your problem?
Yes, OpenGL.
Desktop, Nvidia GTX 660 Ti.

1.8.1:

[Guillaum]

Oh! Yes, it is the problem i encounter and which i try to solve for so many hours (days)!

I'm also using Irrlicht 1.8.1 (under Linux Debian Jessie 8.2 stable).

Would then be a bug from 1.8.1? Or as mentionned by Vectrotek, some methods should not be used anymore:

One serious implication of this is that the old "FPS" method of camera control under Irrlicht can
no longer be used!

[Guillaum]

I've just been downloading, compiling and installing Irrlicht 1.8.3, and then compiling and testing my program. The problem still continues to happen.

[Guillaum]

I have continued to install other versions of Irrlicht under Linux (by downloading the zip, compiling and installing the lib).
* Irrlicht 1.8.3 (from zip, 13.9.2015) => same problem happens
* Irrlicht 1.8.1 (from deb packages, 17.11.2013) => same problem happens
* Irrlicht 1.7.3 (from zip, 20.02.2012) => same problem happens
* Irrlicht 1.6.1 (from zip, 13.01.2010) => same problem happens
* Irrlicht 1.5.2 (from zip, 16.12.2009) => too many compiling errors (lot of things seam to have change since)

For mongoose7, under Windows, the problem doesn't happen with install from trunk 4978 (from 20.10.2014), but happens when using version 1.8.1.

I don't know what to think?!

[Guillaum]

Some update, because i can't stop until code works !

I've downloaded Irrlicht 1.9 master trunk of today (29.11.2015) from:
https://github.com/zaki/irrlicht
then compile it and install it. Then compile my program under Linux... and you know what ? It works ! the problem do not appear anymore.

What's wrong with official ZIP of DEB archives ? Seems that only versions from trunk work?

The problem happens with ZIP 1.8.3 under Windows for mongoose7
and with DEB 1.8.1 or ZIP 1.6.1, 1.7.3, 1.8.3 under Linux for me.

But it doesn't happen with trunk 4978 under Windows for mongoose7
and with current trunk of 1.9 under Linux for me.

[Guillaum]

Here is the result with Irrlicht 1.9 installed from master trunk (29.11.2015):



http://www.guillaumeriviere.name/irr/videos/vid5.avi

[mongoose7]

1.8 has a number of problems that won't get fixed. Best to use the trunk version. The official version is at http://sourceforge.net/p/irrlicht/code/HEAD/tree/trunk/.

[CuteAlien]

@mongoose7: That depends on the problems. If it's bugs then they might still get fixed in 1.8. Sometimes we simply got lazy and fixed something in trunk which could/should be backported. We can't break the interface there, but if you know a specific problem maybe we can something. There's a good chance there will be a 1.8.4 release due the recent copy/paste fix for Linux, I just have to find some weekend for that, so adding more fixes in there would be fine.

[mongoose7]

Well, there is this problem, which seems to be due to maintaining the mask while clearing the framebuffer (so the cyan is not removed). There is also the change made for transparency by Nadro some time ago now, I guess.

[hendu]

I recall having the same problem and discussing it with hybrid. He thought it's the app's responsibility to restore the mask.

[Guillaum]

@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.

Also, i've done one more experiment on the ways to install Irrlicht.

If i download Irrlicht 1.8.3 from SVN (revision 5136 of 13.9.2015):
svn checkout svn://svn.code.sf.net/p/irrlicht/code/trunk@5136 irrlicht-1.8.3-svn
then my program works correctly.



But, if dowloaded from the official ZIP archive:
wget http://downloads.sourceforge.net/irrlic ... -1.8.3.zip
then the problem appears.


So, even if compiling and installing the same 1.8.3 version of Irrlicht, it is the way to get it (official ZIP or SVN trunk) that make things work or not.

Assessment:
* The problem happens:
=> for me when installing from DEB package of 1.8.1 under Linux
=> for me when installing from official ZIP of 1.8.3 / 1.7.3 / 1.6.1 under Linux
=> for mongoose7 when installing from ZIP archive 1.8.3 under Windows
* The problem doesn't happen:
=> for mongoose7 when installing from old trunk revision 4978 (from 20.10.2014) under Windows
=> for me when installing from current 1.9 trunk (of 29.11.2015) and from previous 1.8.3 trunk (r5136 of 13.9.2015) under Linux

So the problem seems to appear only when using official ZIP archives or DEB packages.

Hope it will help to understand when the problem appears. Also, great thanks to Vectrotek who helped to put on the track and support to continue investigations! And thanks all for your replies and interest. But at this moment, i don't know the engine deep enough to see where the problem comes from.

[CuteAlien]

OK, there is no obvious reason. So... crazy idea - but maybe it depends not on the versions but on the pathnames you have installed your app or Irrlicht. Maybe one of your media-files is having trouble with a certain part of the path? I had run into something like that once when I did some checks on part of a filename and forgot to exclude the folder-part of the filename (which caused it to assume a certain file was present whenever it was installed below a folder-name containing that part I was looking for).