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

I dont know. I'm running Unity 4.5.0f6

This is what my directory structure looks like for testing.

 

My structure looks the same other than the weaponTarget script is in a Scripts folder that sits at the root outside of Standard Assets (I have also had the script in the root). Additionally, the FX editor scripts have been in both an Editor and Assets\Editor (which is physically assets\asset\editor) folder. My Unity is at 4.5.2.

 

DK2 is being delivered on Tuesday

 

Awesome news!! Have you been able to get your C# issue fixed?

 

No I am still struggling with it. I have done about everything I can think of but will figure it out eventually. In the mean time as a fun/interesting exercise I have been working on a port of 3DRadar from JS to C#. I am down to working through 300 errors in the FX_3DRadar_Mgr script (I finished going through the errors on all the other scripts). Most of what is left are various casting/implicit convert errors. If I get it done I will send it to you.

 

Here is the current build of the C# version for Unity 4. It is missing Target Lead Indicator, NAV points, and still needs some work with the status bars. I am currently using the Rift skd 3.1 i think. If you want you can create a new scene and mess around with it to see the changes. I wouldn't import it into your existing project until you are comfortable with the changes. There is no documentation ATM to go with this version.

 

ForceX,
Thanks for a first look at the new build. I am looking forward to taking a look and will send feedback.

BTW With the port that I had started to work on I took the assembly of the JS version and used ILSpy to save it to C#. I got through another 100 compile errors most of them are just from the stuff that does not get interpreted accurately from the assembly such as inserted get/sets and mis-interpreted variable names. Also all the other stuff that gets inserted that Monobehavior does not need. ILSpy works pretty well if you need to do a port without a complete rewrite.

 

On new code getting "type or namespace name 'CustomList' could not be found error in CustomListEditor.cs

 

CustomListEditor.cs should not be there and is safe to delete or it should be. It was an example for something else.

 

ForceX,
I dropped this build into a fresh project with the OVR components. Great progress! It looks like you have a lot of the functionality in this version. I like what you are doing with camera groups. This will really come in handy with the Rift and make it much easier to track the different camera configurations. I think I am running 4 or 5 different camera groups in my game now. I did run into a runtime error "A game object can only be in one layer ..." . I have not had a chance to see if it is somehow related to how I have things configured.

 

Well got the Oculus DK2 this evening and the graphics are way better. I have not had time to get my game configured with the new SDK and Unity integration yet but am anxious to do so. Looking forward to trying it with DCS World as well.

 

