search

hharrison / java3d-core

Fork of the javax.media.j3d package
GNU General Public License v2.0
85 stars 39 forks source link

Stereoscopic configuration issues #13

Closed kavon closed 4 years ago

kavon commented 10 years ago

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:

  1. 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?
  2. I have only tested these changes on Windows.
hharrison commented 10 years ago

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: 167369e0df9044a86bf749425feedaa8a2f565b3, 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:

  1. 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:

https://github.com/hharrison/java3d-core/pull/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

Patch Links:

— Reply to this email directly or view it on GitHub https://github.com/hharrison/java3d-core/pull/13.

hharrison commented 10 years ago

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 commented 10 years ago

Hi Harvey,

Yes that is the commit I was referring to. (167369e0df9044a86bf749425feeda 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: 167369e0df9044a86bf749425feedaa8a2f565b3, 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:

  1. 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:

https://github.com/hharrison/java3d-core/pull/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

Patch Links:

— Reply to this email directly or view it on GitHub https://github.com/hharrison/java3d-core/pull/13.

— Reply to this email directly or view it on GitHub https://github.com/hharrison/java3d-core/pull/13#issuecomment-51231615.

kavon commented 10 years ago

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 https://github.com/hharrison/java3d-core/pull/13#issuecomment-51233999.

hharrison commented 10 years ago

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 commented 10 years ago

Kavon,

I've pushed out an alternate approach to the swapfields branch, commit: 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

kavon commented 10 years ago

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 https://github.com/hharrison/java3d-core/commit/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 https://github.com/hharrison/java3d-core/pull/13#issuecomment-51294037.

hharrison commented 10 years ago

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 < https://github.com/hharrison/java3d-core/commit/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 https://github.com/hharrison/java3d-core/pull/13#issuecomment-51294037.

— Reply to this email directly or view it on GitHub https://github.com/hharrison/java3d-core/pull/13#issuecomment-51487469.