3D Radar UI : Beta-2d July-22-2016

Excellent yes, the FOV changing code makes massive improvements to texture quality. as far as I can tell 90FOV should always be preferred. I'm going to implement a similar FOV override from a stored user.PREF and set in my UI with similar VerticalFOV override in my games scene-manager script. I'm going to have to expand on this simple override for my setup. Since I got multilayer OVR's. With a background infinite distance emulating OVR.

The next thing I think you would want to try and test in scene, is to transform the rotation of the HUD element to have the textures faceing to adjust as it moves to screen edge. Rotate with a home of 0 and +/- FOV/2. So for 90 FOV a +/- 45* rotation of the face in both vert and horizontal.

 

Simple enough I'll work on that sometime this week and post a new test build when it's ready for you to try out to make sure things are progressing in the right direction. Thanks for your assistance!

 

Here is the updated Rift Test package. The HUD element will now rotate towards 45deg as it reaches the edges of the screen. Let me know how this works out

Edit : Added the option to turn HUD element rotation on / off and comments to the script

 

opps the code isn't working. I though it was but further testing looks like no. debug shows no angle adjustment. and active or disabled doesn't change visual effect.

 

I checked and

Vector3 newPos = ThisCamera.WorldToViewportPoint(Target.position);
when using Debug.Log (newPos);
returns 0.5,0.5,26.4 at all times it's not tracking which causes a return from function of 0,0,0

 

ok fix'd it. you was referencing the HUD camera. Works great!

 

Glad its working. Do you believe that this is the method I should use to update the Radar's Rift rendering method.

Just to confirm.

Correct Vector3 newPos = ThisCamera.WorldToViewportPoint(Target.position); Is using a dummy camera to get the targets Viewport position. So with the object located at the center of the screen it's Viewport position would read (0.5,0.5,26.4).

Are you referring to the (0,0,0) as the HUD elements rotation? When the object is at the center of the screen we want the HUD element's rotation to be 0,0,0 so it is looking right at the camera. This means we must negate the targets viewport position at the center of the screen (a value of 0.5,0.5,26.4) so the objects rotation will be 0,0,0. Then we can apply rotation as the target starts to creep towards the screen edges by

Angle = new Vector3(-(newPos.y - 0.5f) * EdgeAngleY, (newPos.x - 0.5f) * EdgeAngleX,0);

 

no i had a problem with the fact the dummy camera wasn't set up. so the variable was returning static location of 0.5,0.5,26.4 zero'd out by the script.

Right now I've got the script attached to cameraRight, and using that for location check. not using the dummy camera.

What math did you use for getting 138,80 just want to make sure on same page for that math.

Going to try testing the implementation in a scene with more assets for visual queue references, sometimes stuff looks right in empty scenes in OVR but once populated with assets you notice error more.

 

Only thing I can think of right now. is might need to adjust the determination of "edge" of screen. to be able to pull it in a bit. As our eyes don't see to the full edge of barrel. I'll no more once I test in a more complex scene.

 

No formula. The script has a Debug.Log() that displays the current amount of rotation to apply to the HUD element. What I did was simply place the target so it’s position was at the left edge of the screen then the top edge of the screen and adjust the EdgeAngleX Y values untill the HUD element’s eulerAngles.x.y equaled 45 deg.

That’s where

Code (csharp):

1. Angle = new Vector3(-(newPos.y - 0.5f) * EdgeAngleY, (newPos.x - 0.5f) * EdgeAngleX,0);

comes into play. Because the dummy camera is in the center of the two rift cameras you can use the inverse value from one side to the other without needing to modify it to compensate for the difference in separation between the two cameras.

The Radar script has a method to adjust the screen edge padding for the HUD elements. This pulls them closer into the center of the screen. I added this in just for this reason

 

ForceX,

I just saw your updated package. I just started a new job last week so I have not had a chance to check on your progress. I will give this a shot and see how it looks.

 

Nevermind just saw you were working with Broten on this. Let me know if you need anything.

 

