Separating Oculus View from Controls

[ehaensgen]

Daniel, Long time no talk! :-) I don't know if you remember me, but I was curious if you had continued any development with the Oculus and/or WorldWind? I just recently picked this project back up for work and I was finally able to get the java project to run and using the goggles. I am trying to wrap my head around how I might be able to separate the Oculus view movement from the keyboard direction keys. Basically, I want the goggles to be used to look around but not affect the direction of the movement when the keys are pressed on the keyboard. I am an experienced developer, but more in the Visual Studio C# arena and not so much in the OpenGL 3D field. Not to mention, it seems you have done quite a bit of work building the code to use the goggles and have a decent understanding of 3D concepts. I was hoping you might be able to point me to where in the code you think I can do that.

Thanks, Eric

[danielr2e]

Hi Eric,

You were the guy who got the DK2 code from Google code, right? I still haven't moved that over to github, so that tells you how much I've worked on it :)

I'm actually not experienced with 3D stuff at all, and only got the port working through force of will, so your experience may not be too far off my own. You are in luck, however, that anything involving input will be a lot easier for you to understand than the OpenGL/rendering stuff.

The keyboard behavior is more or less what is built into WorldWind as the 'fly view' controls. There is a custom version of this logic where you could probably modify it to decouple the view from the orientation used for flying around. I'm actually not quite sure what you have in mind, though, because you need some way to control that frame of reference to actually travel in different directions. PC shooters like counter strike have the view locked to the direction of movement for a reason, right? Maybe you could make it so that if you hold the right mouse button, it lets you look around without changing the direction of movement?

Anyway, the class you would want to look at is:

https://code.google.com/p/worldwind-vr/source/browse/worldwind-vr-dk2/src/com/tuohy/worldwindvr/input/VRFlyViewInputHandler.java

If you want to do something similar with the 360 controller (dual analog sticks might give you the flexibility you need!), check out:

https://code.google.com/p/worldwind-vr/source/browse/worldwind-vr-dk2/src/com/tuohy/worldwindvr/input/Xbox360Controller.java

I think the 360 controller was kind of working, but it was the last thing I worked on, so I can't quite recall.

Daniel

On Mon, Jan 11, 2016 at 1:40 PM, ehaensgen notifications@github.com wrote:

Daniel, Long time no talk! :-) I don't know if you remember me, but I was curious if you had continued any development with the Oculus and/or WorldWind? I just recently picked this project back up for work and I was finally able to get the java project to run and using the goggles I am trying to wrap my head around how I might be able to separate the Oculus view movement from the keyboard direction keys Basically, I want the goggles to be used to look around but not affect the direction of the movement when the keys are pressed on the keyboard I am an experienced developer, but more in the Visual Studio C# arena and not so much in the OpenGL 3D field Not to mention, it seems you have done quite a bit of work building the code to use the goggles and have a decent understanding of 3D concepts I was hoping you might be able to point me to where in the code you think I can do that

Thanks, Eric

— Reply to this email directly or view it on GitHub https://github.com/danielr2e/worldwind-vr/issues/4.

[ehaensgen]

Thank you for the quick response. Essentially what I am attempting to accomplish is making it so that the viewer is, in essence, sitting in a vehicle that moves independently from the direction of the goggles. Sort of like a flight simulator. I want to be able to use the keyboard to move around the environment, but use the goggles strictly for viewing. It would be move like Half-LifeX where while you are in a vehicle you can use the mouse to look around, but driving is done by the keyboard. My thought was to create a "vehicle" class that would extend the BasicView functionality and maintain two separate views and modify the code to get heading/pitch/etc from the "vehicle" view. Sadly, my brain has been in overload since picking this project back up. I was able to use to code you had sent me from google to get the DK2 working and am slowly learning the interface that you had built and the original Java world wind software (which I downloaded but am unable to compile). I have look extensively at the VRFlyView and VRFlyViewInputHandler code. I was finally able to modify the onHorizontalTranslateRel function to ignore the pitch of the goggles, but am back at square one with determining how to force it to ignore the heading of the goggles since that it still required, I just need to feed it a different object. Damn 3D crap is so frustrating sometimes. ;-)

Thanks, Eric

On Mon, Jan 11, 2016 at 11:37 AM, danielr2e notifications@github.com wrote:

Hi Eric,

You were the guy who got the DK2 code from Google code, right? I still haven't moved that over to github, so that tells you how much I've worked on it :)

I'm actually not experienced with 3D stuff at all, and only got the port working through force of will, so your experience may not be too far off my own. You are in luck, however, that anything involving input will be a lot easier for you to understand than the OpenGL/rendering stuff.

The keyboard behavior is more or less what is built into WorldWind as the 'fly view' controls. There is a custom version of this logic where you could probably modify it to decouple the view from the orientation used for flying around. I'm actually not quite sure what you have in mind, though, because you need some way to control that frame of reference to actually travel in different directions. PC shooters like counter strike have the view locked to the direction of movement for a reason, right? Maybe you could make it so that if you hold the right mouse button, it lets you look around without changing the direction of movement?

Anyway, the class you would want to look at is:

https://code.google.com/p/worldwind-vr/source/browse/worldwind-vr-dk2/src/com/tuohy/worldwindvr/input/VRFlyViewInputHandler.java

If you want to do something similar with the 360 controller (dual analog sticks might give you the flexibility you need!), check out:

https://code.google.com/p/worldwind-vr/source/browse/worldwind-vr-dk2/src/com/tuohy/worldwindvr/input/Xbox360Controller.java

I think the 360 controller was kind of working, but it was the last thing I worked on, so I can't quite recall.

Daniel

On Mon, Jan 11, 2016 at 1:40 PM, ehaensgen notifications@github.com wrote:

Daniel, Long time no talk! :-) I don't know if you remember me, but I was curious if you had continued any development with the Oculus and/or WorldWind? I just recently picked this project back up for work and I was finally able to get the java project to run and using the goggles I am trying to wrap my head around how I might be able to separate the Oculus view movement from the keyboard direction keys Basically, I want the goggles to be used to look around but not affect the direction of the movement when the keys are pressed on the keyboard I am an experienced developer, but more in the Visual Studio C# arena and not so much in the OpenGL 3D field Not to mention, it seems you have done quite a bit of work building the code to use the goggles and have a decent understanding of 3D concepts I was hoping you might be able to point me to where in the code you think I can do that

Thanks, Eric

— Reply to this email directly or view it on GitHub https://github.com/danielr2e/worldwind-vr/issues/4.

— Reply to this email directly or view it on GitHub https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170665988 .

---

Eric A. Haensgen

[danielr2e]

Ah, OK. If I were doing it, I would just try to find out where the key presses are currently being used to translate the camera position (probably in the fly view handler). Look for uses of the View instance, which gives you access to the position, pitch, roll and heading. Then change that translation logic it so that it doesn't consult the camera's orientation. Instead, you would have a 'hidden' pitch and heading that you consult. Then you would want the left/right keys to update the heading (turning the 'ship' left and right), you'll have to figure out some way to update the pitch, as that's the only way the 'ship' would be able to go up and down.

On Mon, Jan 11, 2016 at 4:23 PM, ehaensgen notifications@github.com wrote:

Thank you for the quick response. Essentially what I am attempting to accomplish is making it so that the viewer is, in essence, sitting in a vehicle that moves independently from the direction of the goggles. Sort of like a flight simulator. I want to be able to use the keyboard to move around the environment, but use the goggles strictly for viewing. It would be move like Half-LifeX where while you are in a vehicle you can use the mouse to look around, but driving is done by the keyboard. My thought was to create a "vehicle" class that would extend the BasicView functionality and maintain two separate views and modify the code to get heading/pitch/etc from the "vehicle" view. Sadly, my brain has been in overload since picking this project back up. I was able to use to code you had sent me from google to get the DK2 working and am slowly learning the interface that you had built and the original Java world wind software (which I downloaded but am unable to compile). I have look extensively at the VRFlyView and VRFlyViewInputHandler code. I was finally able to modify the onHorizontalTranslateRel function to ignore the pitch of the goggles, but am back at square one with determining how to force it to ignore the heading of the goggles since that it still required, I just need to feed it a different object. Damn 3D crap is so frustrating sometimes. ;-)

Thanks, Eric

On Mon, Jan 11, 2016 at 11:37 AM, danielr2e notifications@github.com wrote:

Hi Eric,

You were the guy who got the DK2 code from Google code, right? I still haven't moved that over to github, so that tells you how much I've worked on it :)

I'm actually not experienced with 3D stuff at all, and only got the port working through force of will, so your experience may not be too far off my own. You are in luck, however, that anything involving input will be a lot easier for you to understand than the OpenGL/rendering stuff.

The keyboard behavior is more or less what is built into WorldWind as the 'fly view' controls. There is a custom version of this logic where you could probably modify it to decouple the view from the orientation used for flying around. I'm actually not quite sure what you have in mind, though, because you need some way to control that frame of reference to actually travel in different directions. PC shooters like counter strike have the view locked to the direction of movement for a reason, right? Maybe you could make it so that if you hold the right mouse button, it lets you look around without changing the direction of movement?

Anyway, the class you would want to look at is:

https://code.google.com/p/worldwind-vr/source/browse/worldwind-vr-dk2/src/com/tuohy/worldwindvr/input/VRFlyViewInputHandler.java

If you want to do something similar with the 360 controller (dual analog sticks might give you the flexibility you need!), check out:

https://code.google.com/p/worldwind-vr/source/browse/worldwind-vr-dk2/src/com/tuohy/worldwindvr/input/Xbox360Controller.java

I think the 360 controller was kind of working, but it was the last thing I worked on, so I can't quite recall.

Daniel

On Mon, Jan 11, 2016 at 1:40 PM, ehaensgen notifications@github.com wrote:

Daniel, Long time no talk! :-) I don't know if you remember me, but I was curious if you had continued any development with the Oculus and/or WorldWind? I just recently picked this project back up for work and I was finally able to get the java project to run and using the goggles I am trying to wrap my head around how I might be able to separate the Oculus view movement from the keyboard direction keys Basically, I want the goggles to be used to look around but not affect the direction of the movement when the keys are pressed on the keyboard I am an experienced developer, but more in the Visual Studio C# arena and not so much in the OpenGL 3D field Not to mention, it seems you have done quite a bit of work building the code to use the goggles and have a decent understanding of 3D concepts I was hoping you might be able to point me to where in the code you think I can do that

Thanks, Eric

— Reply to this email directly or view it on GitHub https://github.com/danielr2e/worldwind-vr/issues/4.

— Reply to this email directly or view it on GitHub < https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170665988> .

---

Eric A. Haensgen

— Reply to this email directly or view it on GitHub https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170693857 .

[ehaensgen]

Yea, I had pretty much the same thought. I created a View object within the VRFlyViewInputHandler that was a copy of the initial positioning of the main view object and then I feed the new object into the setEyePosition function. However, Java has a very annoying way of making the new object a reference to the existing and so when it changes it changes the main object as well. It is successfully feeding in my VehicleView object, but the goggles are still causing a change in the heading because as the goggles move and update the main view object, the reference to my new object gets updated as well. I am unfortunately not Java savvy enough yet to learn how to create an independent object. :-/

On Mon, Jan 11, 2016 at 1:51 PM, danielr2e notifications@github.com wrote:

Ah, OK. If I were doing it, I would just try to find out where the key presses are currently being used to translate the camera position (probably in the fly view handler). Look for uses of the View instance, which gives you access to the position, pitch, roll and heading. Then change that translation logic it so that it doesn't consult the camera's orientation. Instead, you would have a 'hidden' pitch and heading that you consult. Then you would want the left/right keys to update the heading (turning the 'ship' left and right), you'll have to figure out some way to update the pitch, as that's the only way the 'ship' would be able to go up and down.

On Mon, Jan 11, 2016 at 4:23 PM, ehaensgen notifications@github.com wrote:

Thank you for the quick response. Essentially what I am attempting to accomplish is making it so that the viewer is, in essence, sitting in a vehicle that moves independently from the direction of the goggles. Sort of like a flight simulator. I want to be able to use the keyboard to move around the environment, but use the goggles strictly for viewing. It would be move like Half-LifeX where while you are in a vehicle you can use the mouse to look around, but driving is done by the keyboard. My thought was to create a "vehicle" class that would extend the BasicView functionality and maintain two separate views and modify the code to get heading/pitch/etc from the "vehicle" view. Sadly, my brain has been in overload since picking this project back up. I was able to use to code you had sent me from google to get the DK2 working and am slowly learning the interface that you had built and the original Java world wind software (which I downloaded but am unable to compile). I have look extensively at the VRFlyView and VRFlyViewInputHandler code. I was finally able to modify the onHorizontalTranslateRel function to ignore the pitch of the goggles, but am back at square one with determining how to force it to ignore the heading of the goggles since that it still required, I just need to feed it a different object. Damn 3D crap is so frustrating sometimes. ;-)

Thanks, Eric

On Mon, Jan 11, 2016 at 11:37 AM, danielr2e notifications@github.com wrote:

Hi Eric,

You were the guy who got the DK2 code from Google code, right? I still haven't moved that over to github, so that tells you how much I've worked on it :)

I'm actually not experienced with 3D stuff at all, and only got the port working through force of will, so your experience may not be too far off my own. You are in luck, however, that anything involving input will be a lot easier for you to understand than the OpenGL/rendering stuff.

The keyboard behavior is more or less what is built into WorldWind as the 'fly view' controls. There is a custom version of this logic where you could probably modify it to decouple the view from the orientation used for flying around. I'm actually not quite sure what you have in mind, though, because you need some way to control that frame of reference to actually travel in different directions. PC shooters like counter strike have the view locked to the direction of movement for a reason, right? Maybe you could make it so that if you hold the right mouse button, it lets you look around without changing the direction of movement?

Anyway, the class you would want to look at is:

https://code.google.com/p/worldwind-vr/source/browse/worldwind-vr-dk2/src/com/tuohy/worldwindvr/input/VRFlyViewInputHandler.java

If you want to do something similar with the 360 controller (dual analog sticks might give you the flexibility you need!), check out:

https://code.google.com/p/worldwind-vr/source/browse/worldwind-vr-dk2/src/com/tuohy/worldwindvr/input/Xbox360Controller.java

I think the 360 controller was kind of working, but it was the last thing I worked on, so I can't quite recall.

Daniel

On Mon, Jan 11, 2016 at 1:40 PM, ehaensgen notifications@github.com wrote:

Daniel, Long time no talk! :-) I don't know if you remember me, but I was curious if you had continued any development with the Oculus and/or WorldWind? I just recently picked this project back up for work and I was finally able to get the java project to run and using the goggles I am trying to wrap my head around how I might be able to separate the Oculus view movement from the keyboard direction keys Basically, I want the goggles to be used to look around but not affect the direction of the movement when the keys are pressed on the keyboard I am an experienced developer, but more in the Visual Studio C# arena and not so much in the OpenGL 3D field Not to mention, it seems you have done quite a bit of work building the code to use the goggles and have a decent understanding of 3D concepts I was hoping you might be able to point me to where in the code you think I can do that

Thanks, Eric

— Reply to this email directly or view it on GitHub https://github.com/danielr2e/worldwind-vr/issues/4.

— Reply to this email directly or view it on GitHub <

https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170665988>

.

---

Eric A. Haensgen

— Reply to this email directly or view it on GitHub < https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170693857>

.

— Reply to this email directly or view it on GitHub https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170702076 .

---

Eric A. Haensgen

[danielr2e]

You would have to create a new instance of View to store that data in. Alternatively, you could just create two primitive double variables to store the pitch and heading and bypass View altogether.

On Mon, Jan 11, 2016 at 5:48 PM, ehaensgen notifications@github.com wrote:

Yea, I had pretty much the same thought. I created a View object within the VRFlyViewInputHandler that was a copy of the initial positioning of the main view object and then I feed the new object into the setEyePosition function. However, Java has a very annoying way of making the new object a reference to the existing and so when it changes it changes the main object as well. It is successfully feeding in my VehicleView object, but the goggles are still causing a change in the heading because as the goggles move and update the main view object, the reference to my new object gets updated as well. I am unfortunately not Java savvy enough yet to learn how to create an independent object. :-/

On Mon, Jan 11, 2016 at 1:51 PM, danielr2e notifications@github.com wrote:

Ah, OK. If I were doing it, I would just try to find out where the key presses are currently being used to translate the camera position (probably in the fly view handler). Look for uses of the View instance, which gives you access to the position, pitch, roll and heading. Then change that translation logic it so that it doesn't consult the camera's orientation. Instead, you would have a 'hidden' pitch and heading that you consult. Then you would want the left/right keys to update the heading (turning the 'ship' left and right), you'll have to figure out some way to update the pitch, as that's the only way the 'ship' would be able to go up and down.

On Mon, Jan 11, 2016 at 4:23 PM, ehaensgen notifications@github.com wrote:

Thank you for the quick response. Essentially what I am attempting to accomplish is making it so that the viewer is, in essence, sitting in a vehicle that moves independently from the direction of the goggles. Sort of like a flight simulator. I want to be able to use the keyboard to move around the environment, but use the goggles strictly for viewing. It would be move like Half-LifeX where while you are in a vehicle you can use the mouse to look around, but driving is done by the keyboard. My thought was to create a "vehicle" class that would extend the BasicView functionality and maintain two separate views and modify the code to get heading/pitch/etc from the "vehicle" view. Sadly, my brain has been in overload since picking this project back up. I was able to use to code you had sent me from google to get the DK2 working and am slowly learning the interface that you had built and the original Java world wind software (which I downloaded but am unable to compile). I have look extensively at the VRFlyView and VRFlyViewInputHandler code. I was finally able to

modify

the onHorizontalTranslateRel function to ignore the pitch of the goggles, but am back at square one with determining how to force it to ignore the heading of the goggles since that it still required, I just need to feed it a different object. Damn 3D crap is so frustrating sometimes. ;-)

Thanks, Eric

On Mon, Jan 11, 2016 at 11:37 AM, danielr2e notifications@github.com wrote:

Hi Eric,

You were the guy who got the DK2 code from Google code, right? I still haven't moved that over to github, so that tells you how much I've worked on it :)

I'm actually not experienced with 3D stuff at all, and only got the port working through force of will, so your experience may not be too far off my own. You are in luck, however, that anything involving input will be a lot easier for you to understand than the OpenGL/rendering stuff.

The keyboard behavior is more or less what is built into WorldWind as the 'fly view' controls. There is a custom version of this logic where you could probably modify it to decouple the view from the orientation used for flying around. I'm actually not quite sure what you have in mind, though, because you need some way to control that frame of reference to actually travel in different directions. PC shooters like counter strike have the view locked to the direction of movement for a reason, right? Maybe you could make it so that if you hold the right mouse button, it lets you look around without changing the direction of movement?

Anyway, the class you would want to look at is:

https://code.google.com/p/worldwind-vr/source/browse/worldwind-vr-dk2/src/com/tuohy/worldwindvr/input/VRFlyViewInputHandler.java

If you want to do something similar with the 360 controller (dual analog sticks might give you the flexibility you need!), check out:

https://code.google.com/p/worldwind-vr/source/browse/worldwind-vr-dk2/src/com/tuohy/worldwindvr/input/Xbox360Controller.java

I think the 360 controller was kind of working, but it was the last thing I worked on, so I can't quite recall.

Daniel

On Mon, Jan 11, 2016 at 1:40 PM, ehaensgen <notifications@github.com

wrote:

Daniel, Long time no talk! :-) I don't know if you remember me, but I was curious if you had continued any development with the Oculus and/or WorldWind? I just recently picked this project back up for work and I was finally able to get the java project to run and using the goggles I am trying to wrap my head around how I might be able to separate the Oculus view movement from the keyboard direction keys Basically, I want the goggles to be used to look around but not affect the direction of the movement when the keys are pressed on the keyboard I am an experienced developer, but more in the Visual Studio C# arena and not so much in the OpenGL 3D field Not to mention, it seems you have done quite a bit of work building the code to use the goggles and have a decent understanding of 3D concepts I was hoping you might be able to point me to where in the code you think I can do that

Thanks, Eric

— Reply to this email directly or view it on GitHub https://github.com/danielr2e/worldwind-vr/issues/4.

— Reply to this email directly or view it on GitHub <

https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170665988>

.

---

Eric A. Haensgen

— Reply to this email directly or view it on GitHub <

https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170693857>

.

— Reply to this email directly or view it on GitHub < https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170702076> .

---

Eric A. Haensgen

— Reply to this email directly or view it on GitHub https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170717419 .

[ehaensgen]

I have been going the route of creating a new instance of a view and initially filling it with the live view. So far it has worked as far as separating out the goggles from the "vehicle". At least as far as the heading of the goggles and the heading of the vehicle view. The problem I am having now is getting the vehicle to move and then updating the goggle view to follow. I can see that the function is getting called, but it does not change the lat/long. If you wouldn't mind, can you take a look at the code below and see if there is something I am missing?

protected void onHorizontalTranslateRel(Angle forwardChange, Angle

sideChange, ViewInputAttributes.ActionAttributes actionAttribs) { View view = this.getView(); if (view == null) // include this test to ensure any derived implementation performs it { return; }

    if (forwardChange.equals(Angle.ZERO) &&

sideChange.equals(Angle.ZERO)) { return; }

    if (view instanceof BasicFlyView)
    {
        Vec4 forward = view.getForwardVector();
        Vec4 up = view.getUpVector();
        Vec4 side =

forward.transformBy3(Matrix.fromAxisAngle(Angle.fromDegrees(90), up));

        forward = forward.multiply3(forwardChange.getDegrees());
        side = side.multiply3(sideChange.getDegrees());
        //Vec4 eyePoint = view.getEyePoint();
        Vec4 eyePoint = getCurrentVehiclePoint(vehicle);

        // *** This is properly showing the goggles (main view) and the

vehicle headings are different as I move the goggles around System.out.println("Main heading; " + view.getHeading() + " - My heading: " + vehicle.getHeading());

        eyePoint = eyePoint.add3(forward.add3(side));
        Position newPosition =

vehicle.getGlobe().computePositionFromPoint(eyePoint);

        //Ignore goggle pitch
        LatLon latlon = new

LatLon(Angle.fromDegrees(newPosition.latitude.degrees), Angle.fromDegrees(newPosition.longitude.degrees)); Position myPos = new Position(latlon, getView().getCurrentEyePosition().getAltitude());

        this.setEyePosition(this.uiAnimControl, vehicle, myPos,

actionAttribs);

        // *** The above code runs without any errors, but the heading

is not updated. I have also tried vehicle.setEyePosition(...), but same issue. System.out.println("head: " + vehicle.getHeading() + ", Pos: "

• vehicle.getEyePosition().latitude.degrees + ":" + vehicle.getEyePosition().longitude.degrees);

    this.setEyePosition(this.uiAnimControl, view,

  vehicle.eyePosition, actionAttribs); view.firePropertyChange(AVKey.VIEW, null, this.vehicle); } }

Thanks, Eric

On Mon, Jan 11, 2016 at 4:52 PM, danielr2e notifications@github.com wrote:

You would have to create a new instance of View to store that data in. Alternatively, you could just create two primitive double variables to store the pitch and heading and bypass View altogether.

On Mon, Jan 11, 2016 at 5:48 PM, ehaensgen notifications@github.com wrote:

Yea, I had pretty much the same thought. I created a View object within the VRFlyViewInputHandler that was a copy of the initial positioning of the main view object and then I feed the new object into the setEyePosition function. However, Java has a very annoying way of making the new object a reference to the existing and so when it changes it changes the main object as well. It is successfully feeding in my VehicleView object, but the goggles are still causing a change in the heading because as the goggles move and update the main view object, the reference to my new object gets updated as well. I am unfortunately not Java savvy enough yet to learn how to create an independent object. :-/

On Mon, Jan 11, 2016 at 1:51 PM, danielr2e notifications@github.com wrote:

Ah, OK. If I were doing it, I would just try to find out where the key presses are currently being used to translate the camera position (probably in the fly view handler). Look for uses of the View instance, which gives you access to the position, pitch, roll and heading. Then change that translation logic it so that it doesn't consult the camera's orientation. Instead, you would have a 'hidden' pitch and heading that you consult. Then you would want the left/right keys to update the heading (turning the 'ship' left and right), you'll have to figure out some way to update the pitch, as that's the only way the 'ship' would be able to go up and down.

On Mon, Jan 11, 2016 at 4:23 PM, ehaensgen notifications@github.com wrote:

Thank you for the quick response. Essentially what I am attempting to accomplish is making it so that the viewer is, in essence, sitting in a vehicle that moves independently from the direction of the goggles. Sort of like a flight simulator. I want to be able to use the keyboard to move around the environment, but use the goggles strictly for viewing. It would be move like Half-LifeX where while you are in a vehicle you can use the mouse to look around, but driving is done by the keyboard. My thought was to create a "vehicle" class that would extend the BasicView functionality and maintain two separate views and modify the code to get heading/pitch/etc from the "vehicle" view. Sadly, my brain has been in overload since picking this project back up. I was able to use to code you had sent me from google to get the DK2 working and am slowly learning the interface that you had built and the original Java world wind software (which I downloaded but am unable to compile). I have look extensively at the VRFlyView and VRFlyViewInputHandler code. I was finally able to

modify

the onHorizontalTranslateRel function to ignore the pitch of the goggles, but am back at square one with determining how to force it to ignore the heading of the goggles since that it still required, I just need to feed it a different object. Damn 3D crap is so frustrating sometimes. ;-)

Thanks, Eric

On Mon, Jan 11, 2016 at 11:37 AM, danielr2e < notifications@github.com> wrote:

Hi Eric,

You were the guy who got the DK2 code from Google code, right? I still haven't moved that over to github, so that tells you how much I've worked on it :)

I'm actually not experienced with 3D stuff at all, and only got the port working through force of will, so your experience may not be too far off my own. You are in luck, however, that anything involving input will be a lot easier for you to understand than the OpenGL/rendering stuff.

The keyboard behavior is more or less what is built into WorldWind as the 'fly view' controls. There is a custom version of this logic where you could probably modify it to decouple the view from the orientation used for flying around. I'm actually not quite sure what you have in mind, though, because you need some way to control that frame of reference to actually travel in different directions. PC shooters like counter strike have the view locked to the direction of movement for a reason, right? Maybe you could make it so that if you hold the right mouse button, it lets you look around without changing the direction of movement?

Anyway, the class you would want to look at is:

https://code.google.com/p/worldwind-vr/source/browse/worldwind-vr-dk2/src/com/tuohy/worldwindvr/input/VRFlyViewInputHandler.java

If you want to do something similar with the 360 controller (dual analog sticks might give you the flexibility you need!), check out:

https://code.google.com/p/worldwind-vr/source/browse/worldwind-vr-dk2/src/com/tuohy/worldwindvr/input/Xbox360Controller.java

I think the 360 controller was kind of working, but it was the last thing I worked on, so I can't quite recall.

Daniel

On Mon, Jan 11, 2016 at 1:40 PM, ehaensgen < notifications@github.com

wrote:

Daniel, Long time no talk! :-) I don't know if you remember me, but I was curious if you had continued any development with the Oculus and/or WorldWind? I just recently picked this project back up for work and I was finally able to get the java project to run and using the goggles I am trying to wrap my head around how I might be able to separate the Oculus view movement from the keyboard direction keys Basically, I want the goggles to be used to look around but not affect the direction of the movement when the keys are pressed on the keyboard I am an experienced developer, but more in the Visual Studio C# arena and not so much in the OpenGL 3D field Not to mention, it seems you have done quite a bit of work building the code to use the goggles and have a decent understanding of 3D concepts I was hoping you might be able to point me to where in the code you think I can do that

Thanks, Eric

— Reply to this email directly or view it on GitHub https://github.com/danielr2e/worldwind-vr/issues/4.

— Reply to this email directly or view it on GitHub <

https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170665988>

.

---

Eric A. Haensgen

— Reply to this email directly or view it on GitHub <

https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170693857>

.

— Reply to this email directly or view it on GitHub <

https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170702076>

.

---

Eric A. Haensgen

— Reply to this email directly or view it on GitHub < https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170717419>

.

— Reply to this email directly or view it on GitHub https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170745699 .

---

Eric A. Haensgen

[danielr2e]

I'm afraid this is about the point where my memory is too fuzzy on the specifics of the WorldWind API.

One tip I can recommend is that if you are in an IDE like eclipse, put a debug point at the line(s) where you are updating the camera/view position. The variable will have a hash code that will let you make sure that the instance you are changing is really the same instance that is being consulted in OculusStereoSceneController during the render (the 'dcView' variable on line 297).

On Tue, Jan 12, 2016 at 12:48 AM, ehaensgen notifications@github.com wrote:

I have been going the route of creating a new instance of a view and initially filling it with the live view. So far it has worked as far as separating out the goggles from the "vehicle". At least as far as the heading of the goggles and the heading of the vehicle view. The problem I am having now is getting the vehicle to move and then updating the goggle view to follow. I can see that the function is getting called, but it does not change the lat/long. If you wouldn't mind, can you take a look at the code below and see if there is something I am missing?

protected void onHorizontalTranslateRel(Angle forwardChange, Angle sideChange, ViewInputAttributes.ActionAttributes actionAttribs) { View view = this.getView(); if (view == null) // include this test to ensure any derived implementation performs it { return; }

if (forwardChange.equals(Angle.ZERO) && sideChange.equals(Angle.ZERO)) { return; }

if (view instanceof BasicFlyView) { Vec4 forward = view.getForwardVector(); Vec4 up = view.getUpVector(); Vec4 side = forward.transformBy3(Matrix.fromAxisAngle(Angle.fromDegrees(90), up));

forward = forward.multiply3(forwardChange.getDegrees()); side = side.multiply3(sideChange.getDegrees()); //Vec4 eyePoint = view.getEyePoint(); Vec4 eyePoint = getCurrentVehiclePoint(vehicle);

// *\ This is properly showing the goggles (main view) and the vehicle headings are different as I move the goggles around System.out.println("Main heading; " + view.getHeading() + " - My heading: " + vehicle.getHeading());

eyePoint = eyePoint.add3(forward.add3(side)); Position newPosition = vehicle.getGlobe().computePositionFromPoint(eyePoint);

//Ignore goggle pitch LatLon latlon = new LatLon(Angle.fromDegrees(newPosition.latitude.degrees), Angle.fromDegrees(newPosition.longitude.degrees)); Position myPos = new Position(latlon, getView().getCurrentEyePosition().getAltitude());

this.setEyePosition(this.uiAnimControl, vehicle, myPos, actionAttribs);

// *\ The above code runs without any errors, but the heading is not updated. I have also tried vehicle.setEyePosition(...), but same issue. System.out.println("head: " + vehicle.getHeading() + ", Pos: "

• vehicle.getEyePosition().latitude.degrees + ":" + vehicle.getEyePosition().longitude.degrees);

this.setEyePosition(this.uiAnimControl, view, vehicle.eyePosition, actionAttribs); view.firePropertyChange(AVKey.VIEW, null, this.vehicle); } }

Thanks, Eric

On Mon, Jan 11, 2016 at 4:52 PM, danielr2e notifications@github.com wrote:

You would have to create a new instance of View to store that data in. Alternatively, you could just create two primitive double variables to store the pitch and heading and bypass View altogether.

On Mon, Jan 11, 2016 at 5:48 PM, ehaensgen notifications@github.com wrote:

Yea, I had pretty much the same thought. I created a View object within the VRFlyViewInputHandler that was a copy of the initial positioning of the main view object and then I feed the new object into the setEyePosition function. However, Java has a very annoying way of making the new object a reference to the existing and so when it changes it changes the main object as well. It is successfully feeding in my VehicleView object, but the goggles are still causing a change in the heading because as the goggles move and update the main view object, the reference to my new object gets updated as well. I am unfortunately not Java savvy enough yet to learn how to create an independent object. :-/

On Mon, Jan 11, 2016 at 1:51 PM, danielr2e notifications@github.com wrote:

Ah, OK. If I were doing it, I would just try to find out where the key presses are currently being used to translate the camera position (probably in the fly view handler). Look for uses of the View instance, which gives you access to the position, pitch, roll and heading. Then change that translation logic it so that it doesn't consult the camera's orientation. Instead, you would have a 'hidden' pitch and heading that you consult. Then you would want the left/right keys to update the heading (turning the 'ship' left and right), you'll have to figure out some way to update the pitch, as that's the only way the 'ship' would be able to go up and down.

On Mon, Jan 11, 2016 at 4:23 PM, ehaensgen <notifications@github.com

wrote:

Thank you for the quick response. Essentially what I am attempting to accomplish is making it so that the viewer is, in essence, sitting in a vehicle that moves independently from the direction of the goggles. Sort of like a flight simulator. I want to be able to use the keyboard to move around the environment, but use the goggles strictly for viewing. It would be move like Half-LifeX where while you are in a vehicle you can use the mouse to look around, but driving is done by the keyboard. My thought was to create a "vehicle" class that would extend the BasicView functionality and maintain two separate views and modify the code to get heading/pitch/etc from the "vehicle" view. Sadly, my brain has been in overload since picking this project back up. I was able to use to code you had sent me from google to get the DK2 working and am slowly learning the interface that you had built and the original Java world wind software (which I downloaded but am unable to compile). I have look extensively at the VRFlyView and VRFlyViewInputHandler code. I was finally able to

modify

the onHorizontalTranslateRel function to ignore the pitch of the goggles, but am back at square one with determining how to force it to ignore the heading of the goggles since that it still required, I just need to feed it a different object. Damn 3D crap is so frustrating sometimes. ;-)

Thanks, Eric

On Mon, Jan 11, 2016 at 11:37 AM, danielr2e < notifications@github.com> wrote:

Hi Eric,

You were the guy who got the DK2 code from Google code, right? I still haven't moved that over to github, so that tells you how much I've worked on it :)

I'm actually not experienced with 3D stuff at all, and only got the port working through force of will, so your experience may not be too far off my own. You are in luck, however, that anything involving input will be a lot easier for you to understand than the OpenGL/rendering stuff.

The keyboard behavior is more or less what is built into WorldWind as the 'fly view' controls. There is a custom version of this logic where you could probably modify it to decouple the view from the orientation used for flying around. I'm actually not quite sure what you have in mind, though, because you need some way to control that frame of reference to actually travel in different directions. PC shooters like counter strike have the view locked to the direction of movement for a reason, right? Maybe you could make it so that if you hold the right mouse button, it lets you look around without changing the direction of movement?

Anyway, the class you would want to look at is:

https://code.google.com/p/worldwind-vr/source/browse/worldwind-vr-dk2/src/com/tuohy/worldwindvr/input/VRFlyViewInputHandler.java

If you want to do something similar with the 360 controller (dual analog sticks might give you the flexibility you need!), check out:

https://code.google.com/p/worldwind-vr/source/browse/worldwind-vr-dk2/src/com/tuohy/worldwindvr/input/Xbox360Controller.java

I think the 360 controller was kind of working, but it was the last thing I worked on, so I can't quite recall.

Daniel

On Mon, Jan 11, 2016 at 1:40 PM, ehaensgen < notifications@github.com

wrote:

Daniel, Long time no talk! :-) I don't know if you remember me, but I was curious if you had continued any development with the Oculus and/or WorldWind? I just recently picked this project back up for work and I was finally able to get the java project to run and using the goggles I am trying to wrap my head around how I might be able to separate the Oculus view movement from the keyboard direction keys Basically, I want the goggles to be used to look around but not affect the direction of the movement when the keys are pressed on the keyboard I am an experienced developer, but more in the Visual Studio C# arena and not so much in the OpenGL 3D field Not to mention, it seems you have done quite a bit of work building the code to use the goggles and have a decent understanding of 3D concepts I was hoping you might be able to point me to where in the code you think I can do that

Thanks, Eric

— Reply to this email directly or view it on GitHub https://github.com/danielr2e/worldwind-vr/issues/4.

— Reply to this email directly or view it on GitHub <

https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170665988>

.

---

Eric A. Haensgen