Also picked up my DK2. Will test latest build shortly ( & yup.. I'm still here )

 

I love you.

 

Curious to see what comes of this.
http://blogs.unity3d.com/2014/09/20/expanded-oculus-rift-support-in-unity/

Going to look into using the new 4.6 UI to draw the HUD elements. I think this should remove the necessity of creating code to place elements pixel perfect on the screen and allow easier implementation for 3D style HUD elements. Also I would think having two canvases (one for each eye) should work with the Rift.

 

This does sound promising...By the way I have also started experimented with using the Leap Motion VR mount and Oculus/unity interfaces.

 

@ RowdyMrB I also have the Leap Motion.. I tried attaching it to my DK2 faceplate. Works quite well but I'm still not a big fan of camera tracking motion. "Perception Neuron " looks interesting though.. I also wait for Sixense STEM

 

I am with you I think both those products look very promising and will be spending more time with the STEM when it is available next month. Like you, so far I have found the camera tracking to be a little limiting. Still digging into it though.

 

With the alpha, I am having trouble getting the oculus rift stuff to work. Admittedly, I am using .4.2 sdk, not the .3

In short, if I have the camera group create the cameras for rift, the hud stuff doesnt show in the rift. Ive tried playing around with creating the oculus cameras and then telling camera group to use them, which gets me a visual, but the visual acts strange, parts of the HUD are obscured unless I look straight ahead, and the boxes dont follow the targets.

 

I haven't tried out the 0.4.2 sdk yet but here are some things you can check.

Does the included Rift demo in the radar package have the same issue on your end?

1. Make sure the HUD is rendered to it's own Orthographic cameras, not shared with the player perspective cameras.
2. The HUD cameras rendering layers are setup to render only the HUD elements. Ie Left camera is rendering Left HUD and Right camera is rendering Right HUD.
3. Other cameras rendering layers are not rendering the HUD layers.
**4. The HUD cameras need to be fixed at world 0,0,0 and do not rotate.

** = It's been a while I need to confirm this when I get home.

I will try to get some time with a Rift this weekend to help out better.

I'll work on getting a setup documentation.

 

Ok, playing around with the demo using the .3 ovr plugin, i saw the hud cams had a size of 124. Much better results using that as my size, but things still dont line up. For example, selecting target creates the diagonal bounding boxes in the lower left corner of the screens. Moving targets, I saw some limited side to side motion, but not to extents. Will provide more info tonight when I'm back at PC.

Thanks so much for all your effort!

 

Yes the camera ortho size should be 1/2 the vertical size of the game screen. This should be set automatically. I will look into this tonight.

If you are able can you setup an example scene and PM me a unitypackage to check out, or post some pics of the inspector for the camera settings.

 

Here is a quick overview of how your HUD cameras should be setup.



Bringing it all together. This is the minimum recommended setup. The HUD Cameras need to remain fixed at world 0,0,0 with the GameMgr object and never rotate.

For the SkyBox It is recommended to use the included inverted quad sphere instead of Unitys default SkyBox for depth reasons. The quad sphere and SkyBox cameras should also remain at world 0,0,0. SkyBox cameras need be set to inherit the Rotation & FOV from the player camera but not the IDP values.

 

Thank you for the layout of how it should look. Unfortunately, I cant simply have the HUD camera created by the radar. If I do, the HUD doesnt get displayed at all (using 4.2). I actually got some forward progress, so let me give you a run down of what I have so far (I'd upload a unity package, but my satellite internet sucks)

First problem: HUD not rendering when using the create camera option
current solution: Drag an OVR Camera controller prefab onto the _HUD object. Set the cameras to orthographic.

Second problem: TSB not following target
current solution: Im not sure what I did, it might have been a glitch in Unity, because it works now... somewhat

Third problem: The TSB images for left eye and right eye are seperated way too much. The left eye TSB was right on the target, the right eye one was off picking daisies to the left.
current solution: Change the HUD camera layermasks so that both left and right cameras render the left HUD layer. This puts the TSB in much closer to the right place, but seems hackey and a better fix would be preferable.

Fourth Problem: TSB only fully appearing when looking directly at it. Otherwise, parts of the image were cut off.
current solution: This one was on me. I had set the clipping plane on the individual cameras in the OVR Camera Controller, not realizing that the settings on the controller itself overrode them. This meant that parts of the mesh were turning out past the near clipping plane at 0.15. I changed the settings of the OVR Controller to have a clipping plane of -50 to 50.

Fifth Problem: The radar itself was not showing up.
current solution: Added an OVR CameraController that looks right at the Radar prefab. By moving the camera, I can move the Radars aparent location. Later, I might add a rig that allows the radar to act like an artificial horizon as well, with the camera rotating in sync with the main view.

Sixth Problem: The HUD is rotating, even when I have inherit Rotation unchecked, and all rotation and translation control from the oculus rift turned off as well.

I will pound away at it some more, and when I get a chance, I can upload a package tomorrow when Im at school, if you still want it.

Thank you again for all you help!

 

It sounds like Oculus has made changes to the rendering pipeline again. I'll download SDK 0.4.2 tonight and see how things go. One thing I did think of that i didnt mention last night is that there is actually a 4th camera group. This is a OVR camera group which has its depth set to be the highest of all the cameras but renders nothing. What this does is allow the cameras below it to render before the Lens Correction pass.

Depth 2 OVR Camera Renders Nothing, Has Lens Correction Enabled.
Depth 1 HUD Normal Camera
Depth 0 Player Normal Camera
Depth -1 Sky Box Normal Camera

 

Yup 0.4.2 has completely changed the rendering method once again.

In previous SKD releases the OVR rendering pipe & distortion shader included all cameras with depths below the OVRCameraController cameras depth. This meant you could have a layered rendering approach using non OVR cameras. Now it now appears that they once again only render there own OVR Cameras and ignore all other cameras. This means that every thing needs to be setup using OVRCameraControllers and needlessly executing there code 3-4 different times. Where as before you would only require one OVRCameraController and render everything else with normal Unity Cameras.

I have been able to get a working scene, but... I will need to come up with a different approach to render the radar object to the screen.

 

I agree with you not chasing your tail on the Rift rendering methods. Their blogs and some of the materials from the conference indicate their is more to come before it is finalized. The 4.2 beta has a ways to go yet.

 

It appears that the OVR view space is larger than the represented screen space. My game window has a screen size of X= 1203 Y = 467 but doing a world to screen space on the OVR camera results in a 1/2 Y of 760. This means i need to find out how to get the represented screen resolution from the Rift in order to do any screen position calculations. This is what is causing the target selection box to think the center of the screen is the top edge of the screen.

Now the OVR renders outside of the unity game view too.

 

Im pretty sure that there is a function that returns the rendered area. I'll check the code for the OVR Main menu which displays the rendered area size

EDIT: This is the code that OVRMainMenu uses to access the render size
int w = 0, h = 0;
OVRDevice.GetResolutionEyeTexture(ref w, ref h);

EDIT2: Running a simple scene, I get a resolution of 2364x1461

 

Thanks I'll see if I can fix the screen bounding edges using the GetResolutionEyeTexture.

 

Easy enough of a fix. Now I only need to get the radar to render back to the screen again.

 

This is so cool! Starlancer, FreeSpace, and Wing Commander are my favourite game series.

I'm working on a fantasy themed game now but I've always wanted to put my own spin on a space combat sim.

I'm shocked that this is free. Gonna download it now and mess around.

 

Fantastic.. Beware that the current Oculus SKD broke support for the radar so it's only good for normal desktop monitor development ATM.

Edit:

Also the C# Alpha a few post up resolves some ease of use issues with getting the Factions setup for first time use but is missing target lead functionality and nav points.

Something I just noticed is with Unity 4.6 beta 19; which resolved a long standing issue between DX9 & DX11 rendering slightly differently to screen space; is now showing a 1 pixel overdraw on the texture atlas. This means some textures on the atlas with close texture neighbors have a one row of pixel bleed. I will be reworking the atlas to resolve this issue.

 

If it helps, my solution was to create another oculus controller as a child of the radar prefab, clear flags depth only, layer mask: radar_object and radar_GUI.

In other news, I'm modifying your RadarManager code so that checking "Create Camera" in the camera groups when using oculus rift creates an OVR Controller for it instead of the camera-child camera set up that you originally had. I also added in some code to the OVRCamera and OVRCameraController to make this easier. Once I get it sorted, I could send you the code for you to look at.

 

I came to the same conclusion. The only problem is that with out using two more OVR controllers it's only possible to render the radar pixel perfect in orthographic mode. As Perspective rendering mode still uses a second orthographic camera to transform the line points from perspective screen space to orthographic screen space.

It all boils down to me having an issue with needing to run OVR scripts multiple times. At this rate we will be using 4-5 OVR controllers. While I have not looked at there code for 0.4.2 in the past they never cache anything instead calling many multiple ridiculous lookups like ACamera.gameObject.transform.camera.FOV ARRG!!!. Executing crap like this 5 times over is needless & I absolutely hate it.

Sorry rant over.

 

The other alternative might be using a render to texture. If you are developing for the oculus, you have pro version anyways, so the only downsides would be a loss of true 3d and lack of transparency. It might be possible to have a circular plane as the mesh the texture is on, which would minimize the issue with no transparency. I will take a look at that tomorrow afternoon.

 

This is awesome. The only thing I had to do is set the layers as per the instuctions in your PDF. Once I did that, the demo scene worked.

 

Good idea. This way the object that has the assigned render texture can be set to display on the HUD cameras.

I mentioned before that I believe the use of the new canvas UI system in Unity 4.6 can also eliminate the need of extra OVR controller groups because it provides a (easy) built in method of screen space rendering with perspective cameras. This would eliminate the need for a dedicated orthographic camera group for the HUD.

Fantastic. I hope you like it

 

I played around with using render textures and oculus rift, and I think Ive got it looking pretty good. I didnt even need the circular mesh, because particle shader that you used worked perfect in that regard. Using a regular quad, I set it as the target of render to texture setting in the radar manager, and added a script to it.

I also placed the orthographic radar camera down to be level with the radar, added an empty gameobject centered on the radar as a child of the radar, and made the camera a child of the empty gameobject.

The script on the quad calcuated the vector3 from the quad to the OVR camera controller, and then in update, found the rotation from starting vector to the current position. It then sets the radar rig( the empty gameobject holding the camera) and the quad to have the same rotation that was calculated. YMMV, but it looked reasonable to me, and saved an OVR controller.

The new script is attached

 

How much would it take to get all that changed over? I agree it would simplify things immensely!

 

It shouldn’t take too long, but it's not too high on my priorities list atm. I'll probably start tinkering around with it next week.

 

Gotchya. I'm having to put this aside to study for qualifying exam myself. Looking forward to whatever you come out with!

 

Sonnova B! They (OVR) changed the structure again! I understand now why you were hesitant to do any extensive work on Oculus support.

 

LOL, I saw the new, new SKD that was released a few days ago. What did they change this time?

 

They reworked the structure of the Camera prefab. Instead of a pair of cameras with OVRCamera scripts, they have 3 cameras, none of them with the ovrCamera script. I dontt know about rendering pipeline yet

 

That sounds like one of the early 0.3.x release versions that used a 3 camera setup. I hope they can settle on a method by 0.5.

 

Hi ForceX, well done on a superb asset!

I have read practically every post in this thread and I have some questions...

2 posts mention network compatibility but you were sort of unable to answer with any definite statements. Then another post mentions a new camera and you answer with a theory about updating the "_GameMgr" script with the new camera.
Wouldn't this be how you enable for network projects as well?
My project is multiplayer only and all scripts are C# apart from yours, so as I instantiate a network player from a prefab, I can't set the player and playercam in _GameMgr.
When a player spawns, my scripts enable and disable certain things...for example, my player object has 3 child objects...1 is a full model ship (enabled) and another is a detailed cockpit (disabled), the 3rd is the players cockpit camera (disabled). On spawn, my script finds out if the player is local or remote...if it's local, it enables cockpit & camera children and disables full ship. It is probably in this same section that I would update the _GameMgr script. The same script also enables disabled player controls for the local client, so I am assuming it is possible to have _GameMgr disabled until spawn activates it locally.

Am I barking up the wrong tree with this? is it even a tree?

The relevant part of the spawn code is this....

Code (CSharp):

1. SpawnSpot mySpawnSpot = spawnSpots [Random.Range (0, spawnSpots.Length)];
2.                 GameObject myPlayerGO = (GameObject)PhotonNetwork.Instantiate ("PlayerShip", mySpawnSpot.transform.position, mySpawnSpot.transform.rotation, 0);
3.                 standbyCamera.SetActive (false);
4.  
5.                 ((MonoBehaviour)myPlayerGO.GetComponent ("PlayerControl")).enabled = true;
6.                 ((MonoBehaviour)myPlayerGO.GetComponent ("Shooting")).enabled = true;
7.                 myPlayerGO.transform.FindChild ("CameraCP").gameObject.SetActive (true);
8.                 myPlayerGO.transform.FindChild ("LocalShip").gameObject.SetActive (true);
9.                 myPlayerGO.transform.FindChild ("RemoteShip").gameObject.SetActive (false);

Any help on coding the updating of _GameMgr with "PlayerShip" and "CameraCP" would be truly appreciated!

You may notice that there is a "standbyCamera" being disabled there too...that is the "lobby" view where I have a menu interface and where you will go when waiting to respawn. At the moment, the radar is displayed on this camera too, which I don't want. If I have _GameMgr disabled until spawn, this won't be a problem, but for other instances, is there a setting on the camera to not render the radar etc?

Apart from all that, I am having issues running as single player. Obviously I'm having to manually update _GameMgr through the inspector once my player has spawned, but I don't think that is causing my problems.
1st, I'm getting bounds and target icons drawn in front of me when the objects are behind.
2nd, the arrows that point to offscreen objects are not moving.
3rd, the center arrow thing does not move either...not sure I want to include that feature anyway, but nice to know what is up with it.
4th, how do I get the distance text? I don't see anything in the inspector options of the scripts and maybe missed it mentioned here.

Anyway, I hope you can help with the network part and shed some light on the issues I'm having.

Cheers,
John

 

P.S.

When the target list is displayed, could you have whatever you have targeted be highlighted in that list?

Cheers

 

I am assuming this is the post about "Networking" you are referring too?

This is not about networking in a Unity sense. This was more of a feature for the Blind Radar option. Meaning if you cannot see a enemy but another friendly can and you can see said friendly then you too can see the enemy. It's more of a communications web or "Network" with your fleet. This never got implemented.

I'm not sure which camera your referring too. Can you post a page number or a quote? A new camera will not work for the Blind Radar Combat Area Radar Network. <--- Not a Unity networking feature.

Inside the FX_3DRadar_Mgr script "FX_3DRadar_Mgr.Transforms[0]" is where the player is stored. You can change this at anytime but it always needs to be assigned. If the _GameMgr exist before your player does and you have targets active, the simple thing would be to have a stand in player object that can assume this role while your player is loading. Once you player object is in the game world assign them to the Mgr script as the new player transform.

Same thing with the players camera.
"FX_3DRadar_Mgr.Cameras[4]" is where the players camera is stored.
"FX_3DRadar_Mgr.Transforms[2]" is where the players camera transform is stored.

The best / easiest thing as long as you know the name of the player and the name of the players camera is to change the FX_3DRadar_Mgr Awake() function.

Code (csharp):

1. Transforms[0] = GameObject.Find("_Player").transform; //Change this to your player name
2. Transforms[1] = GameObject.Find("_Radar2013").transform;
3. Cameras[0] = GameObject.Find("_RadarCamera").camera;
4.      
5.         if(!SetStatus[1]){
6.             Cameras[4] = GameObject.Find("_PlayerCamera").camera; //Change this to your players camera name.
7.         }else{
8.             Cameras[4] = GameObject.Find("CameraRight").camera;
9.             Cameras[5] = GameObject.Find("CameraLeft").camera;
10.         }

You will want to make sure that the player is first object loaded or active before the _GameMgr or any targets are added or enabled.

Remove the radar layers from the cameras culling mask.

1. Make sure the "_GameMgr" GameObject is fixed at world 0,0,0.
2. Are your objects with the FX_3DRadar_RID scripts enabled? If they are disabled then nothing will update on the screen so they will appear to be fixed.

I can force the icons to stay fixed on the screen and bounds to be rendered when the object is behind the player by having the FX_3DRadar_RID, but once enabled everything snaps back to where they should be.

Look in the "Example Scripts" folder. You will see a script named "Display Target Distance".

Yes that's a good idea.

You can download a C# version a few post up. It is much different from the JS version, and NAV Points are still missing at this point.

 

Cheers for that, I will look into the updating _GameMgr stuff later.

I wasn't referring to the Combat Area Radar Network, I was referring to a couple of posts made about multiplayer network. You replied to one saying something about each client would need copies of _GameMgr (could be wrong, 14 pages is a hefty thread to go looking for quotes). The same about the "camera" post...I'd have to read everything from the beginning again
None of that matters now really anyway as you've answered my question now. I am about to go out, so will look into it more later.
I grabbed the c# version before I knew there was any other version on the 1st post, but I didn't have a clue what I was doing with it. I then found the 1st post attachment and replaced. Something must have gone wrong though, as not even your demo scenes worked properly. Eventually I gave up. A few days later I decided to try again and re-downloaded the 1st post attachment and your demos were now ok, so I set about integrating into my project. I got as far as I could before the problems mentioned halted me.
I might have a go at trying the c# version again now I know what I'm doing a bit more.
You may as well know, I'm basing my project on the xwing/tie combat sims and would like to have had radar the same as those (forward and rear scanners), but being a total noob with scripting had to rely on tutorials and asking questions.
Needless to say, I got nowhere, especially with the multiplayer aspect. I had to have something though, as it doesn't take much to get totally lost in deep space
Your system is excellent though and definitely useable and I like the old "Elite" look.

I'll keep you posted to how I get on with the multiplayer side of this.

Cheers,
John

 

Now that I think about it the C# version requires a file from the oculus SDK. I'm working on a version that will not require this file. So hold off for a bit until I get this version up. It will also have NAV points once more.

This is something I have been thinking about as well and may become a feature.