Broten, I am using a similar camera setup with exception of 3D monitors. I will plug in your specific settings and see what results I get. By the way I agree the results of locking FOV to 90 produced much better image results. Also are you using native Rift resolution or are you upscaling?

 

RowdyMrB : Your feedback is always welcome! If you guys think this looks like a good approach I'm going to start modifying the Radar to use this new method for displaying the HUD elements with the Rift.

 

The Rift screen is a 1280x800p, but it also supports 1920x1080p input mode. Some have said it looks better at 1080p then hardware downscale. presumably if the textures are set up for 800p mode, they'd look better in that mode directly. I personally run it in native.

Also one thing to watch for is burn in! my Dev kit already has burn in all over the LCD. make sure to turn it off the second it is removed from ya head. and when designing UI try not to have fix'd locations for elements. These screens appear to be highly susceptible to burn in. The retail will most likely have higher quality screen when it goes 1080p version.

 

looks good for starting to work into the ovr portion of 3D radar.

a simple addition to ya asset pack i added when I got it. was a var to flag the layers modification and so I could manually adjust them. Yuo have custom mode. but I had other scripts accessing the same layers. and the two liked to fight over it.

So I just en-capsuled that segment of code in a if(boolean=true){}. and checked the public Boolean flag. Made it quick and easy to by pass layers and let me mod them in my other scripts.

don't forget the location indicator arrows. that code was never ported properly to work in OVR mode.

 

before adding this modification to live. suggest determining the 138, and 80 via scripted math.

I'd disable OVR's barrel effect for testing since this should be enabled as post-processing after UI camera is drawn.

the math should determine the current resolution of each view port as a base and determine from that, modified by the FOV.

the native 1280x800 /2 horizontal should be two 640x800 view-ports.
using the -0.5f's to centre to view-port should mean we have +/-400px and +/-320px.

in 1920x1080 /2 horizontal we have 960x1080 each view-port to work with.
using the -0.5f's to centre to view-port should mean we have +/-540px and +/-480px.

So max angle wanted should be FOV/2.

My current test actually shows a 90* rotation on one of the axis movements. so current implementation still is bugged.

 

I'm going to do some tests here in a second and see if I can mix up an equation for this.

 

This is probably because the target and the HUD element are outside the cameras FOV so the rotation will be greater. In the 3D Radar the HUD element is not allowed to exit the edges of the screen, instead it will stick to the screen edge. This will prevent the HUD's eulerAngles from exceeding 45 deg as the amount used to determine how much the HUD element should rotate is based entirely on it's screen position.

 

138, 80 I've determined is wrong both should be FOV/2. Aswell as the Horizonal FOV is not the same as the vertical. so this needs to be determined and adjusted for. We are working with rotation = # degree's from 0 on axis of FOV.

so -45* in a 90* FOV equals 45* rotational.

Here is my code changes for that effect. I am running it attacked to CameraRight of the OVR prefab. The main problem with the script is haven't taken into account the IPD set on the OVRC controller. In reality is should be 2 UI objects. one for each eye with any IPD corrections and this rotation done per eye. (that part gets messy).

CODE:

 

Just for note running native 1280x800 returns:

set to 90, we have a hFOV: 77.31962 vHOV: 90
set to 111.4777, we have a hFOV: 99.17448 vHOV: 111.4777

the max rotations then are 0.5* these values in both +/-.


An addition point of note. the OVRC controller has Lens Correction OFF and Chroma OFF. Do not enable these on a HUD OVR camera set. The correction should be done by a separate OVRC set such that it is depth'd above each camera in this HUD-OVR set.

 

Just got up and am getting ready for work but wanted to ask a question.

This sounds similar to the current method used in the Radar. The HUD elements are rendered out to two separate L/R cameras over the Main OVR L/R cameras. The issue is that because Lens Correction is not applied to these cameras the HUD elements do not match up with there respected Lens Corrected world objects. Which brought up my conversations with RowdyMrB about needing to be able and compute an objects screen position post Lens Correction. Is this what you are referring to as IPD corrections? If so then it sounds like these new test scenes do not really mean all that much if we still need to compute Lens Corrected offset? Does this sound right?

 

