Print

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

[santobr]

Yes!!!


I have one doubt...
How can I adjust the colors to better match the colors of the glasses?



santobr.

[Herra Tohtori]

Here's a simpler image, did I get the signs of the variables right?

[Herra Tohtori]

Ok, I discovered a bit of a problem here.




Basically, the convergence option works excellently - as long as the viewpoints are horizontally aligned. When they have a bank angle, the convergence is still relative to horizon rather than the view direction, and that means that left and right image appear vertically stacked on the screen. This makes it very difficult - almost impossible - to align the images. The difference between vertical distance of the images is increased with high convergence values, naturally.

What is needed here is some way to make sure the convergence always works relative to the viewing plane (determined by the two eyes), not relative to the game world horizon... Basically, some sort of vector transformation will be required to keep things synched.

This may be easier said than done. ???


(yeah the convergence is inverted on the last two pairs compared to the first one, but I was kind of in a rush to make that picture, and I think the problem should be clear from it anyway.)

EDIT:

I think, what is required, is to look at the roll value of the view point in-game (probably combined with the roll modifier from TrackIR data), and apply that bank angle value to the converged left and right view vectors. Technically, I think that should keep them tilted always in the viewing plane, but I don't know if the game offers the bank angle to be freely read by mods. I dearly hope so, though.

For example, if the game's own view vector has a roll value of let's say 80 degrees (tilted to the left), but TrackIR data modifies that by -40 degrees, the combined bank angle of the view point is +40 degrees from level, and the view vectors of each eye need to have that same roll value.

I am, of course, assuming here that IL-2 vectors are handled in a somewhat sane pitch/yaw/bank value scheme...

[benitomuso]

Here's a simpler image, did I get the signs of the variables right?

I love this picture. Thank you, this is exactly what I had asked to you.

I think that you are right about that the angle is in "plain observer shift" and not affected by the roll and pitch. Eventhough I thought the method will solve it, it is not working properly.

I still have some doubts with the sign of convergence. Called this way (Convergence) the positive values should be in the inner side (could you change your picture?). Perhaps it is inverted in my code. I still couldn't confirm that but assigning Left=45.0 and Right=-45.0 if the sign is correct, we should be looking in a fixed position at 1:30 hours. If we look at 10:30 hours the sign is inverted as you show in your picture, but I should adapt it in code.

Regards,
                    Pablo

[benitomuso]

Ok,
                 I got it.

  I have confirmed that: the Convergence angle was mistakenly inverted. Now it works as it should: positive values are towards the inner zone.

  I have fixed the angle that now is not always parallel to the hoizon, now it travels with the viewer wherever he goes.

  Herra, if you can change the graphic to display +x.x Convergence to the inner zone and -x.x to the outer zone it would be perfect.

  Once you asked me about the units of Separation. Those are centimeters of interocular distance for a viewer in the scale of the image of the game. It means: if you had a 1:1 real size monitor able to reproduce the cockpit in full scale, you would use 6.5(Reality cm) as the real distance between eyes. I.e. for monitors where you see objects in scale 1:4 the value to use would be 1.625(Monitor cm).

  The basic equation should be Separation = EyeDistance[cm] x MonitorScale

  But in fact this even depends on FOV, so this is the reason why is so difficult to express it in a reasonable unit.

  Regarding Convergence, I think that it will be great to adjust it depending on the FOV. It will generate the best balanced and less effort demanding view in any condition.

  Regards,
                        Pablo

[Herra Tohtori]

Here's a sign adjusted image. I'll test the updated version and report back shortly.

[benitomuso]

Thank you Herra!!!

    That's just perfect. I think that it makes much more clear what means each thing.

  Shardana, first of all, I would start in your case by doing this:

  -Let's say I have my left eye as the "strong one", the one which dominates the vision. If your case is opposite you have to invert whatever I say.
  -Establish in Conf.ini [MODS] section: PAL3DConvLeft=0.0
  -If you know what's the angle (I know that that it isn't constant) but more or less the angle of deviation of your "weak eye", establish in Conf.ini: PAL3DConvRight=WeakEyeAngle (if you have Convergent estrabism, I think that the other type is very uncommon, but in that case the value should be negative). If you don't know the angle, you should estimate that, better by using something long to align with your weak eye and later measure the angle of the aligned object to the front.

  Probably you will need to try a couple of values. I think that it would not be perfect, because your brain is accustomed to manage the situation of having crossed vission, but it should help.

  Then, when some good angle value is determined, you can start to adjust typical Convergence in game as explained before, and later you have to set in your Conf.ini the best values you obtained for you in game. Now this would be real convergence effect (pre compensated by the differential angle between your eyes).

  Regards,
                          Pablo

[Herra Tohtori]

Ok, good news and not very bad news.

The good news is, everything works perfectly as far as convergence is concerned. Images no longer move up or down relative to each other, so that is good.

On the other hand, convergence angles still seem to be inverted, as in negative values result in greater depth, whereas positive angles result in everything coming closer to the viewer. This seems just a sign error, so if you just slap a (-) on both values at one point, it should correct itself... This is not a big issue, it is basically just fine tuning the interface. Functionally, everything seems absolutely fine.

I am getting extremely good results with the following values:

PAL3DSeparation=6.5
PAL3DSeparationExt=6.5
PAL3DConvLeft=-2.0
PAL3DConvRight=-2.0