— Reply to this email directly or view it on GitHub <

https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170693857>

.

— Reply to this email directly or view it on GitHub <

https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170702076>

.

---

Eric A. Haensgen

— Reply to this email directly or view it on GitHub <

https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170717419>

.

— Reply to this email directly or view it on GitHub < https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170745699> .

---

Eric A. Haensgen

— Reply to this email directly or view it on GitHub https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170804440 .

[ehaensgen]

I figured out what my issue is. Even though I am creating a second object based on the initial value of the first object, Java has a VERY annoying way of creating the second object as a reference to the first. So, naturally, when the first object changes, so does the second and vice versa. I really hate Java sometimes. ;-)

On Tue, Jan 12, 2016 at 10:09 AM, danielr2e notifications@github.com wrote:

I'm afraid this is about the point where my memory is too fuzzy on the specifics of the WorldWind API.

One tip I can recommend is that if you are in an IDE like eclipse, put a debug point at the line(s) where you are updating the camera/view position. The variable will have a hash code that will let you make sure that the instance you are changing is really the same instance that is being consulted in OculusStereoSceneController during the render (the 'dcView' variable on line 297).

On Tue, Jan 12, 2016 at 12:48 AM, ehaensgen notifications@github.com wrote:

I have been going the route of creating a new instance of a view and initially filling it with the live view. So far it has worked as far as separating out the goggles from the "vehicle". At least as far as the heading of the goggles and the heading of the vehicle view. The problem I am having now is getting the vehicle to move and then updating the goggle view to follow. I can see that the function is getting called, but it does not change the lat/long. If you wouldn't mind, can you take a look at the code below and see if there is something I am missing?

protected void onHorizontalTranslateRel(Angle forwardChange, Angle sideChange, ViewInputAttributes.ActionAttributes actionAttribs) { View view = this.getView(); if (view == null) // include this test to ensure any derived implementation performs it { return; }

if (forwardChange.equals(Angle.ZERO) && sideChange.equals(Angle.ZERO)) { return; }

if (view instanceof BasicFlyView) { Vec4 forward = view.getForwardVector(); Vec4 up = view.getUpVector(); Vec4 side = forward.transformBy3(Matrix.fromAxisAngle(Angle.fromDegrees(90), up));

forward = forward.multiply3(forwardChange.getDegrees()); side = side.multiply3(sideChange.getDegrees()); //Vec4 eyePoint = view.getEyePoint(); Vec4 eyePoint = getCurrentVehiclePoint(vehicle);

// *\ This is properly showing the goggles (main view) and the vehicle headings are different as I move the goggles around System.out.println("Main heading; " + view.getHeading() + " - My heading: " + vehicle.getHeading());

eyePoint = eyePoint.add3(forward.add3(side)); Position newPosition = vehicle.getGlobe().computePositionFromPoint(eyePoint);

//Ignore goggle pitch LatLon latlon = new LatLon(Angle.fromDegrees(newPosition.latitude.degrees), Angle.fromDegrees(newPosition.longitude.degrees)); Position myPos = new Position(latlon, getView().getCurrentEyePosition().getAltitude());

this.setEyePosition(this.uiAnimControl, vehicle, myPos, actionAttribs);

// *\ The above code runs without any errors, but the heading is not updated. I have also tried vehicle.setEyePosition(...), but same issue. System.out.println("head: " + vehicle.getHeading() + ", Pos: "

• vehicle.getEyePosition().latitude.degrees + ":" + vehicle.getEyePosition().longitude.degrees);

this.setEyePosition(this.uiAnimControl, view, vehicle.eyePosition, actionAttribs); view.firePropertyChange(AVKey.VIEW, null, this.vehicle); } }

Thanks, Eric

On Mon, Jan 11, 2016 at 4:52 PM, danielr2e notifications@github.com wrote:

You would have to create a new instance of View to store that data in. Alternatively, you could just create two primitive double variables to store the pitch and heading and bypass View altogether.

On Mon, Jan 11, 2016 at 5:48 PM, ehaensgen notifications@github.com wrote:

Yea, I had pretty much the same thought. I created a View object within the VRFlyViewInputHandler that was a copy of the initial positioning of the main view object and then I feed the new object into the setEyePosition function. However, Java has a very annoying way of making the new object a reference to the existing and so when it changes it changes the main object as well. It is successfully feeding in my VehicleView object, but the goggles are still causing a change in the heading because as the goggles move and update the main view object, the reference to my new object gets updated as well. I am unfortunately not Java savvy enough yet to learn how to create an independent object. :-/

On Mon, Jan 11, 2016 at 1:51 PM, danielr2e <notifications@github.com

wrote:

Ah, OK. If I were doing it, I would just try to find out where the key presses are currently being used to translate the camera position (probably in the fly view handler). Look for uses of the View instance, which gives you access to the position, pitch, roll and heading. Then change that translation logic it so that it doesn't consult the camera's orientation. Instead, you would have a 'hidden' pitch and heading that you consult. Then you would want the left/right keys to update the heading (turning the 'ship' left and right), you'll have to figure out some way to update the pitch, as that's the only way the 'ship' would be able to go up and down.

On Mon, Jan 11, 2016 at 4:23 PM, ehaensgen < notifications@github.com

wrote:

Thank you for the quick response. Essentially what I am attempting to accomplish is making it so that the viewer is, in essence, sitting in a vehicle that moves independently from the direction of the goggles. Sort of like a flight simulator. I want to be able to use the keyboard to move around the environment, but use the goggles strictly for viewing. It would be move like Half-LifeX where while you are in a vehicle you can use the mouse to look around, but driving is done by the keyboard. My thought was to create a "vehicle" class that would extend the BasicView functionality and maintain two separate views and modify the code to get heading/pitch/etc from the "vehicle" view. Sadly, my brain has been in overload since picking this project back up. I was able to use to code you had sent me from google to get the DK2 working and am slowly learning the interface that you had built and the original Java world wind software (which I downloaded but am unable to compile). I have look extensively at the VRFlyView and VRFlyViewInputHandler code. I was finally able to

modify

the onHorizontalTranslateRel function to ignore the pitch of the goggles, but am back at square one with determining how to force it to ignore the heading of the goggles since that it still required, I just need to feed it a different object. Damn 3D crap is so frustrating sometimes. ;-)

Thanks, Eric

On Mon, Jan 11, 2016 at 11:37 AM, danielr2e < notifications@github.com> wrote:

Hi Eric,

You were the guy who got the DK2 code from Google code, right? I still haven't moved that over to github, so that tells you how much I've worked on it :)

I'm actually not experienced with 3D stuff at all, and only got the port working through force of will, so your experience may not be too far off my own. You are in luck, however, that anything involving input will be a lot easier for you to understand than the OpenGL/rendering stuff.

The keyboard behavior is more or less what is built into WorldWind as the 'fly view' controls. There is a custom version of this logic where you could probably modify it to decouple the view from the orientation used for flying around. I'm actually not quite sure what you have in mind, though, because you need some way to control that frame of reference to actually travel in different directions. PC shooters like counter strike have the view locked to the direction of movement for a reason, right? Maybe you could make it so that if you hold the right mouse button, it lets you look around without changing the direction of movement?

Anyway, the class you would want to look at is:

https://code.google.com/p/worldwind-vr/source/browse/worldwind-vr-dk2/src/com/tuohy/worldwindvr/input/VRFlyViewInputHandler.java

If you want to do something similar with the 360 controller (dual analog sticks might give you the flexibility you need!), check out:

https://code.google.com/p/worldwind-vr/source/browse/worldwind-vr-dk2/src/com/tuohy/worldwindvr/input/Xbox360Controller.java

I think the 360 controller was kind of working, but it was the last thing I worked on, so I can't quite recall.

Daniel

On Mon, Jan 11, 2016 at 1:40 PM, ehaensgen < notifications@github.com

wrote:

Daniel, Long time no talk! :-) I don't know if you remember me, but I was curious if you had continued any development with the Oculus and/or WorldWind? I just recently picked this project back up for work and I was finally able to get the java project to run and using the goggles I am trying to wrap my head around how I might be able to separate the Oculus view movement from the keyboard direction keys Basically, I want the goggles to be used to look around but not affect the direction of the movement when the keys are pressed on the keyboard I am an experienced developer, but more in the Visual Studio C# arena and not so much in the OpenGL 3D field Not to mention, it seems you have done quite a bit of work building the code to use the goggles and have a decent understanding of 3D concepts I was hoping you might be able to point me to where in the code you think I can do that

Thanks, Eric

— Reply to this email directly or view it on GitHub https://github.com/danielr2e/worldwind-vr/issues/4.

— Reply to this email directly or view it on GitHub <

https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170665988>

.

---

Eric A. Haensgen

— Reply to this email directly or view it on GitHub <

https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170693857>

.

— Reply to this email directly or view it on GitHub <

https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170702076>

.

---

Eric A. Haensgen

— Reply to this email directly or view it on GitHub <

https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170717419>

.

— Reply to this email directly or view it on GitHub <

https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170745699>

.

---

Eric A. Haensgen

— Reply to this email directly or view it on GitHub < https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170804440>

.

— Reply to this email directly or view it on GitHub https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170998237 .

---

Eric A. Haensgen

[danielr2e]

If it helps, this is a general lesson for most object oriented languages (C++, C#, etc.) that is very important, and excruciating to debug if you haven't learned it. If you didn't specifically allocate a new object (using 'new' in java, it's different in other languages), then all you are getting is a pointer to the existing object.

On Tue, Jan 12, 2016 at 2:01 PM, ehaensgen notifications@github.com wrote:

I figured out what my issue is. Even though I am creating a second object based on the initial value of the first object, Java has a VERY annoying way of creating the second object as a reference to the first. So, naturally, when the first object changes, so does the second and vice versa. I really hate Java sometimes. ;-)

On Tue, Jan 12, 2016 at 10:09 AM, danielr2e notifications@github.com wrote:

I'm afraid this is about the point where my memory is too fuzzy on the specifics of the WorldWind API.

One tip I can recommend is that if you are in an IDE like eclipse, put a debug point at the line(s) where you are updating the camera/view position. The variable will have a hash code that will let you make sure that the instance you are changing is really the same instance that is being consulted in OculusStereoSceneController during the render (the 'dcView' variable on line 297).

On Tue, Jan 12, 2016 at 12:48 AM, ehaensgen notifications@github.com wrote:

I have been going the route of creating a new instance of a view and initially filling it with the live view. So far it has worked as far as separating out the goggles from the "vehicle". At least as far as the heading of the goggles and the heading of the vehicle view. The problem I am having now is getting the vehicle to move and then updating the goggle view to follow. I can see that the function is getting called, but it does not change the lat/long. If you wouldn't mind, can you take a look at the code below and see if there is something I am missing?

protected void onHorizontalTranslateRel(Angle forwardChange, Angle sideChange, ViewInputAttributes.ActionAttributes actionAttribs) { View view = this.getView(); if (view == null) // include this test to ensure any derived implementation performs it { return; }

if (forwardChange.equals(Angle.ZERO) && sideChange.equals(Angle.ZERO)) { return; }

if (view instanceof BasicFlyView) { Vec4 forward = view.getForwardVector(); Vec4 up = view.getUpVector(); Vec4 side = forward.transformBy3(Matrix.fromAxisAngle(Angle.fromDegrees(90), up));

forward = forward.multiply3(forwardChange.getDegrees()); side = side.multiply3(sideChange.getDegrees()); //Vec4 eyePoint = view.getEyePoint(); Vec4 eyePoint = getCurrentVehiclePoint(vehicle);

// *\ This is properly showing the goggles (main view) and the vehicle headings are different as I move the goggles around System.out.println("Main heading; " + view.getHeading() + " - My heading: " + vehicle.getHeading());

eyePoint = eyePoint.add3(forward.add3(side)); Position newPosition = vehicle.getGlobe().computePositionFromPoint(eyePoint);

//Ignore goggle pitch LatLon latlon = new LatLon(Angle.fromDegrees(newPosition.latitude.degrees), Angle.fromDegrees(newPosition.longitude.degrees)); Position myPos = new Position(latlon, getView().getCurrentEyePosition().getAltitude());

this.setEyePosition(this.uiAnimControl, vehicle, myPos, actionAttribs);

// *\ The above code runs without any errors, but the heading is not updated. I have also tried vehicle.setEyePosition(...), but same issue. System.out.println("head: " + vehicle.getHeading() + ", Pos: "

• vehicle.getEyePosition().latitude.degrees + ":" + vehicle.getEyePosition().longitude.degrees);

this.setEyePosition(this.uiAnimControl, view, vehicle.eyePosition, actionAttribs); view.firePropertyChange(AVKey.VIEW, null, this.vehicle); } }

