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

yes, it is changing "game_mgr" player faction from default "imperial" to "rebel", but target colours remain the same, as does the error.
I have to go out but I'll pm the network manager script when I get back in about half hour. Still doubt it will work with what I sent you before though.

 

No problem it's still about 6 hours before I get home, so take your time

 

Hey!

First of all: Thanks for the radar, it's fantastic!

Unfortunately we have some problems setting up the the target indicator. For some reason I can't see it on the edge of the screen (using Oculus with Pro Unity) - but it's working! Position is correct when I'm moving.
I can see it on the scene screen - it's just floating in the air (and 10 times bigger thank my game objects).

I attach a picture, maybe somebody already had this problem.

Thank you for the help in advance!

 

The screen edge target indicator icons are difficult to make work with the Rift. Because they exist on the edge of the screen which is outside the visible viewing area when wearing a Rift, the only way to see them is to adjust the screen edge padding amount to bring them in closer to the center. However depending on which version you are using this may not be an adjustable setting. Are you using the package download from the first post or the C# preview version that was posted a few pages back? Let me know and I can give you a solution to adjust this value when I get home from work.

Dont worry about the size. Because I am using a custom method to draw the HUD elements to screen space, objects will appear to be large (1 pixel in screen space = 1 unit in world space).

 

I'm using the one from the first post - the JS version.
We tried it again and we still only have enormous icons on the scene and not in the camera.

We are looking forward to solution, our school project really depends on it.

Again, thank you for the radar and your help - I'm super super thankful!

 

With the _GameMgr object selected, on the FX_3DRadar_Mgr script in the inspector switch to the Radar / HUD Dispaly Settings tab and you can adjust the Horizontal & Vertical Padding amounts. I think the defaults are 32 x 32 pixels. I dont remember off the top of my head if these affect the padding amount for all HUD elements or just the main target selection box. You can try to change these values to something larger like 200. Thats just a made up number but you can tinker with them and see what happens. I'll have better info for you later on.

 

Looking at the inspector now; I did include a separate padding amount for the screen edge indicators. FX_3DRadar_Mgr--->Radar HUDDisplay Settings--->HUD Indicators : Screen Edge Padding (Pixels)--->HUD Target Indicators. Setting the Horizontal & Vertical to a high number will pull the indicators into the center of the screen.

While this may give the desired result, I know that others have just turned them off when using a Rift.

 

Hi, I'm in the same project group as Wikh. Here's the problem as I see it. When we start the game the hud indicators render at 0,0,0 while our player (with oculus camera's) is moving around. Is there a way to render the HUD in front of the oculus camera by making it a child of the cameras? In sense, rendering the hud in local oculus space instead of world space.

Thanks in andvance.

 

Also is there a way that we could render the HUD on a plane? That way we could just render the plane in front of the Oculus Camera's that is a child of the oculus. That would solve all our problems

 

This is where they are intended to be by design. When this was originally made to work with the Rift (SDK 0.2.x) camera stacking was allowed. Meaning you could render cameras on top of each other. First thing is to check how your cameras are stacked & make sure that the HUD cameras have a higher depth order than the palyer cameras but a lower depth order than the Oculus cameras.

Create the cameras

1. Create two new Left / Right cameras for the player & child them to the Oculus Rift Left / Right Cameras. Set these cameras to render your gameObjects.
2. Remove all culling mask / rendering layers from the original Oculus Cameras so they render nothing.
3. Optional – Create two new Left / Right cameras to render the environment / Skybox. Because this is an infinite FOV you do not want any IDP applied to these cameras.

Remember to set the new cameras rect size & positions.

Set the camera depth order

At runtime you should have 4 groups of cameras with a depth order something like.

1. Environment / skybox camera : Depth -1 Renders only the Skybox / Inverted Sphere (preferred)
2. Player camera : Depth 0 Renders all the gameObjects in the enviroment
3. HUD camera : Depth 1 Renders only the HUD elements
4. Oculus camera : Depth 2 Renders nothing. Only applies LensDistortion to the rendering Stack.

However the Oculus team has changed the rendering approach with every SDK release and sometimes this approach works and sometimes it does not.

Unfortunately no. The HUD uses a screen space rendering approach that relies on Orthographic cameras to draw the elements to the screen. depending on which version of the Oculus SDK you are using you “should” be able to render the HUD cameras before the rift camera as described above.

The next release will utilize the 4.6 UI system which will allow the HUD to render directly to the Oculus cameras.

 

Hey!

Thank you again for your answer and help!
We are trying to make it work right now but I'm not sure if it will or not - will let you know about the result.

I'm trying to play with the layer / culling mask settings.

Do you have any other tips (before the future update) or these are all of the (possible) solutions?

Again, thanks for help and looking forward to any update on the project!

Edit: You mentioned the camera depth order: should we change that manually like a pro or leave it like that you created them in the script?

 

No, that’s the idea behind the workflow sense SDK 0.2.x. I had a working c# version that was based on this premise but Oculus kept changing the way the SDK worked so I just scrapped the entire thing and started working on the 4.6 UI version.

Unfortunately I have not done any Rift testing in a while so I'm not sure what works and what does not ATM. According to a few other users this method did still work as of something like two SDK releases ago. I believe one of the users mentioned they needed to stack multiple OVRController rigs instead of using just Unity cameras in one of these newer SDKs. Based on that you can try to import 4 OVRContorllers (I think that's what they are called) and sort there rendering depth and flags as mentioned in the previous post.

 

