Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[benitomuso]

Herra,
               I think that you are possitive regarding turbulence. The turbulence effect is calculated by the game in every rendered frame, so the left and the right eyes could have changed distortions introduced by different turbulence random numbers. A solution to this is to affect the view with turbulence and headshaking values once every two frames. In this way both eyes will see always the some "front image".

  Regarding convergence: in what mode was taken the picture you posted?

  I think that you are misunderstanding Left 45° / Right 0°. It means that your left sight will cross 45° inward. That's true, the blueish image (it is not the right eye, because of the color composition, in fact it is the left one) seem to be 45° outwards, but at the same time (having comparatively the eyes so close) 45° inward of the left eye would be indistinguishable from 45° outward of the red eye. You will always see a big angle like this as divergent (looking outward), because after crossing in front of your other eye, it sends your sight outside.

  Now I consider that a way of making more evident the sign of the angle is setting something like Left -30° / Right 0°. Then you yes have to see a divergent left eye (really divergent due to the -30) and the other eye (the right one) looking forward.

  Regards,
                     Pablo

[Herra Tohtori]

Herra,
               I think that you are possitive regarding turbulence. The turbulence effect is calculated by the game in every rendered frame, so the left and the right eyes could have changed distortions introduced by different turbulence random numbers. A solution to this is to affect the view with turbulence and headshaking values once every two frames. In this way both eyes will see always the some "front image".

That would work for that, I guess.

Regarding convergence: in what mode was taken the picture you posted?

View direction locked straight forward, Left 45 degrees, right 0 degrees convergence, as posted:

PAL3DConvLeft=45
PAL3DConvRight=0

I think that you are misunderstanding Left 45° / Right 0°. It means that your left sight will cross 45° inward.

Except with those settings, left view point (red) looks outward 45 degrees and right view point (cyan) is looking dead straight forward.

That's true, the blueish image (it is not the right eye, because of the color composition, in fact it is the left one) seem to be 45° outwards, but at the same time (having comparatively the eyes so close) 45° inward of the left eye would be indistinguishable from 45° outward of the red eye. You will always see a big angle like this as divergent (looking outward), because after crossing in front of your other eye, it sends your sight outside.

I don't understand. The blue-green (cyan) view is definitely the right eye view (note how it is displaced to the right of the centerline, you can see this from the reflection sights). In my glasses, right lens is cyan and left lens is red. I didn't change any colour filtering, and I took the screenshot in Mode A. All the other 3D modes behave exactly the same though.

In the screenshot I posted, the view is locked forward. Left eye convergence is set to 45, and it is tilted 45 degrees left (outward), as you can see by closing right eye and only looking through the red lens.

Now I consider that a way of making more evident the sign of the angle is setting something like Left -30° / Right 0°. Then you yes have to see a divergent left eye (really divergent due to the -30) and the other eye (the right one) looking forward.

Here is a screenshot of the same cockpit but with the following values:

PAL3DConvLeft=-30
PAL3DConvRight=0



Left eye (red) is now entirely predictably turned 30 degrees right (inward).



I'm not trying to be mean or anything, but this is how the mod behaves at the moment... ???

[kumpel]

Hi Pablo,

On a bit different subject.
I got myself a few pairs of colour glasses that use a number of slightly different filters, just to experiment with the effectiveness of the 3D rendering.
My small problem is that I have a wide colour gamut monitor, so the results may not be the same for a regular type LCD.
With the method that you use, colour plane manipulation, colours are equivalent to the RGB pixel spectra. These are not pure colours but extended spectra with dominant R, G or B bands. It is then difficult to obtain good separation of colours, and in effect a well observable crosstalk is always present.

I have tried three systems (1) R__/_GB, (2)_G_/R_B and (3)_GB/R_G* with a range of filters.

(1) gives reasonable results with week red colours and an overall skew of colour towards red,
     eye strain is noticable after a while; not very sensitive to slight variations of colour filters
(2) gives better colour rendering, however there is a strong eye bias towards magenta where
     light, whiteish areas tend to switch between their natural colour and magenta, something
     like the eye gets used to the proper rendering and then from time to time sees the image
     dominated by magenta; a bit more fussy about types of colour filters, more redish magenta
     filter works better
(3) this one gives the best colour rendering, and the least eye strain provided one can get
     the right combination of filters.

The above results reasonably agree with the generally published info. A couple of interesting articles can be found here:
http://cmst.curtin.edu.au/local/docs/pubs/2004-08.pdf
http://www.wseas.us/e-library/transactions/circuits/2010/89-191.pdf

Contrary to what you stated a few posts before, 3D rendering does not require complete separation of colours, the question remains whether you can find a way to make a reliable cyan/magenta function.