Thanks, Eric

On Mon, Jan 11, 2016 at 4:52 PM, danielr2e notifications@github.com wrote:

You would have to create a new instance of View to store that data in. Alternatively, you could just create two primitive double variables to store the pitch and heading and bypass View altogether.

On Mon, Jan 11, 2016 at 5:48 PM, ehaensgen <notifications@github.com

wrote:

Yea, I had pretty much the same thought. I created a View object within the VRFlyViewInputHandler that was a copy of the initial positioning of the main view object and then I feed the new object into the setEyePosition function. However, Java has a very annoying way of making the new object a reference to the existing and so when it changes it changes the main object as well. It is successfully feeding in my VehicleView object, but the goggles are still causing a change in the heading because as the goggles move and update the main view object, the reference to my new object gets updated as well. I am unfortunately not Java savvy enough yet to learn how to create an independent object. :-/

On Mon, Jan 11, 2016 at 1:51 PM, danielr2e < notifications@github.com

wrote:

Ah, OK. If I were doing it, I would just try to find out where the key presses are currently being used to translate the camera position (probably in the fly view handler). Look for uses of the View instance, which gives you access to the position, pitch, roll and heading. Then change that translation logic it so that it doesn't consult the camera's orientation. Instead, you would have a 'hidden' pitch and heading that you consult. Then you would want the left/right keys to update the heading (turning the 'ship' left and right), you'll have to figure out some way to update the pitch, as that's the only way the 'ship' would be able to go up and down.

On Mon, Jan 11, 2016 at 4:23 PM, ehaensgen < notifications@github.com

wrote:

Thank you for the quick response. Essentially what I am attempting to accomplish is making it so that the viewer is, in essence, sitting in a vehicle that moves independently from the direction of the goggles. Sort of like a flight simulator. I want to be able to use the keyboard to move around the environment, but use the goggles strictly for viewing. It would be move like Half-LifeX where while you are in a vehicle you can use the mouse to look around, but driving is done by the keyboard. My thought was to create a "vehicle" class that would extend the BasicView functionality and maintain two separate views and modify the code to get heading/pitch/etc from the "vehicle" view. Sadly, my brain has been in overload since picking this project back up. I was able to use to code you had sent me from google to get the DK2 working and am slowly learning the interface that you had built and the original Java world wind software (which I downloaded but am unable to compile). I have look extensively at the VRFlyView and VRFlyViewInputHandler code. I was finally able to

modify

the onHorizontalTranslateRel function to ignore the pitch of the goggles, but am back at square one with determining how to force it to ignore the heading of the goggles since that it still required, I just need to feed it a different object. Damn 3D crap is so frustrating sometimes. ;-)

Thanks, Eric

On Mon, Jan 11, 2016 at 11:37 AM, danielr2e < notifications@github.com> wrote:

Hi Eric,

You were the guy who got the DK2 code from Google code, right? I still haven't moved that over to github, so that tells you how much I've worked on it :)

I'm actually not experienced with 3D stuff at all, and only got the port working through force of will, so your experience may not be too far off my own. You are in luck, however, that anything involving input will be a lot easier for you to understand than the OpenGL/rendering stuff.

The keyboard behavior is more or less what is built into WorldWind as the 'fly view' controls. There is a custom version of this logic where you could probably modify it to decouple the view from the orientation used for flying around. I'm actually not quite sure what you have in mind, though, because you need some way to control that frame of reference to actually travel in different directions. PC shooters like counter strike have the view locked to the direction of movement for a reason, right? Maybe you could make it so that if you hold the right mouse button, it lets you look around without changing the direction of movement?

Anyway, the class you would want to look at is:

https://code.google.com/p/worldwind-vr/source/browse/worldwind-vr-dk2/src/com/tuohy/worldwindvr/input/VRFlyViewInputHandler.java

If you want to do something similar with the 360 controller (dual analog sticks might give you the flexibility you need!), check out:

https://code.google.com/p/worldwind-vr/source/browse/worldwind-vr-dk2/src/com/tuohy/worldwindvr/input/Xbox360Controller.java

I think the 360 controller was kind of working, but it was the last thing I worked on, so I can't quite recall.

Daniel

On Mon, Jan 11, 2016 at 1:40 PM, ehaensgen < notifications@github.com

wrote:

Daniel, Long time no talk! :-) I don't know if you remember me, but I was curious if you had continued any development with the Oculus and/or WorldWind? I just recently picked this project back up for work and I was finally able to get the java project to run and using the goggles I am trying to wrap my head around how I might be able to separate the Oculus view movement from the keyboard direction keys Basically, I want the goggles to be used to look around but not affect the direction of the movement when the keys are pressed on the keyboard I am an experienced developer, but more in the Visual Studio C# arena and not so much in the OpenGL 3D field Not to mention, it seems you have done quite a bit of work building the code to use the goggles and have a decent understanding of 3D concepts I was hoping you might be able to point me to where in the code you think I can do that

Thanks, Eric

— Reply to this email directly or view it on GitHub https://github.com/danielr2e/worldwind-vr/issues/4.

— Reply to this email directly or view it on GitHub <

https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170665988>

.

---

Eric A. Haensgen

— Reply to this email directly or view it on GitHub <

https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170693857>

.

— Reply to this email directly or view it on GitHub <

https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170702076>

.

---

Eric A. Haensgen

— Reply to this email directly or view it on GitHub <

https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170717419>

.

— Reply to this email directly or view it on GitHub <

https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170745699>

.

---

Eric A. Haensgen

— Reply to this email directly or view it on GitHub <

https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170804440>

.

— Reply to this email directly or view it on GitHub < https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170998237> .

---

Eric A. Haensgen

— Reply to this email directly or view it on GitHub https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-171016447 .

[ehaensgen]

Unfortunately they do not allow you to execute View vehicle = new View(); (it has no constructor). Plus, I need vehicle to be a copy of the original in the since that they both start in the same place, but take very different paths from there. I have tried copying just the necessities, but that is apparently not enough when it comes time to setEyePosition. I am getting very frustrated. I am not certain how to proceed. I have tried your idea of just grabbing the heading and all, but I have a feeling that since there is a "smoothing" affect, which makes it flow rather than jump, it is constantly getting the most current heading regardless of what I set it to before calling the function. >-(

On Tue, Jan 12, 2016 at 11:18 AM, danielr2e notifications@github.com wrote:

If it helps, this is a general lesson for most object oriented languages (C++, C#, etc.) that is very important, and excruciating to debug if you haven't learned it. If you didn't specifically allocate a new object (using 'new' in java, it's different in other languages), then all you are getting is a pointer to the existing object.

On Tue, Jan 12, 2016 at 2:01 PM, ehaensgen notifications@github.com wrote:

I figured out what my issue is. Even though I am creating a second object based on the initial value of the first object, Java has a VERY annoying way of creating the second object as a reference to the first. So, naturally, when the first object changes, so does the second and vice versa. I really hate Java sometimes. ;-)

On Tue, Jan 12, 2016 at 10:09 AM, danielr2e notifications@github.com wrote:

I'm afraid this is about the point where my memory is too fuzzy on the specifics of the WorldWind API.

One tip I can recommend is that if you are in an IDE like eclipse, put a debug point at the line(s) where you are updating the camera/view position. The variable will have a hash code that will let you make sure that the instance you are changing is really the same instance that is being consulted in OculusStereoSceneController during the render (the 'dcView' variable on line 297).

On Tue, Jan 12, 2016 at 12:48 AM, ehaensgen notifications@github.com wrote:

I have been going the route of creating a new instance of a view and initially filling it with the live view. So far it has worked as far as separating out the goggles from the "vehicle". At least as far as the heading of the goggles and the heading of the vehicle view. The problem I am having now is getting the vehicle to move and then updating the goggle view to follow. I can see that the function is getting called, but it does not change the lat/long. If you wouldn't mind, can you take a look at the code below and see if there is something I am missing?

protected void onHorizontalTranslateRel(Angle forwardChange, Angle sideChange, ViewInputAttributes.ActionAttributes actionAttribs) { View view = this.getView(); if (view == null) // include this test to ensure any derived implementation performs it { return; }

if (forwardChange.equals(Angle.ZERO) && sideChange.equals(Angle.ZERO)) { return; }

if (view instanceof BasicFlyView) { Vec4 forward = view.getForwardVector(); Vec4 up = view.getUpVector(); Vec4 side = forward.transformBy3(Matrix.fromAxisAngle(Angle.fromDegrees(90), up));

forward = forward.multiply3(forwardChange.getDegrees()); side = side.multiply3(sideChange.getDegrees()); //Vec4 eyePoint = view.getEyePoint(); Vec4 eyePoint = getCurrentVehiclePoint(vehicle);

// *\ This is properly showing the goggles (main view) and the vehicle headings are different as I move the goggles around System.out.println("Main heading; " + view.getHeading() + " - My heading: " + vehicle.getHeading());

eyePoint = eyePoint.add3(forward.add3(side)); Position newPosition = vehicle.getGlobe().computePositionFromPoint(eyePoint);

//Ignore goggle pitch LatLon latlon = new LatLon(Angle.fromDegrees(newPosition.latitude.degrees), Angle.fromDegrees(newPosition.longitude.degrees)); Position myPos = new Position(latlon, getView().getCurrentEyePosition().getAltitude());

this.setEyePosition(this.uiAnimControl, vehicle, myPos, actionAttribs);

// *\ The above code runs without any errors, but the heading is not updated. I have also tried vehicle.setEyePosition(...), but same issue. System.out.println("head: " + vehicle.getHeading() + ", Pos: "

• vehicle.getEyePosition().latitude.degrees + ":" + vehicle.getEyePosition().longitude.degrees);

this.setEyePosition(this.uiAnimControl, view, vehicle.eyePosition, actionAttribs); view.firePropertyChange(AVKey.VIEW, null, this.vehicle); } }

Thanks, Eric

On Mon, Jan 11, 2016 at 4:52 PM, danielr2e <notifications@github.com

wrote:

You would have to create a new instance of View to store that data in. Alternatively, you could just create two primitive double variables to store the pitch and heading and bypass View altogether.

On Mon, Jan 11, 2016 at 5:48 PM, ehaensgen < notifications@github.com

wrote:

Yea, I had pretty much the same thought. I created a View object within the VRFlyViewInputHandler that was a copy of the initial positioning of the main view object and then I feed the new object into the setEyePosition function. However, Java has a very annoying way of making the new object a reference to the existing and so when it changes it changes the main object as well. It is successfully feeding in my VehicleView object, but the goggles are still causing a change in the heading because as the goggles move and update the main view object, the reference to my new object gets updated as well. I am unfortunately not Java savvy enough yet to learn how to create an independent object. :-/

On Mon, Jan 11, 2016 at 1:51 PM, danielr2e < notifications@github.com

wrote:

Ah, OK. If I were doing it, I would just try to find out where the key presses are currently being used to translate the camera position (probably in the fly view handler). Look for uses of the View instance, which gives you access to the position, pitch, roll and heading. Then change that translation logic it so that it doesn't consult the camera's orientation. Instead, you would have a 'hidden' pitch and heading that you consult. Then you would want the left/right keys to update the heading (turning the 'ship' left and right), you'll have to figure out some way to update the pitch, as that's the only way the 'ship' would be able to go up and down.

On Mon, Jan 11, 2016 at 4:23 PM, ehaensgen < notifications@github.com

wrote:

Thank you for the quick response. Essentially what I am attempting to accomplish is making it so that the viewer is, in essence, sitting in a vehicle that moves independently from the direction of the goggles. Sort of like a flight simulator. I want to be able to use the keyboard to move around the environment, but use the goggles strictly for viewing. It would be move like Half-LifeX where while you are in a vehicle you can use the mouse to look around, but driving is done by the keyboard. My thought was to create a "vehicle" class that would extend the BasicView functionality and maintain two separate views and modify the code to get heading/pitch/etc from the "vehicle" view. Sadly, my brain has been in overload since picking this project back up. I was able to use to code you had sent me from google to get the DK2 working and am slowly learning the interface that you had built and the original Java world wind software (which I downloaded but am unable to compile). I have look extensively at the VRFlyView and VRFlyViewInputHandler code. I was finally able to

modify

the onHorizontalTranslateRel function to ignore the pitch of the goggles, but am back at square one with determining how to force it to ignore the heading of the goggles since that it still required, I just need to feed it a different object. Damn 3D crap is so frustrating sometimes. ;-)

Thanks, Eric

On Mon, Jan 11, 2016 at 11:37 AM, danielr2e < notifications@github.com> wrote:

Hi Eric,

You were the guy who got the DK2 code from Google code, right? I still haven't moved that over to github, so that tells you how much I've worked on it :)

I'm actually not experienced with 3D stuff at all, and only got the port working through force of will, so your experience may not be too far off my own. You are in luck, however, that anything involving input will be a lot easier for you to understand than the OpenGL/rendering stuff.

The keyboard behavior is more or less what is built into WorldWind as the 'fly view' controls. There is a custom version of this logic where you could probably modify it to decouple the view from the orientation used for flying around. I'm actually not quite sure what you have in mind, though, because you need some way to control that frame of reference to actually travel in different directions. PC shooters like counter strike have the view locked to the direction of movement for a reason, right? Maybe you could make it so that if you hold the right mouse button, it lets you look around without changing the direction of movement?

Anyway, the class you would want to look at is:

https://code.google.com/p/worldwind-vr/source/browse/worldwind-vr-dk2/src/com/tuohy/worldwindvr/input/VRFlyViewInputHandler.java

If you want to do something similar with the 360 controller (dual analog sticks might give you the flexibility you need!), check out:

https://code.google.com/p/worldwind-vr/source/browse/worldwind-vr-dk2/src/com/tuohy/worldwindvr/input/Xbox360Controller.java

I think the 360 controller was kind of working, but it was the last thing I worked on, so I can't quite recall.

Daniel

On Mon, Jan 11, 2016 at 1:40 PM, ehaensgen < notifications@github.com

wrote:

Daniel, Long time no talk! :-) I don't know if you remember me, but I was curious if you had continued any development with the Oculus and/or WorldWind? I just recently picked this project back up for work and I was finally able to get the java project to run and using the goggles I am trying to wrap my head around how I might be able to separate the Oculus view movement from the keyboard direction keys Basically, I want the goggles to be used to look around but not affect the direction of the movement when the keys are pressed on the keyboard I am an experienced developer, but more in the Visual Studio C# arena and not so much in the OpenGL 3D field Not to mention, it seems you have done quite a bit of work building the code to use the goggles and have a decent understanding of 3D concepts I was hoping you might be able to point me to where in the code you think I can do that

Thanks, Eric

— Reply to this email directly or view it on GitHub https://github.com/danielr2e/worldwind-vr/issues/4.

— Reply to this email directly or view it on GitHub <

https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170665988>

.

---

Eric A. Haensgen

— Reply to this email directly or view it on GitHub <

https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170693857>

.

— Reply to this email directly or view it on GitHub <

https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170702076>

.

---

Eric A. Haensgen

— Reply to this email directly or view it on GitHub <

https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170717419>

.

— Reply to this email directly or view it on GitHub <

https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170745699>

.

---

Eric A. Haensgen

— Reply to this email directly or view it on GitHub <

https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170804440>

.

— Reply to this email directly or view it on GitHub <

https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170998237>

.

---

Eric A. Haensgen

— Reply to this email directly or view it on GitHub < https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-171016447>

.

— Reply to this email directly or view it on GitHub https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-171021765 .

---

Eric A. Haensgen

[ehaensgen]

Just out of curiosity, do you remember what version of the world wind software you used? I finally was able to compile the version that I have, but the first thing I noticed was that the file size was 2MB less than the one included in your original project. Also, now when I try to run I get a bunch of errors. Hopefully you remember, if not I will figure it out. :-)

On Tue, Jan 12, 2016 at 1:30 PM, Eric Haensgen programgod@gmail.com wrote:

Unfortunately they do not allow you to execute View vehicle = new View(); (it has no constructor). Plus, I need vehicle to be a copy of the original in the since that they both start in the same place, but take very different paths from there. I have tried copying just the necessities, but that is apparently not enough when it comes time to setEyePosition. I am getting very frustrated. I am not certain how to proceed. I have tried your idea of just grabbing the heading and all, but I have a feeling that since there is a "smoothing" affect, which makes it flow rather than jump, it is constantly getting the most current heading regardless of what I set it to before calling the function. >-(

On Tue, Jan 12, 2016 at 11:18 AM, danielr2e notifications@github.com wrote:

If it helps, this is a general lesson for most object oriented languages (C++, C#, etc.) that is very important, and excruciating to debug if you haven't learned it. If you didn't specifically allocate a new object (using 'new' in java, it's different in other languages), then all you are getting is a pointer to the existing object.

On Tue, Jan 12, 2016 at 2:01 PM, ehaensgen notifications@github.com wrote:

I figured out what my issue is. Even though I am creating a second object based on the initial value of the first object, Java has a VERY annoying way of creating the second object as a reference to the first. So, naturally, when the first object changes, so does the second and vice versa. I really hate Java sometimes. ;-)

On Tue, Jan 12, 2016 at 10:09 AM, danielr2e notifications@github.com wrote:

I'm afraid this is about the point where my memory is too fuzzy on the specifics of the WorldWind API.

One tip I can recommend is that if you are in an IDE like eclipse, put a debug point at the line(s) where you are updating the camera/view position. The variable will have a hash code that will let you make sure that the instance you are changing is really the same instance that is being consulted in OculusStereoSceneController during the render (the 'dcView' variable on line 297).

On Tue, Jan 12, 2016 at 12:48 AM, ehaensgen <notifications@github.com

wrote:

I have been going the route of creating a new instance of a view and initially filling it with the live view. So far it has worked as far as separating out the goggles from the "vehicle". At least as far as the heading of the goggles and the heading of the vehicle view. The problem I am having now is getting the vehicle to move and then updating the goggle view to follow. I can see that the function is getting called, but it does not change the lat/long. If you wouldn't mind, can you take a look at the code below and see if there is something I am missing?

protected void onHorizontalTranslateRel(Angle forwardChange, Angle sideChange, ViewInputAttributes.ActionAttributes actionAttribs) { View view = this.getView(); if (view == null) // include this test to ensure any derived implementation performs it { return; }

if (forwardChange.equals(Angle.ZERO) && sideChange.equals(Angle.ZERO)) { return; }

if (view instanceof BasicFlyView) { Vec4 forward = view.getForwardVector(); Vec4 up = view.getUpVector(); Vec4 side = forward.transformBy3(Matrix.fromAxisAngle(Angle.fromDegrees(90), up));

forward = forward.multiply3(forwardChange.getDegrees()); side = side.multiply3(sideChange.getDegrees()); //Vec4 eyePoint = view.getEyePoint(); Vec4 eyePoint = getCurrentVehiclePoint(vehicle);

// *\ This is properly showing the goggles (main view) and the vehicle headings are different as I move the goggles around System.out.println("Main heading; " + view.getHeading() + " - My heading: " + vehicle.getHeading());

eyePoint = eyePoint.add3(forward.add3(side)); Position newPosition = vehicle.getGlobe().computePositionFromPoint(eyePoint);

//Ignore goggle pitch LatLon latlon = new LatLon(Angle.fromDegrees(newPosition.latitude.degrees), Angle.fromDegrees(newPosition.longitude.degrees)); Position myPos = new Position(latlon, getView().getCurrentEyePosition().getAltitude());

this.setEyePosition(this.uiAnimControl, vehicle, myPos, actionAttribs);

// *\ The above code runs without any errors, but the heading is not updated. I have also tried vehicle.setEyePosition(...), but same issue. System.out.println("head: " + vehicle.getHeading() + ", Pos: "

• vehicle.getEyePosition().latitude.degrees + ":" + vehicle.getEyePosition().longitude.degrees);

this.setEyePosition(this.uiAnimControl, view, vehicle.eyePosition, actionAttribs); view.firePropertyChange(AVKey.VIEW, null, this.vehicle); } }

Thanks, Eric

On Mon, Jan 11, 2016 at 4:52 PM, danielr2e < notifications@github.com> wrote:

You would have to create a new instance of View to store that data in. Alternatively, you could just create two primitive double variables to store the pitch and heading and bypass View altogether.

On Mon, Jan 11, 2016 at 5:48 PM, ehaensgen < notifications@github.com

wrote:

Yea, I had pretty much the same thought. I created a View object within the VRFlyViewInputHandler that was a copy of the initial positioning of the main view object and then I feed the new object into the setEyePosition function. However, Java has a very annoying way of making the new object a reference to the existing and so when it changes it changes the main object as well. It is successfully feeding in my VehicleView object, but the goggles are still causing a change in the heading because as the goggles move and update the main view object, the reference to my new object gets updated as well. I am unfortunately not Java savvy enough yet to learn how to create an independent object. :-/

On Mon, Jan 11, 2016 at 1:51 PM, danielr2e < notifications@github.com

wrote:

Ah, OK. If I were doing it, I would just try to find out where the key presses are currently being used to translate the camera position (probably in the fly view handler). Look for uses of the View instance, which gives you access to the position, pitch, roll and heading. Then change that translation logic it so that it doesn't consult the camera's orientation. Instead, you would have a 'hidden' pitch and heading that you consult. Then you would want the left/right keys to update the heading (turning the 'ship' left and right), you'll have to figure out some way to update the pitch, as that's the only way the 'ship' would be able to go up and down.

On Mon, Jan 11, 2016 at 4:23 PM, ehaensgen < notifications@github.com

wrote:

Thank you for the quick response. Essentially what I am attempting to accomplish is making it so that the viewer is, in essence, sitting in a vehicle that moves independently from the direction of the goggles. Sort of like a flight simulator. I want to be able to use the keyboard to move around the environment, but use the goggles strictly for viewing. It would be move like Half-LifeX where while you are in a vehicle you can use the mouse to look around, but driving is done by the keyboard. My thought was to create a "vehicle" class that would extend the BasicView functionality and maintain two separate views and modify the code to get heading/pitch/etc from the "vehicle" view. Sadly, my brain has been in overload since picking this project back up. I was able to use to code you had sent me from google to get the DK2 working and am slowly learning the interface that you had built and the original Java world wind software (which I downloaded but am unable to compile). I have look extensively at the VRFlyView and VRFlyViewInputHandler code. I was finally able to

modify

the onHorizontalTranslateRel function to ignore the pitch of the goggles, but am back at square one with determining how to force it to ignore the heading of the goggles since that it still required, I just need to feed it a different object. Damn 3D crap is so frustrating sometimes. ;-)

Thanks, Eric

On Mon, Jan 11, 2016 at 11:37 AM, danielr2e < notifications@github.com> wrote:

Hi Eric,

You were the guy who got the DK2 code from Google code, right? I still haven't moved that over to github, so that tells you how much I've worked on it :)

I'm actually not experienced with 3D stuff at all, and only got the port working through force of will, so your experience may not be too far off my own. You are in luck, however, that anything involving input will be a lot easier for you to understand than the OpenGL/rendering stuff.

The keyboard behavior is more or less what is built into WorldWind as the 'fly view' controls. There is a custom version of this logic where you could probably modify it to decouple the view from the orientation used for flying around. I'm actually not quite sure what you have in mind, though, because you need some way to control that frame of reference to actually travel in different directions. PC shooters like counter strike have the view locked to the direction of movement for a reason, right? Maybe you could make it so that if you hold the right mouse button, it lets you look around without changing the direction of movement?

Anyway, the class you would want to look at is:

https://code.google.com/p/worldwind-vr/source/browse/worldwind-vr-dk2/src/com/tuohy/worldwindvr/input/VRFlyViewInputHandler.java

If you want to do something similar with the 360 controller (dual analog sticks might give you the flexibility you need!), check out:

https://code.google.com/p/worldwind-vr/source/browse/worldwind-vr-dk2/src/com/tuohy/worldwindvr/input/Xbox360Controller.java

I think the 360 controller was kind of working, but it was the last thing I worked on, so I can't quite recall.

Daniel

On Mon, Jan 11, 2016 at 1:40 PM, ehaensgen < notifications@github.com

wrote:

Daniel, Long time no talk! :-) I don't know if you remember me, but I was curious if you had continued any development with the Oculus and/or WorldWind? I just recently picked this project back up for work and I was finally able to get the java project to run and using the goggles I am trying to wrap my head around how I might be able to separate the Oculus view movement from the keyboard direction keys Basically, I want the goggles to be used to look around but not affect the direction of the movement when the keys are pressed on the keyboard I am an experienced developer, but more in the Visual Studio C# arena and not so much in the OpenGL 3D field Not to mention, it seems you have done quite a bit of work building the code to use the goggles and have a decent understanding of 3D concepts I was hoping you might be able to point me to where in the code you think I can do that

Thanks, Eric

— Reply to this email directly or view it on GitHub https://github.com/danielr2e/worldwind-vr/issues/4.

— Reply to this email directly or view it on GitHub <

https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170665988

.

---

Eric A. Haensgen

— Reply to this email directly or view it on GitHub <

https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170693857

.

— Reply to this email directly or view it on GitHub <

https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170702076

.

---

Eric A. Haensgen

— Reply to this email directly or view it on GitHub <

https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170717419

.

— Reply to this email directly or view it on GitHub <

https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170745699

.

---

Eric A. Haensgen

— Reply to this email directly or view it on GitHub <

https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170804440

.

— Reply to this email directly or view it on GitHub <

https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170998237

.

---

Eric A. Haensgen

— Reply to this email directly or view it on GitHub < https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-171016447

.

— Reply to this email directly or view it on GitHub https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-171021765 .

---

Eric A. Haensgen

---

Eric A. Haensgen

[danielr2e]

My recollection is that when I moved to DK2 I got either the 'last stable build' or maybe even 'daily build' from the WorldWind website. I can't remember why I did this, it might have had something to do with OpenGL. In any case, I would be surprised if your version of WorldWind didn't work.

On Tue, Jan 12, 2016 at 6:12 PM, ehaensgen notifications@github.com wrote:

Just out of curiosity, do you remember what version of the world wind software you used? I finally was able to compile the version that I have, but the first thing I noticed was that the file size was 2MB less than the one included in your original project. Also, now when I try to run I get a bunch of errors. Hopefully you remember, if not I will figure it out. :-)

On Tue, Jan 12, 2016 at 1:30 PM, Eric Haensgen programgod@gmail.com wrote:

Unfortunately they do not allow you to execute View vehicle = new View(); (it has no constructor). Plus, I need vehicle to be a copy of the original in the since that they both start in the same place, but take very different paths from there. I have tried copying just the necessities, but that is apparently not enough when it comes time to setEyePosition. I am getting very frustrated. I am not certain how to proceed. I have tried your idea of just grabbing the heading and all, but I have a feeling that since there is a "smoothing" affect, which makes it flow rather than jump, it is constantly getting the most current heading regardless of what I set it to before calling the function. >-(

On Tue, Jan 12, 2016 at 11:18 AM, danielr2e notifications@github.com wrote:

If it helps, this is a general lesson for most object oriented languages (C++, C#, etc.) that is very important, and excruciating to debug if you haven't learned it. If you didn't specifically allocate a new object (using 'new' in java, it's different in other languages), then all you are getting is a pointer to the existing object.

On Tue, Jan 12, 2016 at 2:01 PM, ehaensgen notifications@github.com wrote:

I figured out what my issue is. Even though I am creating a second object based on the initial value of the first object, Java has a VERY annoying way of creating the second object as a reference to the first. So, naturally, when the first object changes, so does the second and vice versa. I really hate Java sometimes. ;-)

On Tue, Jan 12, 2016 at 10:09 AM, danielr2e <notifications@github.com

wrote:

I'm afraid this is about the point where my memory is too fuzzy on the specifics of the WorldWind API.

One tip I can recommend is that if you are in an IDE like eclipse, put a debug point at the line(s) where you are updating the camera/view position. The variable will have a hash code that will let you make sure that the instance you are changing is really the same instance that is being consulted in OculusStereoSceneController during the render (the 'dcView' variable on line 297).

On Tue, Jan 12, 2016 at 12:48 AM, ehaensgen < notifications@github.com

wrote:

I have been going the route of creating a new instance of a view and initially filling it with the live view. So far it has worked as far as separating out the goggles from the "vehicle". At least as far as the heading of the goggles and the heading of the vehicle view. The problem I am having now is getting the vehicle to move and then updating the goggle view to follow. I can see that the function is getting called, but it does not change the lat/long. If you wouldn't mind, can you take a look at the code below and see if there is something I am missing?

protected void onHorizontalTranslateRel(Angle forwardChange, Angle sideChange, ViewInputAttributes.ActionAttributes actionAttribs) { View view = this.getView(); if (view == null) // include this test to ensure any derived implementation performs it { return; }

if (forwardChange.equals(Angle.ZERO) && sideChange.equals(Angle.ZERO)) { return; }

if (view instanceof BasicFlyView) { Vec4 forward = view.getForwardVector(); Vec4 up = view.getUpVector(); Vec4 side = forward.transformBy3(Matrix.fromAxisAngle(Angle.fromDegrees(90), up));

forward = forward.multiply3(forwardChange.getDegrees()); side = side.multiply3(sideChange.getDegrees()); //Vec4 eyePoint = view.getEyePoint(); Vec4 eyePoint = getCurrentVehiclePoint(vehicle);

// *\ This is properly showing the goggles (main view) and the vehicle headings are different as I move the goggles around System.out.println("Main heading; " + view.getHeading() + " - My heading: " + vehicle.getHeading());

eyePoint = eyePoint.add3(forward.add3(side)); Position newPosition = vehicle.getGlobe().computePositionFromPoint(eyePoint);

//Ignore goggle pitch LatLon latlon = new LatLon(Angle.fromDegrees(newPosition.latitude.degrees), Angle.fromDegrees(newPosition.longitude.degrees)); Position myPos = new Position(latlon, getView().getCurrentEyePosition().getAltitude());

this.setEyePosition(this.uiAnimControl, vehicle, myPos, actionAttribs);

// *\ The above code runs without any errors, but the heading is not updated. I have also tried vehicle.setEyePosition(...), but same issue. System.out.println("head: " + vehicle.getHeading() + ", Pos: "

• vehicle.getEyePosition().latitude.degrees + ":" + vehicle.getEyePosition().longitude.degrees);

this.setEyePosition(this.uiAnimControl, view, vehicle.eyePosition, actionAttribs); view.firePropertyChange(AVKey.VIEW, null, this.vehicle); } }

Thanks, Eric

On Mon, Jan 11, 2016 at 4:52 PM, danielr2e < notifications@github.com> wrote:

You would have to create a new instance of View to store that data in. Alternatively, you could just create two primitive double variables to store the pitch and heading and bypass View altogether.

On Mon, Jan 11, 2016 at 5:48 PM, ehaensgen < notifications@github.com

wrote:

Yea, I had pretty much the same thought. I created a View object within the VRFlyViewInputHandler that was a copy of the initial positioning of the main view object and then I feed the new object into the setEyePosition function. However, Java has a very annoying way of making the new object a reference to the existing and so when it changes it changes the main object as well. It is successfully feeding in my VehicleView object, but the goggles are still causing a change in the heading because as the goggles move and update the main view object, the reference to my new object gets updated as well. I am unfortunately not Java savvy enough yet to learn how to create an independent object. :-/

On Mon, Jan 11, 2016 at 1:51 PM, danielr2e < notifications@github.com

wrote:

Ah, OK. If I were doing it, I would just try to find out where the key presses are currently being used to translate the camera position (probably in the fly view handler). Look for uses of the View instance, which gives you access to the position, pitch, roll and heading. Then change that translation logic it so that it doesn't consult the camera's orientation. Instead, you would have a 'hidden' pitch and heading that you consult. Then you would want the left/right keys to update the heading (turning the 'ship' left and right), you'll have to figure out some way to update the pitch, as that's the only way the 'ship' would be able to go up and down.

On Mon, Jan 11, 2016 at 4:23 PM, ehaensgen < notifications@github.com

wrote:

Thank you for the quick response. Essentially what I am attempting to accomplish is making it so that the viewer is, in essence, sitting in a vehicle that moves independently from the direction of the goggles. Sort of like a flight simulator. I want to be able to use the keyboard to move around the environment, but use the goggles strictly for viewing. It would be move like Half-LifeX where while you are in a vehicle you can use the mouse to look around, but driving is done by the keyboard. My thought was to create a "vehicle" class that would extend the BasicView functionality and maintain two separate views and modify the code to get heading/pitch/etc from the "vehicle" view. Sadly, my brain has been in overload since picking this project back up. I was able to use to code you had sent me from google to get the DK2 working and am slowly learning the interface that you had built and the original Java world wind software (which I downloaded but am unable to compile). I have look extensively at the VRFlyView and VRFlyViewInputHandler code. I was finally able to

modify

the onHorizontalTranslateRel function to ignore the pitch of the goggles, but am back at square one with determining how to force it to ignore the heading of the goggles since that it still required, I just need to feed it a different object. Damn 3D crap is so frustrating sometimes. ;-)

Thanks, Eric

On Mon, Jan 11, 2016 at 11:37 AM, danielr2e < notifications@github.com> wrote:

Hi Eric,

You were the guy who got the DK2 code from Google code, right? I still haven't moved that over to github, so that tells you how much I've worked on it :)

I'm actually not experienced with 3D stuff at all, and only got the port working through force of will, so your experience may not be too far off my own. You are in luck, however, that anything involving input will be a lot easier for you to understand than the OpenGL/rendering stuff.

The keyboard behavior is more or less what is built into WorldWind as the 'fly view' controls. There is a custom version of this logic where you could probably modify it to decouple the view from the orientation used for flying around. I'm actually not quite sure what you have in mind, though, because you need some way to control that frame of reference to actually travel in different directions. PC shooters like counter strike have the view locked to the direction of movement for a reason, right? Maybe you could make it so that if you hold the right mouse button, it lets you look around without changing the direction of movement?

Anyway, the class you would want to look at is:

https://code.google.com/p/worldwind-vr/source/browse/worldwind-vr-dk2/src/com/tuohy/worldwindvr/input/VRFlyViewInputHandler.java

If you want to do something similar with the 360 controller (dual analog sticks might give you the flexibility you need!), check out:

https://code.google.com/p/worldwind-vr/source/browse/worldwind-vr-dk2/src/com/tuohy/worldwindvr/input/Xbox360Controller.java

I think the 360 controller was kind of working, but it was the last thing I worked on, so I can't quite recall.

Daniel

On Mon, Jan 11, 2016 at 1:40 PM, ehaensgen < notifications@github.com

wrote:

Daniel, Long time no talk! :-) I don't know if you remember me, but I was curious if you had continued any development with the Oculus and/or WorldWind? I just recently picked this project back up for work and I was finally able to get the java project to run and using the goggles I am trying to wrap my head around how I might be able to separate the Oculus view movement from the keyboard direction keys Basically, I want the goggles to be used to look around but not affect the direction of the movement when the keys are pressed on the keyboard I am an experienced developer, but more in the Visual Studio C# arena and not so much in the OpenGL 3D field Not to mention, it seems you have done quite a bit of work building the code to use the goggles and have a decent understanding of 3D concepts I was hoping you might be able to point me to where in the code you think I can do that

Thanks, Eric

— Reply to this email directly or view it on GitHub https://github.com/danielr2e/worldwind-vr/issues/4.

— Reply to this email directly or view it on GitHub <

https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170665988

.

---

Eric A. Haensgen

— Reply to this email directly or view it on GitHub <

https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170693857