Thank you again, we will try to fix it. If we can't then we will look forward to the updated (4.6 UI) version of your radar.

Thanks for the help and for the radar system too (again)!

 

I can kind-of get it to work with SDK 0.4.4. I can get the depth order and culling mask to render everything the way it is intended but the HUD elements are rendering off center from their respected cameras.

You do need to use OVRCameraRigs for every camera, even the HUD cameras need to be replaced with an OVRCameraRig. Which meant modifying the FX_3DRadar_Mgr script to allow assigning custom HUD Cameras. but right now something is defiantly not right. I think it is because this JS version of the script is not taking into account the IDP values from the OVR scripts.

 

We had the same idea first.
So here we should createa an OVR camera instead of a normal one? Or we shouldn't modify the script like this because it wont work?
Cameras[2] = new GameObject("HUD / GUI Camera").AddComponent(Camera);
Cameras[3] = new GameObject("HUD / GUI Camera 2").AddComponent(Camera);

 

I discovered the trick. You just need to access the rendertextures of the OVR Cameras and you can use any cameras you want. I have it working. Mostly. The left camera is inheriting values from the right camera so I just need to fix that. Here you can see how i set things up.

Open this up in a new project. It has the SDK included. This was a very quick test just to prove that it can be done.

RiftTest

 

Hey!

Wow! Thank you very - very much! We are trying it right now - will post ASAP if it worked or not.

 

Like i mentioned it works and it doesnt. The HUD is way off like it is pushed down to the bottom left. I'm working on that. I'll post again when i get something figured out.

 

Also edit your script execution order to add the OVRCameraRig.cs to be above Default Time below the other OVR scripts.

 

We are trying to make it work - have to change a lot of our camera settings but no luck so far.Looking forward to any update!

 

I have been working with ForceX's radar system for some time together with the Oculus and have been using 4 OVR camera rigs on different layers...Actually now I think I have it dow to three. Anyway, I have been working with OVR 4.3.1 on Unity 5 beta and just downloaded OVR SDK 4.4 and will work with it tomorrow.

 

The issue is because the old SDK (0.2.x) which is what this was based off of, utilized two cameras which had a 1/2 rect sizes, with one cameras rect shifted to the left and the other cameras rect shifted to the right. Now it appears that all cameras use a full size unmodified rect. Because the math to calculate the screen position was based on the fact the cameras rects were only 1/2 the size and shifted means that the math is completely wrong for an unmodified camera rect and needs to be scrapped. I am having better luck with the C# version. The only issue i am having is the fact that the target selection box gets stuck 1/2 way up the screen. Duno whats up with that.

 

If you have some time and it's working for you (and if it has the target indicators) can you upload that version (as the RiftTest demo earlier)? We are not using the selection box - so it might solve our problems.

 

The screen edge target indicators use the same math as the target selection box so they dont work either. The only thing that does work is the target bounds indicator.


I'll look at it more tomorrow..

 

ForceX, thought you might find this from the Unity 5 beta forum regarding their plans for Oculus integration interesting:

"Here is a high level overview:

Instead of using OVRCameraRig (which contains one camera for each eye), you will use just one standard unity camera which will have some special properties when VR is enabled.

Having just one camera allows us to do rendering optimizations and has some benefits when creating an experience which can toggle VR.

There will be a global option to toggle VR. When enabled, some special things happen:

• Any unity cameras without a targetTexture will automatically render both eyes from the head tracked pose to the device.
  • Camera transform becomes the reference point for head tracking.
  • Actual rendered POV is based on the head tracked pose from the camera transform.
  • Head tracking does not affect the camera transform by default.
    • Scripts can replicate this functionality or a game object hierarchy for eyes, etc if desired. We will evaluate usage patterns during alpha and see what we should provide out of the box.