With these values, I get good depth at the full 90-30 degrees field of view range (while we're waiting for that to get dynamic).

https://www.sas1946.rocks/images/imageshit/dead/dead.gif
https://www.sas1946.rocks/images/imageshit/dead/dead.gif
https://www.sas1946.rocks/images/imageshit/dead/dead.gif
https://www.sas1946.rocks/images/imageshit/dead/dead.gif
https://www.sas1946.rocks/images/imageshit/dead/dead.gif
https://www.sas1946.rocks/images/imageshit/dead/dead.gif
https://www.sas1946.rocks/images/imageshit/dead/dead.gif
https://www.sas1946.rocks/images/imageshit/dead/dead.gif
https://www.sas1946.rocks/images/imageshit/dead/dead.gif
https://www.sas1946.rocks/images/imageshit/dead/dead.gif

[shardana]

It will take me some time to work this out but all Ii want to tell you is that you proved to be a friend....... I'm moved by your dedication towards my personal, although not exclusive to me, problem.

Grazie davvero e tanti auguri di buon natale!

[benitomuso]

Ok, good news and not very bad news.

The good news is, everything works perfectly as far as convergence is concerned. Images no longer move up or down relative to each other, so that is good.

On the other hand, convergence angles still seem to be inverted, as in negative values result in greater depth, whereas positive angles result in everything coming closer to the viewer. This seems just a sign error, so if you just slap a (-) on both values at one point, it should correct itself... This is not a big issue, it is basically just fine tuning the interface. Functionally, everything seems absolutely fine.

I am getting extremely good results with the following values:

PAL3DSeparation=6.5
PAL3DSeparationExt=6.5
PAL3DConvLeft=-2.0
PAL3DConvRight=-2.0


With these values, I get good depth at the full 90-30 degrees field of view range (while we're waiting for that to get dynamic).

Good!
              But just test this to confirm my deduction. Set PAL3DConvLeft=30.0 (it means one oclock for the left eye, 30 degress to the right) and PAL3DConvRight=-30.0 (it means one oclock too for the right eye, because positive 30 degress convergence for the right eye would mean 11 oclock). Now run the game, and you will be seen with your two eyes to the 1 oclock. what does it mean? The correct value is the left one because it is pointing in the appropriate direction (30 deg internal).

  My deduction is in some way independent of what it should produce if getting closer or not the objects. Positive Convergence would mean having your eyes more crossed and Negative Convergence (divergence) would mean having them pointing to the outside. Am I right with this? I think so.

  In the other hand: do you use the same value for internal and for external separation? I saw that adjusting convergence external Stereo perception is enriched, and particularly everything goes far from the screen plane (where the HUD messages are printed).

  Regards,
                            Pablo

It will take me some time to work this out but all Ii want to tell you is that you proved to be a friend....... I'm moved by your dedication towards my personal, although not exclusive to me, problem.

Grazie davvero e tanti auguri di buon natale!

Non c'e niente.

   Anche per te, auguri di buon natale. E dopo fami sapere si quello lavora come io credo.

[Herra Tohtori]

Well, I guess it all depends on what we're trying to say... regarding the direction of convergent angles.

Basically, when the view vectors are turned inward, it has an effect of separating the actual rendered images from each other, which means viewer will look at them more parallel and thus the perceived distance of objects in the game increases.

Conversely, when view vectors turn outward, it means the rendered images slide closer toward each other, and viewer needs to cross their eyes more - which reduces the perceived distance of the objects.

It doesn't really matter which way it goes, as long as it's consistent. Currently, if I reduce the convergence (going to negative values), the object distance is increased and I gain more depth. Setting convergence to -2.0 is a good compromise value for my display size and distance, I think; setting it to positive +2.0 brings everything into the space between the monitor and my eyes. So, it just needs to be decided which way you wish it to be, and then use the correct notation in the readme to tell players how to adjust it.



Regarding eye separation: Yes, I use same separation values for both internal and external view. The reason I do this is that I don't really want "exaggerated" 3D effect in externals - I want it to look more like I was there looking at things with my own eyes.

Oh! One thing I noticed. Mode C does not work, and accidentally selecting that mode hangs the game and forces me to kill the process via task manager. This also means I can't select Mode D or Mode B- (not that I would have use for them either, but accidentally scrolling to wrong direction has become a bit of an annoyance, when it essentially crashes the game.

So, it might be handy to disable it by default, and make it so that Quadro owners have to enable it with a

PAL3DModeCEnabled=1

and the rest of us, for whom it causes crashes, don't need to trouble ourselves with it.

[benitomuso]

Herra,
            in fact yes, it is a matter of convention and it works consistently. So Convergence ~= Inward crossed view ~= Positive Values.

  Regarding the other question: what brand of video card do you use? If you activate the Java Console (Shift + TAB) you will see that for any mode change, some lines are recorded, specifying if your card has real Stereo 3D (double buffers as in Quadro cards). If you see a "No" there then the Stereo Feature my MOD will not try to address any Quadro buffer and instead of that it will work with the so called "Auxiliary Buffers" which are a space taken from your main memory. In ATI you can switch instantaneously to Mode C and it works slowly but you don't have any problem on the switch. I had the chance of testing in an nVIDIA of a friend and when changing to Mode C the game got frozen for some seconds (not too many, about 6). It seems that the nVIDIA card doesn't have the auxiliary buffers pre-initialized, so it did it in that switch of mode. But after that frozen time, Mode C started to work quite good (a little fps under Mode A and B but clearly better that the performance of my ATI cards in Mode C). And after that first episode you can later change modes without any interruption passing through or staying at Mode C. Please check to confirm if this is valid for you too.

  The existance of the Quadro buffers is taken into accoutn to only activate them if present. Perhaps another check can be introduced to see if there are operative auxiliary buffers.

  Regards,
                       Pablo