.

— Reply to this email directly or view it on GitHub <

https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170702076

.

---

Eric A. Haensgen

— Reply to this email directly or view it on GitHub <

https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170717419

.

— Reply to this email directly or view it on GitHub <

https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170745699

.

---

Eric A. Haensgen

— Reply to this email directly or view it on GitHub <

https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170804440

.

— Reply to this email directly or view it on GitHub <

https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170998237

.

---

Eric A. Haensgen

— Reply to this email directly or view it on GitHub <

https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-171016447

.

— Reply to this email directly or view it on GitHub < https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-171021765> .

---

Eric A. Haensgen

---

Eric A. Haensgen

— Reply to this email directly or view it on GitHub https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-171093574 .

[ehaensgen]

It didn't, but I have a feeling that because at the time I downloaded months ago I just randomly chose the first one I found that I might have downloaded a half-a$$'d version of it. I should have the latest and greatest, and as long as they didn't deprecate anything it should work. I am going to see if I can update the world wind software to include a "clone" function in the hopes that I can either clone or deep copy the view. I appreciate you taking the time in trying to assist me with this and I apologize that I have taken so much of it. I will let you know how it turns out.

Thanks, Eric

On Tue, Jan 12, 2016 at 3:38 PM, danielr2e notifications@github.com wrote:

My recollection is that when I moved to DK2 I got either the 'last stable build' or maybe even 'daily build' from the WorldWind website. I can't remember why I did this, it might have had something to do with OpenGL. In any case, I would be surprised if your version of WorldWind didn't work.

On Tue, Jan 12, 2016 at 6:12 PM, ehaensgen notifications@github.com wrote:

Just out of curiosity, do you remember what version of the world wind software you used? I finally was able to compile the version that I have, but the first thing I noticed was that the file size was 2MB less than the one included in your original project. Also, now when I try to run I get a bunch of errors. Hopefully you remember, if not I will figure it out. :-)

On Tue, Jan 12, 2016 at 1:30 PM, Eric Haensgen programgod@gmail.com wrote:

Unfortunately they do not allow you to execute View vehicle = new View(); (it has no constructor). Plus, I need vehicle to be a copy of the original in the since that they both start in the same place, but take very different paths from there. I have tried copying just the necessities, but that is apparently not enough when it comes time to setEyePosition. I am getting very frustrated. I am not certain how to proceed. I have tried your idea of just grabbing the heading and all, but I have a feeling that since there is a "smoothing" affect, which makes it flow rather than jump, it is constantly getting the most current heading regardless of what I set it to before calling the function. >-(

On Tue, Jan 12, 2016 at 11:18 AM, danielr2e notifications@github.com wrote:

If it helps, this is a general lesson for most object oriented languages (C++, C#, etc.) that is very important, and excruciating to debug if you haven't learned it. If you didn't specifically allocate a new object (using 'new' in java, it's different in other languages), then all you are getting is a pointer to the existing object.

On Tue, Jan 12, 2016 at 2:01 PM, ehaensgen notifications@github.com wrote:

I figured out what my issue is. Even though I am creating a second object based on the initial value of the first object, Java has a VERY annoying way of creating the second object as a reference to the first. So, naturally, when the first object changes, so does the second and vice versa. I really hate Java sometimes. ;-)

On Tue, Jan 12, 2016 at 10:09 AM, danielr2e < notifications@github.com

wrote:

I'm afraid this is about the point where my memory is too fuzzy on the specifics of the WorldWind API.

One tip I can recommend is that if you are in an IDE like eclipse, put a debug point at the line(s) where you are updating the camera/view position. The variable will have a hash code that will let you make sure that the instance you are changing is really the same instance that is being consulted in OculusStereoSceneController during the render (the 'dcView' variable on line 297).

On Tue, Jan 12, 2016 at 12:48 AM, ehaensgen < notifications@github.com

wrote:

I have been going the route of creating a new instance of a view and initially filling it with the live view. So far it has worked as far as separating out the goggles from the "vehicle". At least as far as the heading of the goggles and the heading of the vehicle view. The problem I am having now is getting the vehicle to move and then updating the goggle view to follow. I can see that the function is getting called, but it does not change the lat/long. If you wouldn't mind, can you take a look at the code below and see if there is something I am missing?

protected void onHorizontalTranslateRel(Angle forwardChange, Angle sideChange, ViewInputAttributes.ActionAttributes actionAttribs) { View view = this.getView(); if (view == null) // include this test to ensure any derived implementation performs it { return; }

if (forwardChange.equals(Angle.ZERO) && sideChange.equals(Angle.ZERO)) { return; }

if (view instanceof BasicFlyView) { Vec4 forward = view.getForwardVector(); Vec4 up = view.getUpVector(); Vec4 side = forward.transformBy3(Matrix.fromAxisAngle(Angle.fromDegrees(90), up));

forward = forward.multiply3(forwardChange.getDegrees()); side = side.multiply3(sideChange.getDegrees()); //Vec4 eyePoint = view.getEyePoint(); Vec4 eyePoint = getCurrentVehiclePoint(vehicle);

// *\ This is properly showing the goggles (main view) and the vehicle headings are different as I move the goggles around System.out.println("Main heading; " + view.getHeading() + " - My heading: " + vehicle.getHeading());

eyePoint = eyePoint.add3(forward.add3(side)); Position newPosition = vehicle.getGlobe().computePositionFromPoint(eyePoint);

//Ignore goggle pitch LatLon latlon = new LatLon(Angle.fromDegrees(newPosition.latitude.degrees), Angle.fromDegrees(newPosition.longitude.degrees)); Position myPos = new Position(latlon, getView().getCurrentEyePosition().getAltitude());

this.setEyePosition(this.uiAnimControl, vehicle, myPos, actionAttribs);

// *\ The above code runs without any errors, but the heading is not updated. I have also tried vehicle.setEyePosition(...), but same issue. System.out.println("head: " + vehicle.getHeading() + ", Pos: "

• vehicle.getEyePosition().latitude.degrees + ":" + vehicle.getEyePosition().longitude.degrees);

this.setEyePosition(this.uiAnimControl, view, vehicle.eyePosition, actionAttribs); view.firePropertyChange(AVKey.VIEW, null, this.vehicle); } }

Thanks, Eric

On Mon, Jan 11, 2016 at 4:52 PM, danielr2e < notifications@github.com> wrote:

You would have to create a new instance of View to store that data in. Alternatively, you could just create two primitive double variables to store the pitch and heading and bypass View altogether.

On Mon, Jan 11, 2016 at 5:48 PM, ehaensgen < notifications@github.com

wrote:

Yea, I had pretty much the same thought. I created a View object within the VRFlyViewInputHandler that was a copy of the initial positioning of the main view object and then I feed the new object into the setEyePosition function. However, Java has a very annoying way of making the new object a reference to the existing and so when it changes it changes the main object as well. It is successfully feeding in my VehicleView object, but the goggles are still causing a change in the heading because as the goggles move and update the main view object, the reference to my new object gets updated as well. I am unfortunately not Java savvy enough yet to learn how to create an independent object. :-/

On Mon, Jan 11, 2016 at 1:51 PM, danielr2e < notifications@github.com

wrote:

Ah, OK. If I were doing it, I would just try to find out where the key presses are currently being used to translate the camera position (probably in the fly view handler). Look for uses of the View instance, which gives you access to the position, pitch, roll and heading. Then change that translation logic it so that it doesn't consult the camera's orientation. Instead, you would have a 'hidden' pitch and heading that you consult. Then you would want the left/right keys to update the heading (turning the 'ship' left and right), you'll have to figure out some way to update the pitch, as that's the only way the 'ship' would be able to go up and down.

On Mon, Jan 11, 2016 at 4:23 PM, ehaensgen < notifications@github.com

wrote:

Thank you for the quick response. Essentially what I am attempting to accomplish is making it so that the viewer is, in essence, sitting in a vehicle that moves independently from the direction of the goggles. Sort of like a flight simulator. I want to be able to use the keyboard to move around the environment, but use the goggles strictly for viewing. It would be move like Half-LifeX where while you are in a vehicle you can use the mouse to look around, but driving is done by the keyboard. My thought was to create a "vehicle" class that would extend the BasicView functionality and maintain two separate views and modify the code to get heading/pitch/etc from the "vehicle" view. Sadly, my brain has been in overload since picking this project back up. I was able to use to code you had sent me from google to get the DK2 working and am slowly learning the interface that you had built and the original Java world wind software (which I downloaded but am unable to compile). I have look extensively at the VRFlyView and VRFlyViewInputHandler code. I was finally able to

modify

the onHorizontalTranslateRel function to ignore the pitch of the goggles, but am back at square one with determining how to force it to ignore the heading of the goggles since that it still required, I just need to feed it a different object. Damn 3D crap is so frustrating sometimes. ;-)

Thanks, Eric

On Mon, Jan 11, 2016 at 11:37 AM, danielr2e < notifications@github.com> wrote:

Hi Eric,

You were the guy who got the DK2 code from Google code, right? I still haven't moved that over to github, so that tells you how much I've worked on it :)

I'm actually not experienced with 3D stuff at all, and only got the port working through force of will, so your experience may not be too far off my own. You are in luck, however, that anything involving input will be a lot easier for you to understand than the OpenGL/rendering stuff.

The keyboard behavior is more or less what is built into WorldWind as the 'fly view' controls. There is a custom version of this logic where you could probably modify it to decouple the view from the orientation used for flying around. I'm actually not quite sure what you have in mind, though, because you need some way to control that frame of reference to actually travel in different directions. PC shooters like counter strike have the view locked to the direction of movement for a reason, right? Maybe you could make it so that if you hold the right mouse button, it lets you look around without changing the direction of movement?

Anyway, the class you would want to look at is:

https://code.google.com/p/worldwind-vr/source/browse/worldwind-vr-dk2/src/com/tuohy/worldwindvr/input/VRFlyViewInputHandler.java

If you want to do something similar with the 360 controller (dual analog sticks might give you the flexibility you need!), check out:

https://code.google.com/p/worldwind-vr/source/browse/worldwind-vr-dk2/src/com/tuohy/worldwindvr/input/Xbox360Controller.java

I think the 360 controller was kind of working, but it was the last thing I worked on, so I can't quite recall.

Daniel

On Mon, Jan 11, 2016 at 1:40 PM, ehaensgen < notifications@github.com

wrote:

Daniel, Long time no talk! :-) I don't know if you remember me, but I was curious if you had continued any development with the Oculus and/or WorldWind? I just recently picked this project back up for work and I was finally able to get the java project to run and using the goggles I am trying to wrap my head around how I might be able to separate the Oculus view movement from the keyboard direction keys Basically, I want the goggles to be used to look around but not affect the direction of the movement when the keys are pressed on the keyboard I am an experienced developer, but more in the Visual Studio C# arena and not so much in the OpenGL 3D field Not to mention, it seems you have done quite a bit of work building the code to use the goggles and have a decent understanding of 3D concepts I was hoping you might be able to point me to where in the code you think I can do that

Thanks, Eric

— Reply to this email directly or view it on GitHub <https://github.com/danielr2e/worldwind-vr/issues/4 .

— Reply to this email directly or view it on GitHub <

https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170665988

.

---

Eric A. Haensgen

— Reply to this email directly or view it on GitHub <

https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170693857

.

— Reply to this email directly or view it on GitHub <

https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170702076

.

---

Eric A. Haensgen

— Reply to this email directly or view it on GitHub <

https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170717419

.

— Reply to this email directly or view it on GitHub <

https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170745699

.

---

Eric A. Haensgen

— Reply to this email directly or view it on GitHub <

https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170804440

.

— Reply to this email directly or view it on GitHub <

https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-170998237

.

---

Eric A. Haensgen

— Reply to this email directly or view it on GitHub <

https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-171016447

.

— Reply to this email directly or view it on GitHub <

https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-171021765>

.

---

Eric A. Haensgen

---

Eric A. Haensgen

— Reply to this email directly or view it on GitHub < https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-171093574>

.

— Reply to this email directly or view it on GitHub https://github.com/danielr2e/worldwind-vr/issues/4#issuecomment-171100383 .

---

Eric A. Haensgen