• Any image filters on the camera will occur on both eyes.
• Layering cameras works as expected.
• Pressing play in the editor gets you a judder free experience on the rift immediately (if your computer can hit the necessary framerate)

There will be a VR class which exposes parameters and functionality for the device if you want to go deeper with scripts (still WIP). The goal with this API is to be forward thinking so that VR experiences you build with Unity will work on future hardware without tweaking later. Some of these details may change in order to better align with this goal.

For now we are focused on getting a stable alpha build. Any feedback will be welcome during the alpha period, we will let you know when it begins."

 

@RowdyMrB : LOL!!! I just finished the first pass at getting the C# UI version to work with the two camera OVRCameraRig. That'll teach me

Here it is any way for anyone that wants to test it out.

1.Create 3 new layers UI_R, VFB, & RadarObject
2.Set the OVR Camera Left Eye Anchor culling mask to use the default UI layer
3.Set the OVR Camera Right Eye Anchor culling mask to use the new UI_R layer
4.Set the radar object to use the RadarObject layer
5.Set the radar camera to only render the RadarObject layer
6.Remove RadarObject from both the Left & Right Eye Anchor culling mask
7.In the FX_3DRadar_Mgr inspector assign the the HUD Canvas Right to be the new UI_R layer
8.Find the UI_Canvas_R in the CenterEyeAnchor and set its layer to be UI_R along with all the children.

Because the current Oculus requires a world space canvas in order to render, a custom shader is required that will ignore the Z test for all canvas UI elements, I have not gotten around to this yet.

Download FX_3DRadar_C#_Unity_4.6_UI(Alpha Preview)

 

Yea I thought you might want to know about it. I will give the above a try anyway. By the way have you tried the DK2 with Elite Dangerous? It is a good illustration of how it should be done. Works great and the graphics are slowly improving and with a HOTAS setup it rocks. Not sure I could play it without VR as I think I have got a big advantage when in combat with VR.

 

WOw..... you still plugging away at an Oculus Version... great to see

 

Yeah still at it...I get encouraged when I see what companies like Frontier (Elite Dangerous) do with the Oculus.

 

Oculus Unity update might help your radar sys.

New features include: layered camera support for cockpits !!!!

• Lens correction, TimeWarp, and dynamic prediction from LibOVR/VRLib
• Preview within the Unity editor
• Layered camera support for cockpits, UI, etc.
• Cross-platform support for XInput controllers
• Consistent IPD and head model for comfort at all world scales
• Utilities for locomotion, head-tracking, and Rift status
• On Windows, direct-to-Rift rendering with or without display driver

Is this of use ??

 

Is it of use to try the asset Java script to C# converter ? It does a great job from what I read during the discount 50% off asset store sale.

 

Man this all looks and sounds awesome. Is there a stripped down version though that doesnt include the oculus stuff?
I'd love to implement this into my little space game. Or maybe even an even more stripped down version? Don't need like team/faction control stuff.

But Awesome Work!

 

@J_Troher : Sorry but factions are a core feature of the radar system. As for Oculus if you are using the last official release from the top post then Oculus mode is optional and probably not functional with any oculus sdk greater than 0.2.x.

 

Is this free to be edited and put into commercial games?

 

Yes. In fact it is in use with NeonXSZ. I just ask for mention in the credits.

 

Hello, me again!
I got my project set up for the rift, but I get an error when running a standalone...couldn't switch resolution...anyone encountered this before?
Also, enabling the rift in the radar manager doesn't do anything, just can't see it....confused about the camera settings maybe?
I also upgraded to Unity 5 and I get some warnings about shadows or something in the radar scripts....without the rift it all still works though

 

The version that is available for download on the top post used the old 0.2.x Rift SDK and even then was only experimental. Sorry to say any SDK after the 0.2.x will not work.

Due to not owning a Rift and the numerous changes in methodology in developing for the rift, it is something i have given up on for the time being. Plus the current "In Development" version has been completely re-written from scratch in C# and uses the new Unity UI. I've been lazy the past 3 months not working on finishing the NAV / Mission system. Unfortunately it will not have Rift support. This version will strictly be a screen space based approach. In the future I do want to look at creating a world based radar similar to Elite / Star Citizen.

 

I finally got multiplayer respawning working, but now have another radar problem!
Player A destroys player B....player A radar now has an empty target (1 for each time player B is destroyed) and player B radar doesn't have any targets, not even the stationary capital ships.
I tried updating when respawning with the ChangePlayerFaction() function, but this doesn't change anything.

Any help again is most appreciated!

 

Dunno what I did, but player B has targets again. Still got the player A blank targets though. The big issue there is that with each blank, the fps drops significantly.

 