If you have stacked camer out puts to each view port. the last camera does the OVR lens correction. it completely removes the need for manual correction of hud.

 

no lens correction is needed let the OVR handle it.

Simple method is using a dummy camera with same resolution view-port that is centred to the IPD.
But this isn't accurate.

Another option which is how it's done now in radar3d is to get location data from BOTH viewports. LEFT and RIGHT. and paint a hud element on each eye. then adjust rotation script functions on each eye. this allows for rotations to the edge of view port on each.


I sent you an asset pack in msg to show a basic OVRc set up for lens correction. I didn't share public because it contains the Oculus code in place.

I've got a landlord inspection tomorrow so probably wont be able to make changes to go 2 camera adjusted.


Things to do:
1 move script from CameraRight. to an agnostic location.
2 reference cameraRight and cameraLeft of our choice that matches HUD in script
3 mod location tracking to work for both Right and Left viewport
4 mod rotation track to preform to Right and Left tracked object. and rotate beased on results for each viewport.

 

I was just typing up a question about a typical setup and you posted up an example I'm going to look at this first thing when I get home.

Here was the question anyway.

I did not know that! I thought the Lens Correction was applied directly to that camera.

Does that mean that you would typically work with a 3 camera layer setup something like :
Layer1 (camera depth 0) Renders the environment
Layer2 (camera depth 1) Renders the HUD elements
Layer3 (camera depth 2) Renders nothing but applies the Lens Correction to the previous Layers.

Does this also mean that the only cameras required to have the OVR scripts is the Layer3 cameras?

Edit:
It also seams that with the use of Zdepth shaders that always render on top we can remove or combine the HUD camera layer with the Enviroment layer. Shaders like the one I have included in the Rift test package.
End Edit:

I wish I had a Rift. My brother will be coming into town later on this month, I’m going to make sure that he brings his Dev kit with him.

 

Correct Layer3 camera is the only one needing Lens Correction. and only one that should. else you cascade lens corrections. and the camera objects of lower cameras get distorted multiple times.

Rule is 1 lens correction total for all scene.

Layers 3 in my case has lens correction, as well as player/cockpit. since I want them in front of my HUD trackers.

One thing to considers. SOME UI should be layer 2, some layer 3.

Tracking on layer 2, and near HUD like directional arrow would probably be layer 3.

I'm using the set up now with current radar3D.

 

In my game I have