In conclusion, in my opinion, due to the always present colour crosstack, the main consideration needs to be given to the eye strain - rating (3)(1)(2), rather than a faithful colour rendering (although with often present red controls in cockpits this may be a point to consider).

Cheers, Kumpel

* This mode can be obtained from your Mode A by setting the right color planes, minus the first yellow image that can be put aside (literally) by engaging the 3D mode while looking at a wite background, like a cloud, and then turning the view away towards a 3D object.

[benitomuso]

Here is a screenshot of the same cockpit but with the following values:

PAL3DConvLeft=-30
PAL3DConvRight=0



Left eye (red) is now entirely predictably turned 30 degrees right (inward).



I'm not trying to be mean or anything, but this is how the mod behaves at the moment... ???

Herra,
                     what I meant is more evident in your last picture.

  Try to follow my explanation:

  -The Right = 0° is the frontal image you see, pointing ahead, the "most dense" of the two images. What I told you is particularly evident here, it can be confusing and you can assume that because the parts of the cockpit structure look "redish" you can figure out that it is the left (ref tinted) image. But not, if you see to the gunsight, this is in fact the cyan half image.
  -The Left = -30° convergence (-30° means 30° divergence) makes your left eye to diverge (go outwards) 30 degrees and it is exactly what the other half image does. Again, check the gunsight and the part of the right wing you see in the screen: they are redish, so they are the left image view port.

  As I said before, the metal structure of the cockpit is composed with the light blue sky and generates distracting color tones.

  To confirm what I say, you can do this:

PAL3DConvLeft=-30
PAL3DConvRight=0
PAL3DFilterLeft=RGB
PAL3DFilterRight=___

  Then you will only see a less brilliant image twisted 30° outwards, more to the left (divergent because the eyes don't cross in front of you) corresponding to the left eye. No right image (FilterRight = ___) will be seen. If instead of -30° (divergent) you set 30° (convergent) you will only see one left image twisted inwards (to the right), crossing the now hidden right viewport, so clearly convergent (in full accordance with the great graphic you made).

  Attached you can see an image of what I mean (the settings I showed you, no other change made).

  Regards,
                       Pablo
 

[Herra Tohtori]

I see, we are using different terminology here.


When I say the eye looks inward, I mean that it is physically turned toward your nose. That is exactly what happens there - the left eye's vector is turned 30 degrees right with convergence value of -30.

Whereas you are saying that the image is moved 30 degrees to opposite direction. This is correct, but it is also rather confusing, as is evident by this conversation. It is also the opposite of the instructions in this image:




Currently, negative angles converge the eye directions, the vector in which the respective eye is pointed.. Positive angles diverge the eyes.

This has, of course, the opposite effect on the direction to which the images "slide" on top of each other. This works just as well, but we just need to get the terminology straight for the instructions for the users. Personally, I would say it is more intuitive for users to adjust the angles in which each eye is pointed; in this sense, positive angle should turn the eye inward, and this also pushes objects further as the rendered images diverge from each other.

This would mean that positive values of convergence increase the distance of the objects in game, while negative convergence values reduce the perceived object distance. This is, in my opinion, a more intuitive relation of what happens in the mechanics, and what the viewer sees.


It's your call ultimately, but from tester perspective I would say making the mod behave as described in that instruction image would be probably the most intuitive way for users to control the perceived object distance with the convergence controls.

[benitomuso]

Herra,
                a simple graphic (not drawn by me). Look at any definition of convergence / divergence and everything will show you or explain you the same:

  In mathematics any function convergent means that gets closer to a value (inward). A divergent means that aparts from a value (outward). I don't think that my convention is confusing. I see it very consistent. Again: the values we are adjusting are convergence, so a negative must be the first case of the graphic I posted here. It is consistent with your graphic too. A positive will twist your eyes inwards (second case of my pic) and absolutely consistent with your graphic, what you see in game in the pictures me and you posted, etc.

  Obviously the linear angle convergence (because they are rect lines) when you set a convergence, finally will produce a cross of the two lines (that could be very close) and then they will start to diverge. But you cannot consider what happens after crossing, because at the beginning you established a convergence. If not they wouldn't have ever crossed. I think that a great example (very similar to the +10 deg / +10 deg in the MOD) is this one:

  You can say: I see two tracks which are diverging. And that's true only if you consider the situation in the long distance, but in fact they were convergent tracks because they have crossed each one very close to the point of view. As I said before, later they will diverge, but you should consider them convergent (because if not you would not have any crossing).

  EDIT: what I really don't know because I don't have neither the theory learnt nor the experience is which of the cases the objects should be pushed forwards or backwards, but the rest (the therminology, eye assignment and angle convention is consistent with physics, mathematics and semantics).

  Regards,
                        Pablo

[Herra Tohtori]

Well, here is how I think of it.

Here's a simple scene where there are two eyes, lines that go along the ground parallel to each other at the same distance as the eye separation, and "cross" at infinite distance at horizon (perspective lines, in other words). Above the imaginary convergence point, also at optical infinity, is a single cloud.



Now if we make an anaglyph stereo picture of the scene, it basically looks like this:



Note as you look at the image, the cloud and infinity point are exactly at the same distance as the display apparatus. If you put your finger next to the cloud, it will seem to be at the same distance.


Now, let's apply some angles to the eye points.

Here, the view points are turned outward, so that left eye looks slightly to the left, and right eye slightly to the right. This corresponds currently to positive convergence values in the mod.



Note that as the view angles diverge, the images themselves actually converge:



If you now look at the cloud, it will appear to "pop-up" from the display. It will be somewhere between the display and your eyes, and if you try to put your finger on it, you'll find an untoucheable "hologram" hovering mid-air and your finger will phase through it.

Now let's do the other way round. Here, both view points are angled inward; left eye looks over the centerline to the right, and right eye correspondingly to the left. This, currently, corresponds to negative convergence values in the mod.



Now the result is that even though the view directions from the eyes themselves have a convergent angle, the images that the eyes see will actually diverge. This means objects will appear to be at a longer distance:



Now, if you try to "touch" the cloud, you will find that your finger will hit the display apparatus before reaching the distance at which the cloud is perceived to be.


What am I trying to say here? Well, just that the convergence or divergence of images actually causes the opposite effect than what would be intuitive for most people: Currently when you decrease convergence, object distance increases, and vice versa.

Thus, I recommend that the convergence values affect the angles to which the eyes point, rather than the phase angle shift of the images relative to zero-convergence angle. If not so, then the signs should be inverted in the readme picture to expressly state that negative convergence values push objects further, while positive values bring them closer to you.

I'm not trying to say you should do things this or that way, but the instructions need to match what is actually in the mod, right?


(note the images are hand-drawn, and the "railroad" effect from the two lines doesn't really work very well, but the cloud itself should make things abundantly clear...)

[Herra Tohtori]

Moving along, here is how the turbulence looks like on my PC. I don't think it's merely the eye difference (although that needs to be addressed as well); it's more like there is some extra zeroes in some multiplier somewhere in the code that magnifies the small viewpoint movements compared to what the regular 6DOF does.

You said the code is supposed to be the same as far as turbulence is concerned? Well, clearly something somewhere is different since on regular 6DOF, this definitely doesn't happen...


http://www.youtube.com/watch?v=9xi_njtlqqQ

[santobr]

Yes, the same thing occurs with me, but I forgot to report it.

[benitomuso]

People,
                    I was quite busy lately.

  OK, I will review the part of the code related to turbulence, but I'm positive that I haven't introduced anything different. Perhaps, now I'm figuring that, when the shift of viewpoint is calculated and specially now with the angle of convergence, there is a transofrm, that if it includes an angular headhsake effect (which produces an angle distortion), it will magnify the effect of the convergence / separation pair to a big extent. But again: this can be completely compensated by making the head shifts only once every two frames.

  Herra: regarding the Convergence topic, and so we (you and me) can converge to some common concept: as far as I know you understand convergence as convergence of images (to make them close to match objects in different views one to the other) and I agree with you that it is not necessarely the same that eye convergence (that's what the angles of the MOD express, how the eyes are oriented). For images convergence some abstract units should be used, for eyes convergence, it is easy, real angular measure of the twist is used, and that was my approach. So again: it's a convention, and I always referred it as "eyes convergence" so it's the twist of the eyes inwards respect of the parallel view.

  Kumpel: sorry that I couldn't answer before. When you say this mode: (3)_GB/R_G* I assume you made a mistake and you are referring to Cyan / Yellow (_GB / RG_), correct? Because R_G will be evaluated by my MOD as R__

  If you share some color (in this case the Green G) you will have a blurry effect in that color, because the half image of the left eye will have a Green component and the half image of the red eye will have a different one, and they will be "mixed". In particular, if it's the green that mostly is seen in far backgrounds (landscape) it will not be perceived as a problem because that blurr will be minimal, but for closer green objects (let's say the cockpit of the B-17) you will have lack of stereo precision, because a channel is being taken from two different images.

  There is another approach to color filters, that mainly could create more "your conditions" rendering (compensating your monitor / glasses characteristics), and it is using a mesh filter like the one we are accustomed to see in the redouts or blackouts of the game. The tint of those filters could be adjusted to be really neutral for each eye, and so creating an image almost free of residual components. The cons are:

  -It would be tremendously hard to calibrate to really generate pure color channels.
  -It would suffer with monitor brightness / contrast or any other adjustment.
  -It would have an impact on fps rate (probably significant).

  So potentially it's perfect but if you consider these 3 last points: it is a big problem.

  Regards,
                      Pablo

[Herra Tohtori]

People,
                    I was quite busy lately.

  OK, I will review the part of the code related to turbulence, but I'm positive that I haven't introduced anything different. Perhaps, now I'm figuring that, when the shift of viewpoint is calculated and specially now with the angle of convergence, there is a transofrm, that if it includes an angular headhsake effect (which produces an angle distortion), it will magnify the effect of the convergence / separation pair to a big extent. But again: this can be completely compensated by making the head shifts only once every two frames.

Except if you watch the video, you'll see it does the exact same thing when stereo mode is disabled.

I would recommend checking the code regarding turbulence is actually identical - maybe there has been some accidental change (such as a multiplier of 1 becoming a multiplier of 10 or 100 by accidental presses of zero, or something like that). I'm asking this because I tried to manually change the turbulence multiplier while flying with regular 6DOF; it only went up to 9, but I could already see that the behaviour of the image went a lot closer to what I'm seeing with stereo mod.

Call it an intuition but I think the turbulence multiplier is somehow locked to a far higher variable than it should be.

There are filecompare utilities that should be able to colour differences in the code for you. If the code itself is the same, then I would check that the variables that are fed into that bit of code remain the same (although that seems more far-fetched).

Meanwhile, I will perform a test to see whether setting Separation to zero helps, or if setting Convergence to zero helps. If the problem exists even with those values at zero, then I suspect it's not related to them as such; I already suspect it's unrelated since the problem occurs even with stereo mode disabled, but I shall test it regardless.


EDIT:

Test done. Behaviour same even when separation and convergence are manually set to zero.

I also did a test to integrate the "PureTrackIR6DOF-3DAdapted" from v5 into v6RC, to see if the anomalous turbulent behaviour was caused by the 6DOF part of the mod. However, same magnified shaking occurred.

It appears that the view direction is not really a problem, but horizontal and vertical location of the viewpoint is. The movements are magnified to a very large extent by something somewhere in the code. I tried manually adjusting the Turbulence modifier via 6DOF controls, but I didn't see any increase (or decrease) in the amount of movements that the viewpoint was doing within the cockpit.


EDIT 2:[/b]

The behaviour seems to be triggered by the parametre

PAL3D6DOF=0

If I set that to PAL3D6DOF=1, then the excessive turbulence shaking does not occur. But, on the other hand, I do not gain six degrees of freedom from head tracking; I only get pitch and roll.

  Herra: regarding the Convergence topic, and so we (you and me) can converge to some common concept: as far as I know you understand convergence as convergence of images (to make them close to match objects in different views one to the other) and I agree with you that it is not necessarely the same that eye convergence (that's what the angles of the MOD express, how the eyes are oriented). For images convergence some abstract units should be used, for eyes convergence, it is easy, real angular measure of the twist is used, and that was my approach. So again: it's a convention, and I always referred it as "eyes convergence" so it's the twist of the eyes inwards respect of the parallel view.

Well, convergence of images is the opposite of convergence of eyes themselves. That said, if you refer to it as eye convergence, then positive convergence values should converge the eyes and diverge the images, yes?

Currently positive convergence causes the opposite; it diverges the eyes and thus converges the images.

As long as we are clear about what we tell people about it, I don't have a problem with any notation, but then this image that I initially made has the correct notation:




This image explains the effect of convergence variables regarding eye directions correctly according to the current convention of the mod, and also links it correctly to the increasing or decreasing of perceived distance. (though it still describes eye separation in arbitrary units instead of centimetres)

If you wish me to make another graph that shows the effect regarding movement of images relative to each other instead, I can probably do that too. I'll just have to think of how to do it so that it makes sense to people when they watch it. The advantage in showing the direction of eyes is that people easily understand exactly what it means.

[kumpel]

Pablo,

Thanks for responding to my post.
I did mean _GB/R_G (cyan/magenta). My mistake was that it is handled by your mode B rather than A as I have written incorrectly (my apologies).

Our 3D vision is a complex system where the stereoscopic image from the eyes has only about 20% contribution, the rest relies on a range of cues that our brain is using in processing for the final effect. Cyan/magenta system, despite both eyes seeing different blue images, does not create any blur. It simply helps to balance the colours and to remove magenta bias.
Unfortunately, as I have discovered so many times dealing with the use of our vision in astronomy, only experiments give ultimate answers.

Cheers, Kumpel

P.S. I wonder whether you might be able to clear this one fixed initial yellow frame in mode B with _GB/R_G setting?