Stereoscopic configuration issues #13

kavon · 2014-08-05T14:51:40Z

I was trying to transition a piece of software that supports stereo 3d from 1.5.2 to 1.6, but found it wouldn't actually detect whether or not stereo is supported. The "best configuration" generated based on the specifications turned out to be the issue.

On systems which have support for stereoscopic 3D (most quadros, etc), even if the driver has specified that it is on, using getBestConfiguration does not yield a configuration that ever says that stereo is supported unless if it is created as stereo REQUIRED, which defeats the purpose of PREFERRED, because if it's REQUIRED and not actually available, it is expected to return null according to the documentation, which it doesn't seem to do either.

I fixed this issue by finding the commit that broke this, and it had to do with a graphics configuration change for mac (which was merged into your trunk from another fork). Most of the code in these commits were based on how the prior commit functioned. I thought you might want to integrate at least some of these changes.

Note:

The last commit involving the eye swapping is something that is needed for the systems that I'm using because there is no support to swap eyes in a hardware configuration. It should work universally for anyone who wants it and perhaps isn't a bad addition to the api?
I have only tested these changes on Windows.

…ions

hharrison · 2014-08-05T17:33:06Z

It would be very helpful if you could identify the commit you found that
broke this, just to help me
compare. I'm guessing you mean commit:
167369e,
but please confirm.

Thanks very much for doing this, provided you've actually tested this, I'm
content to just merge it
and get some more testers to have a go with it.

Harvey

On Tue, Aug 5, 2014 at 7:51 AM, Kavon Farvardin notifications@github.com
wrote:

I was trying to transition a piece of software that supports stereo 3d
from 1.5.2 to 1.6, but found it wouldn't actually detect whether or not
stereo is supported or not. The "best configuration" generated based on the
specifications turned out to be the issue.

On systems which have support for stereoscopic 3D (most quadros, etc),
even if the driver has specified that it is on, using getBestConfiguration
does not yield a configuration that ever says that stereo is supported
unless if it is created as stereo REQUIRED, which defeats the purpose of
PREFERRED, because if it's REQUIRED and not actually available, it is
expected to return null according to the documentation, which it doesn't
seem to do either.

I fixed this issue by finding the commit that broke this, and it had to do
with a graphics configuration change for mac (which was merged into your
trunk from another fork). Most of the code in these commits were based on
how the prior commit functioned. I thought you might want to integrate at
least some of these changes.

Note:

The last commit involving the eye swapping is something that is
specific to the systems that I'm using because there is no support to swap
eyes in a hardware configuration.

2. I have only tested these changes on Windows.

You can merge this Pull Request by running

git pull https://github.com/kavon/java3d-core master

Or view, comment on, or merge it at:

#13
Commit Summary

initial fix for stereoscopic and double buffering graphics
configurations

removed dead code

adding software implementation of eye swapping for stereo 3d

File Changes

M src/classes/share/javax/media/j3d/Canvas3D.java
https://github.com/hharrison/java3d-core/pull/13/files#diff-0 (26)

M src/classes/share/javax/media/j3d/JoglPipeline.java
https://github.com/hharrison/java3d-core/pull/13/files#diff-1 (604)

M src/classes/share/javax/media/j3d/Renderer.java
https://github.com/hharrison/java3d-core/pull/13/files#diff-2 (4)

Patch Links:

https://github.com/hharrison/java3d-core/pull/13.patch

https://github.com/hharrison/java3d-core/pull/13.diff

—
Reply to this email directly or view it on GitHub
#13.

hharrison · 2014-08-05T17:51:53Z

Hi Kavon,

I have a few questions I ask everyone that contributes code, basically
the Linux kernel's contribution agreement, can you
agree with the following (not a legal agreement, basically just saying
you have the right to release the
code under the license of the project, in this case GPLv2 w/ classpath
exception)

If you can agree to the below, can you reply in an email containing the text:

Signed-off-by: "Your Name" you@email.com

Be aware this will appear in the public git record of the project, and
will also be how you are
credited as the author of these changes.

Thanks!!

