-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Jme3 vr #828
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Jme3 vr #828
Conversation
User can specify external OpenVR library to load with openvr.library.path system property. Usage: java -Dopenvr.library.name=my_path_to_library MyApp Removed reference to OCCULUS VR and OpenVR from VRAppstate as this class is generic and does not have to be linked to specific implementation. VRMouseManager can be buggous using OSVR or Occulus VR. Refactored VR implementation packages in order to separate all available implementation. Modifying or adding implementation should no more impact other ones. Renamed some classes in order to be uniform
Adding sample for VR AppState Added OSVRMouseManager in order to handle VRMouseManager for OSVR environment Added OcculusMouseManager in order to handle VRMouseManager for Oculus environment Changed OpenVRMouseManager reference within VRAppState and VREnvironment into VRMouseManager
Adding AWT component rendering capabilities for any JMonkeyEngine renderer (works with LWJGL 3.1.x and compatible with other implementations) This implementation differs from the previous one as it's relies on AppState (compatible with all JME application) and as it use only produces framebuffer. With this implementation, it is possible to use AWT component ad rendering target and so to integrate JMonkey rendering within AWT / Swing application. This capability was not available with LWJGL3 as the version 3.1.x does not provide anymore AWT link.
Added Update within AWTComponentAppState and added getter and setter for transfer mode within AWTFramePRocessor
|
Is see this correctly, that only a new integration way is added, but nothing is removed? (So can be merged without destroying anything?) |
|
The idea of this commit is to have AWT component rendering capability respire the underlying renderer. More over, the use of an app state enable to use the component rendering without creating a specific application. My problem is that the existing AWT related classes seems to only work with lwjgl3 and as i dis not want to break somethings i've committed classes with same lames bu within différents packages. |
|
Sorry for the mistakes within my previous comment. I wanted to says "despite" instead of "respire" and the actual AWT classes works only with lwjgl2 and not lwjgl3 or other renderer. |
|
@shadowislord could you look into this PR please? |
|
Hello Guys, Sorry but nobody has accepted or rejected my pull request. Is it possible to accept or reject it ? Thanks a lot. |
|
Since I see no removals and only additions, so I guess this is ok from my point of view. |
|
I'm sorry with this mistake but in fact this PR is not related with VR. This PR deal with the fact that when using LWJGL 3, the AWTCanvas and the related classes that enable to render Jmonkey within an AWT/SWING component are no more available. This PR add new classes that enable to display JMonkey rendering within any AWT component and so that enable to intégrateur JMonkey rendering within any AWT/SWING application. The interest is that or does notre relies on specific LWJGL version. The link with VR is that i'm also contributing to the VR module and a used the sale branch to make the pull request. Sorry |
|
I also don't know enough about AWT/SWING to decide whether this PR should be integrated or not. You might request integration at the Forum, or from specific members of the project team. |
|
I've reactivated the forum topic that i have opened months ago ( AWT / Swing rendering with LWGJL 3.1.X) I hope that some guys will enable you to authorize (or reject) this PR. |
|
Hello, Does anyone can have a look to this PR ? I would like to know if it is acceptable ? |
|
Well since there were no prior objections, and apparently noone else feels like knowing enough about the integration, I just merged it. |
I propose within this PR an AWT component rendering within app state
This implementation differs from the previous one as it's relies on AppState (compatible with all JME application) and as it use only produced framebuffer (no link with native objects).
With this implementation, it is possible to use AWT component ad rendering target and so to integrate JMonkey rendering within AWT / Swing application. This capability was no more available with LWJGL3 as the version 3.1.x does not provide anymore AWT link.
The old AWT integration cannot be removed at this time as many users of JMonkey use AWT canvas, however, those that want to use LWJGL3 version of Jmonkey (for example to use VR capabilities) have no more access to AWT capabilities. This is the reason why my commit add redundancy with some classes...