Right Eye
OVRC - sky box. solid black backgrounded, 0,0,0 fix'd
OVRC - scene objects. no clear, LENS off, chroma off. variable x,y,z to player location.
HUDc - radar3d tracked elements. overlay map to scene objects. (with new system these would be OVRC or mix'd into OVRC below)
OVRC - Cockpit, player and fix'd foreground HUD. no clear LENS correction ON, chroma off. 0,0,0 fix'd

Left Eye
OVRC - sky box. solid black backgrounded, 0,0,0 fix'd
OVRC - scene objects. no clear, LENS off, chroma off. variable x,y,z to player location.
HUDc - radar3d tracked elements. overlay map to scene objects. (with new system these would be OVRC or mix'd into OVRC below)
OVRC - Cockpit, player and fix'd foreground HUD. no clear LENS correction ON, chroma off. 0,0,0 fix'd

 

For the Radar I will probably create a separate version just for the Rift. This version would allow you to assign your own cameras, render layers, and which HUD elements should render to which layer/camera. This should allow you to customize the HUD to render how you want.

 

Good idea it has forked out already a lot

 

Good news I'll be getting the Rift this weekend through the next two weeks. I'll be at SXSW in Austin checking out the PrioVR and Star Citizen if they are there and I'll be picking the Rift up then

 

Nice star citizen is a good product.

 

PMed you a new package. I set it up the way I thought a more finalized version would look.

I changed the way the script works. Because we only care about how our HUD textures look we only need to set the HUD cameras FOV to 90. All other non HUD cameras can keep or inherit the OVR FOV.

The tracker script is attached to the _StaticGameWorld object.

The _StaticGameWorld is intended to stay at 0,0,0

Give it a shot and move the Target, OVRCameraController around and look about. I applied one of the standard skyboxes as well.

Edit:
I have not yet applied independent L/R HUD elements I'll add this in the next day or two.

Turns out SXSW is next weekend.

 

I see why you have two OVRCameraControllers now. You need to be able and access the IPD values for each camera layer.

 

Broten and ForceX,
Great discussion! I have learned a lot and had a number of things confirmed regarding my OVR camera setup. One difference with my setup is I am running 4 layers of OVR cameras with one dedicate to a custom skybox dedicated to my star field. It may not be the best way to handle it but it is what I had time for ATM. I also have not had time to run it through the Latency Tester so we will see how that checks out when I do.

I am looking forward to trying out what ForceX comes up with. 3D Radar has saved me a lot of time and effort.

 

The other reason to access the IPD's of each layer of camera is to make adjustments for game scale.
The default is set for 1 Unity Unit to equal 1 meter. If you have a world that you have scaled to be 0.01 Units equal 1 Meter then the IPD etc needs to be factored in. This is why in my games I've gone the route of passing all values as scripted overrides to the OVRC based on 1) user selected value, 2) any transformations needed one specific cameras, 3) reset to defaults base values provided by OVR config. Allows greater control of the cameras by the game.

 

After work I'll create a new build using your recommendations.

 

Hi ForceX!

I'm using your radar script in my game project and it has been working quite well (I have seen some inspector errors related to editor scripts but I have ignored those). Now that I have started using PoolManager for Unity which recycles gameobjects by disabling/enabling them I get a lot of errors with your radar implementation.

I needed to modify DestroyThis() to not to delete the gameobject that it is attached to because I want gameobject to stay inside the asset pool. That change was ok to preserve the gameobject, but I still get a lot of null reference exceptions here and there because I need to disable FX_3DRadar_RID script when an enemy game object "dies" and gets SetActive(false), otherwise I get more errors because gameobject is not active. Some other functions still try to access something that is not there anymore. Probably DestroyThis destroys something that it should not in this case.

Now I'm trying to figure out how to preserve this RID in the gameobject because just commenting out the Destroy(gameObject); from DestroyThis() does not seem to be enough because when the gameobject is recycled and activated again I don't see icon on the radar.... I have also added some if(ThisID[someIndex] != null) ... or if(ThisID[someIndex].gameObject != null) ...

Any idea how to modify DestroyThis() to work with disabled/enabled objects rather than newly instantiated objects? I would love to continue using this radar but it seems that I'm having a hard time with it when not using Destroy with my objects anymore.

Br,

Kalle

 

I have not tested this but you can create your own function in the RID script to simply disable/enable all related assets.

This just replaces any Destroy() methods with SetActive(false).

Do Not SetAactive(false) the main GameObject you will not be able to re-enable it through the RID script. Instead disable the GameObjects renderer and collider.

Code (csharp):

1.  
2. function DisableThis(){
3.     if(!IsNAV){
4.         BoundsCorners.SetActive(false);
5.        
6.         //Remove this target from the players target list
7.         FX3DRM.RemoveFromList(ThisID[0]);
8.     }
9.        
10.     ThisID[1].gameObject.SetActive(false);
11.     ThisID[2].gameObject.SetActive(false);
12.     ThisID[3].gameObject.SetActive(false);
13.     ThisID[4].gameObject.SetActive(false);
14.     if(FX3DRM.SetStatus[1]){
15.         ThisID[5].gameObject.SetActive(false);
16.     }
17.    
18.     if(IsPlayerTarget){
19.         FX3DRM.ClearTarget();
20.     }
21.  
22. //Disable the renderer
23. gameObject.renderer.enabled = false;
24.  
25. //Disable your collider
26.  
27. //Disable this RID script
28. this.enabled = false;
29. }
30.  
31. function EnableThis(){
32.     if(!IsNAV){
33.         BoundsCorners.SetActive(true);
34.     }
35.        
36.     ThisID[1].gameObject.SetActive(true);
37.     ThisID[2].gameObject.SetActive(true);
38.     ThisID[3].gameObject.SetActive(true);
39.     ThisID[4].gameObject.SetActive(true);
40.    
41.     if(FX3DRM.SetStatus[1]){
42.         ThisID[5].gameObject.SetActive(true);
43.     }
44.  
45. //Enable this renderer 
46. gameObject.renderer.enabled = true;
47.  
48. //Enabe your collider here
49.  
50. //Enable this RID script
51. this.enabled = true;
52.  
53. //Add this target to the players target list if it is in range
54. var Distance : float = ((FX_3DRadar_Mgr.PlayerPos - ThisPos).sqrMagnitude);
55.     if(Distance < FX3DRM.RadarRange[1]){
56.         FX3DRM.AddToList(IFF, ThisID[0]);
57.     }
58. }

 

Hi ya Doc.... Thought I'd drop in after some time away... ( sky dive accidents hurt a lot ). 3D Radar looks like it's moving ahead nicely. Will give it whirl again shortly in my Oculus Rift.

 

Hay Banksy, The radar has not been updated with any new rift features yet. I am however getting the Rift today for one week and will be working on it during this time. So expect an update later on in the coming week.

 

Here is a preview of the updated inspector I have been working. It should give an idea about how the new Rift options will work.

 

Good Work ForceX, looks like you gathered the ideas talked about into a nicely forming up package. Can't wait to see the implementation.

 

Can't wait to try it!

 

Ha-ha.. awesome news !!! can't wait to test it out.. What THE FUN !!! you finally get o trial the Rift.. this will help you so much. Before you were sorta ball parking a lot of the Oculus features... needless to say you did a darn good job of it.

I'll brush out the cobwebs from my Oculus Rift over the weekend... note: Lately I've been playing around with OVRVision ( an AR accessory for the Rift )

I reckon once the Oculus Rift V2 comes out with 1080p Rez.. your Radar will shine .....

 

So it turns out that this is not going to be a simple process. The radar script was designed with a very strict set of rules and allowing any number of cameras with any possible configuration of rendering options is going to be a nightmare to mod in. I will probably rewrite the Radar in C# and create it to be more flexible in this regards.

Sorry for the delay but I believe this will be the best choice. A fresh start with the Rift at the core of the design instead of an after though integration. Also because the Rift scripts are in C# this will allow for better integration, where as ATM in JS it is only possible to to communicate from JS to C# or from C# to JS but not both at the same time, and because the Rift requires Unity Pro I will be able to use a few more Pro only features through out the radar. It might require Unity 4.2+ if i want to use the new Quad primitive instead of having to create my own. Well see it's not that important, just clears out a bunch of code.

I am excited I've been wanting to rewrite the Radar in C# for a while now so this is a perfect opportunity. The current version will stay online so continue to use it as you please. I do not know how long it will take but just a before I will post up versions from time to time. Thanks for your support and feedback with V1 it has been invaluable, but now it's time to start working on V2! If you have any cool ideas that are radar centric post them up.

 

Looking foreword to this rewrite! I think moving to C# is a good decision. Currently the radar scripts are the only remaining JS I have left in my game as I have rewritten everything else in C# up to this point. I had originally started it with JS. Thanks for all the effort!

 

Let me know how it goes ForceX. if you want anything tested or feed back just PM me.

 

Thanks, I'll let you guys know when a new build is ready

 

Hey ForceX in case you have not seen it now is the time to order your Oculus Rift. DK2 was release this past week. I think this one will have the resolution you are looking for. Ordered mine last week.

 

C# sweet.... I'll check back from time to time... I notice OculusVR Dev. Kit 2 will be released start of July. They're taking orders now