Harvey harvey.harrison@gmail.com

    Developer's Certificate of Origin 1.1

    By making a contribution to this project, I certify that:

    (a) The contribution was created in whole or in part by me and I
        have the right to submit it under the open source license
        indicated in the file; or

    (b) The contribution is based upon previous work that, to the best
        of my knowledge, is covered under an appropriate open source
        license and I have the right under that license to submit that
        work with modifications, whether created in whole or in part
        by me, under the same open source license (unless I am
        permitted to submit under a different license), as indicated
        in the file; or

    (c) The contribution was provided directly to me by some other
        person who certified (a), (b) or (c) and I have not modified
        it.

    (d) I understand and agree that this project and the contribution
        are public and that a record of the contribution (including all
        personal information I submit with it, including my sign-off) is
        maintained indefinitely and may be redistributed consistent with
        this project or the open source license(s) involved.

kavon · 2014-08-05T18:59:23Z

Hi Harvey,

Yes that is the commit I was referring to. (167369e
a8a2f565b3)

On Tue, Aug 5, 2014 at 1:33 PM, Harvey Harrison notifications@github.com
wrote:

It would be very helpful if you could identify the commit you found that
broke this, just to help me
compare. I'm guessing you mean commit:
167369e,
but please confirm.

Thanks very much for doing this, provided you've actually tested this, I'm
content to just merge it
and get some more testers to have a go with it.

Harvey

On Tue, Aug 5, 2014 at 7:51 AM, Kavon Farvardin notifications@github.com

wrote:

I was trying to transition a piece of software that supports stereo 3d
from 1.5.2 to 1.6, but found it wouldn't actually detect whether or not
stereo is supported or not. The "best configuration" generated based on
the
specifications turned out to be the issue.

On systems which have support for stereoscopic 3D (most quadros, etc),
even if the driver has specified that it is on, using
getBestConfiguration
does not yield a configuration that ever says that stereo is supported
unless if it is created as stereo REQUIRED, which defeats the purpose of
PREFERRED, because if it's REQUIRED and not actually available, it is
expected to return null according to the documentation, which it doesn't
seem to do either.

I fixed this issue by finding the commit that broke this, and it had to
do
with a graphics configuration change for mac (which was merged into your
trunk from another fork). Most of the code in these commits were based
on
how the prior commit functioned. I thought you might want to integrate
at
least some of these changes.

Note:

The last commit involving the eye swapping is something that is
specific to the systems that I'm using because there is no support to
swap
eyes in a hardware configuration.

2. I have only tested these changes on Windows.

You can merge this Pull Request by running

git pull https://github.com/kavon/java3d-core master

Or view, comment on, or merge it at:

#13
Commit Summary

initial fix for stereoscopic and double buffering graphics
configurations

removed dead code

adding software implementation of eye swapping for stereo 3d

File Changes

M src/classes/share/javax/media/j3d/Canvas3D.java
https://github.com/hharrison/java3d-core/pull/13/files#diff-0 (26)

M src/classes/share/javax/media/j3d/JoglPipeline.java
https://github.com/hharrison/java3d-core/pull/13/files#diff-1 (604)

M src/classes/share/javax/media/j3d/Renderer.java
https://github.com/hharrison/java3d-core/pull/13/files#diff-2 (4)

Patch Links:

https://github.com/hharrison/java3d-core/pull/13.patch

https://github.com/hharrison/java3d-core/pull/13.diff

—
Reply to this email directly or view it on GitHub
#13.

—
Reply to this email directly or view it on GitHub
#13 (comment).

kavon · 2014-08-05T19:02:36Z

Yes, the contribution agreement is fine by me.

Signed-off-by: "Kavon Farvardin" kavon.farvardin@gmail.com

On Tue, Aug 5, 2014 at 1:51 PM, Harvey Harrison notifications@github.com
wrote:

Hi Kavon,

I have a few questions I ask everyone that contributes code, basically
the Linux kernel's contribution agreement, can you
agree with the following (not a legal agreement, basically just saying
you have the right to release the
code under the license of the project, in this case GPLv2 w/ classpath
exception)

If you can agree to the below, can you reply in an email containing the
text:

Signed-off-by: "Your Name" you@email.com

Be aware this will appear in the public git record of the project, and
will also be how you are
credited as the author of these changes.

Thanks!!

Harvey harvey.harrison@gmail.com
Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.
—
Reply to this email directly or view it on GitHub
#13 (comment).

hharrison · 2014-08-05T23:23:26Z

I've pulled in the first two patches from your request and added you signed off by to them.

