Forum Discussion
'hmddbg camera on' not visible in shipping mode
Hi there,
I love the ability to make the view frustum visible and would like to use that as a hint if the user has lost tracking (currently looks like this):
(The grainy image is just a additonal hint for the user, should look like 'the signal gets weak')
Unfortunately this doesn't work in a shipping built anymore. Would it be possible to make this possible? Don't know exactly why this isn't working. The execution of console commands by blueprint nodes works, even if the console self isn't availably anymore. I can draw debug sphere's and lines, too....
Thank you,
spyro
I love the ability to make the view frustum visible and would like to use that as a hint if the user has lost tracking (currently looks like this):
(The grainy image is just a additonal hint for the user, should look like 'the signal gets weak')
Unfortunately this doesn't work in a shipping built anymore. Would it be possible to make this possible? Don't know exactly why this isn't working. The execution of console commands by blueprint nodes works, even if the console self isn't availably anymore. I can draw debug sphere's and lines, too....
Thank you,
spyro
5 Replies
Replies have been turned off for this discussion
- Yes, it is considered as a debug feature. It is assumed, that for shipping build you should do something more sophisticated. You can re-enable it for shipping by editing OculusRfit plugin source code (OculusRiftRender.cpp, search for DrawDebug, replace "#if !UE_BUILD_SHIPPING" by "#if 1")
- Ok, thank you, so I am at least able to hack this back in. ;)
But I don't know why you deactivated it alltogether?
How will this be handled in the future? Will there be a method like 'getTrackingFrustum' to use as a procedural mesh (new in 4.8) or something?
BTW: Yesterday I visited many students working on their own VR projects. Some of them didn't use the camera at all (!) others didn't give much attention to the limited tracking range. Most people who tried that were thinking that the tracking just isn't reliable or 'jumpy' when they were just out of the tracking space but didn't get any visual feedback about that.
Only a very minor part of the developers are integrating something like this by hand. They just don't care about that.
The best would be to integrate this directly in the composer.
Others were pushing UE4 to it's limited resulting in a constant framerate of 37.5 fps. People also thought that this is normal due to 'bad displays' and 'VR just needs some more time'. Why isn't the composer showing a hint like 'unsufficient framerate' or something when fps drop under the target framerate for more than X seconds in a row? How will this be handled in the future? Will there be a method like 'getTrackingFrustum' to use as a procedural mesh (new in 4.8) or something?
I was waiting for the procedural mesh to be released in 4.8 to do just that :) I create it dynamically based on the camera HFOV and VFOV then render a material when you get close. It seems to work well.If you've not already done it yourself let me know. I should have time to pull out the code and share it early next week.
I've posted my sample code on the Epic forum if anyone wants a starting point:
Sample code using 4.8 procedural mesh to show tracking bounds"jumbli" wrote:
I've posted my sample code on the Epic forum if anyone wants a starting point:
Sample code using 4.8 procedural mesh to show tracking bounds
That's - more than nice from you! :)- BTW: I build a simple replacement for this function, based on the one of https://github.com/mitchemmc/UE4FirstPersonVRTemplate:
You can find it here (too long to paste):
http://pastebin.com/BSgtJuZ8
(You will have to recreate all local variables as UE4 still can't repair/recreate them after copy/paste)