Well I am stupid for thinking that calling ChangePlayerFaction() with the respawning player would solve the problem for the other player! I obviously need to figure out the syntax for sending that call over the network.

 

When you destroy a target are you calling FX_3DRadar_RID.DestroyThis() from the object being destroyed? If not then you will be left with "Empty" targets that may cause Null ref errors which would result in FPS drops.

 

bloody hell I'm just stupid I forgot all about that! I'll investigate tomorrow. Cheers mate!

 

I'm messing around with things as I type, so I might solve it yet, but....

as you may remember, I have things instantiating in a cack handed way (Local & Remote gameobjects with ship dependent names). To call the DestroyThis function, I'm using

GetComponentInChildren<FX_3DRadar_RID>().DestroyThis();

If the ship is targeted and destroyed, the target box disappears but leaves behind the blip on the 3d radar and causes a blank if targets are cycled.
If the ship isn't targeted when destroyed, it leaves behind the bounds corners stuck in place and the radar blip and causes a blank when cycling.
Is using GetComponentInChildren the wrong thing to do? Getting the actual name of the target object is very confusing for me.

 

ok, I realised I was already getting the Remote object to instantiate the main explosion, so DestroyThis is now being called as per your readme but the problems are still the same.

edit...

I also get spammed with this....

MissingReferenceException: The object of type 'Transform' has been destroyed but you are still trying to access it.
Your script should either check if it is null or you should not destroy the object.

clicking on the errors highlight various objects that have the RID attached.

 

Here are the two scenarios I can think of.

1. When you are running multiple clients Client A (You The Player) & Client B (Someone Else). If DestroyThis() is called on Client B only Client B is clean, but on Client A side only the gameObject was destroyed leaving all the component references intact. This means that DestroyThis() needs to be called on all clients for an object being destroyed and not just one.

I have no multiplayer coding experience so I’m not sure how to perform this efficiently. But it seems that the server should send a message to the clients to call the DestroyThis() on the gameObject being destroyed.

2. You have other scripts still needing access to a component on a destroyed gameObject. These will need to be cleaned up when DestroyThis() is called too.

Remember DestroyThis() in a single client environment will destroy the object in question, it will also destroy the radar graphics and the bounds graphics & then it will rebuild the target list for the Player and AI. This cleans up any component references to any targets. The changes made by DestroyThis() will not cascade to other clients; so you will need a method to do this.

 

I thought it would have to be called across the network. I shall look into how.

So DestroyThis() also destroys the ship object? I've obviously sorted out NetworkDestroy to handle that, so if I'm NetworkDestroying the blown up ship, Destroythis() will have no ship to destroy and therefore no radar stuff to destroy?

 

Not sure if any of it worked. I just made the DestroyThis() get called over the network before the NetworkDestroy. The ship will blow up and the bits stay floating off into space forever. The ship isn't being destroyed at all.
I'll look into it more tomorrow before my brain melts

 

Yes DestroyThis() will destroy the gameObject that the FX_3DRadar_RID script is attached to. If need be you can if you have not done so already is remove the line where it destroys the gameObject and let your network code take care of this part.

 

Yeah I tried that...same thing, ship not being removed at all.

Code (CSharp):

1. RemoteGO.GetComponent<PhotonView>().RPC("DestroyThis", PhotonTargets.All);
2.                         PhotonNetwork.Destroy (gameObject);

That's in the shiphealth script.

Code (JavaScript):

1. @RPC
2. function DestroyThis(){
3.     if(!IsNAV){
4.         Destroy(BoundsCorners);
5.         FX3DRM.RemoveFromList(ThisID[0]);
6.     }
7.      
8.     Destroy(ThisID[1].gameObject);
9.     Destroy(ThisID[2].gameObject);
10.     Destroy(ThisID[3].gameObject);
11.     Destroy(ThisID[4].gameObject);
12.     if(FX3DRM.SetStatus[1]){
13.         Destroy(ThisID[5].gameObject);
14.     }
15.  
16.     if(IsPlayerTarget){
17.         FX3DRM.ClearTarget();
18.     }
19.  
20. //Destroy(gameObject);
21. }

and that's the DestroyThis code.

I have no idea why the ship is not being destroyed at all now even if I did the RPC stuff wrong (no errors) the ship should still be destroyed with PhotonNetwork.Destroy, but it isn't.

 

Well, I wanted to try PhotonNetwork.Destroy in your script but it seems I have to extend your 3DRadar_RID script to use Photon.Monobehaviour but I can't for the life of me extend it, even following answers from unity answers and exitgames etc. I just get an error saying I can't. I ended up breaking Photon big time and had to re-import it all again. I think I'm back to where I was now.
Oh well, bed time...fresh mind tomorrow and try something else :S