I'm considering the swapEyes patch now, I'm thinking it will need to be reworked a little bit, we can't
make the FIELD_LEFT/FIELD_RIGHT values writable, they could have been inlined into other people's
classes at compile time (they're public static final currently), in which case their code will break unexpectadly until they recompile, which I'd rather not do.

I'm thinking a getter in Canvas3D that returns the constant that is wanted.

I'll push out a commit for your review by end of day, have a bit of work stuff I need to get done first.

Harvey

hharrison · 2014-08-06T05:00:57Z

Kavon,

I've pushed out an alternate approach to the swapfields branch, commit: c4f1134, could you take a look and see if that would be sufficient for your needs, the system property approach would make sure no existing user is impacted
and would apply globally to all canvas3Ds....please let me know if this would be workable for you.

Harvey

kavon · 2014-08-07T15:25:43Z

After looking into this further, whether you need to switch the left/right
eye is only known at runtime, so a command line flag isn't very useful. The
3D monitor I had added the workaround for only needs it because it lacks a
sync cable, and any piece of 3D hardware worth it's salt should have one.
Maybe we should hold off on adding this to the mainline J3D until we find
out if this problem is more common than I think. The software may end up
dropping support for the monitor anyways.

On Wed, Aug 6, 2014 at 1:00 AM, Harvey Harrison notifications@github.com
wrote:

Kavon,

I've pushed out an alternate approach to the swapfields branch, commit:
c4f1134
c4f1134,
could you take a look and see if that would be sufficient for your needs,
the system property approach would make sure no existing user is impacted
and would apply globally to all canvas3Ds....please let me know if this
would be workable for you.

Harvey

—
Reply to this email directly or view it on GitHub
#13 (comment).

hharrison · 2014-08-07T15:31:40Z

Sure, let's hold off for now, did the patch actually work for you? If it
works, I'll hold on to it for awhile in case it's needed.

Harvey
On 7 Aug 2014 08:25, "Kavon Farvardin" notifications@github.com wrote:

After looking into this further, whether you need to switch the left/right
eye is only known at runtime, so a command line flag isn't very useful.
The
3D monitor I had added the workaround for only needs it because it lacks a
sync cable, and any piece of 3D hardware worth it's salt should have one.
Maybe we should hold off on adding this to the mainline J3D until we find
out if this problem is more common than I think. The software may end up
dropping support for the monitor anyways.

On Wed, Aug 6, 2014 at 1:00 AM, Harvey Harrison notifications@github.com

wrote:

Kavon,

I've pushed out an alternate approach to the swapfields branch, commit:
c4f1134
<
c4f1134a99beadfaf452fdb0db81c5960768352d>,

could you take a look and see if that would be sufficient for your
needs,
the system property approach would make sure no existing user is
impacted
and would apply globally to all canvas3Ds....please let me know if this
would be workable for you.

Harvey

—
Reply to this email directly or view it on GitHub
#13 (comment).

—
Reply to this email directly or view it on GitHub
#13 (comment).

kavon added 3 commits May 28, 2014 17:26

initial fix for stereoscopic and double buffering graphics configurat…

bddf848

…ions

removed dead code

46ed8d9

adding software implementation of eye swapping for stereo 3d

7be6e19

kavon closed this Oct 8, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Stereoscopic configuration issues #13

Stereoscopic configuration issues #13

kavon commented Aug 5, 2014

hharrison commented Aug 5, 2014

2. I have only tested these changes on Windows.

hharrison commented Aug 5, 2014

kavon commented Aug 5, 2014

2. I have only tested these changes on Windows.

kavon commented Aug 5, 2014

hharrison commented Aug 5, 2014

hharrison commented Aug 6, 2014

kavon commented Aug 7, 2014

hharrison commented Aug 7, 2014

Stereoscopic configuration issues #13

Stereoscopic configuration issues #13

Conversation

kavon commented Aug 5, 2014

hharrison commented Aug 5, 2014

2. I have only tested these changes on Windows.

hharrison commented Aug 5, 2014

kavon commented Aug 5, 2014

2. I have only tested these changes on Windows.

kavon commented Aug 5, 2014

hharrison commented Aug 5, 2014

hharrison commented Aug 6, 2014

kavon commented Aug 7, 2014

hharrison commented Aug 7, 2014