4.4.1: Anyone able to run 'Minimum Default' without judder?'

"spyro" wrote:

"artyom17" wrote:
What do you see if you use 'stat fps'?

I am not able to see any stats when in Rift mode. They are only visible in the viewport of the editor which can't be sent to Rift for some reason. I have to start the game as standalone for this - and all the stat information seems gone.

When I reactivate mirroring I am able to see the stats partly on the right edge of the screen in Rift Mode.
(EDIT: 'stat fps' seems ok, the problem remains with 'stat unit'.)

The values change very fast but they go never over 60 fps. When using 'stat unit' I can clearly see that the render time for each frame is between 16 and 17 ms. So it seems to be a bug with the Direct HMD Mode implementation. The game locks on 60 fps.

Here are my project's frame rate settings:



In the editor's viewport it runs with a much higher framerate without problems, so it's no general frame lock:
http://s1.directupload.net/images/140828/g87aqltu.png


spyro

You need to package as the Development build, rather than Shipping, in order for the console to work in a stand alone game.

I would also suggest adding a PostProcessVolume and turning most of the effects off. There are some that cause real big hits on the Rift.

"artyom17" wrote:

You need to package as the Development build, rather than Shipping, in order for the console to work in a stand alone game.

I would also suggest adding a PostProcessVolume and turning most of the effects off. There are some that cause real big hits on the Rift.

Thank you, but that's actually not my problem (never used the shipping config so far). Does that mean, that all Blueprint-injected console commands will also not work when I ship my game? Could you go into details about particularly expensive effects? Temporal-Antialiasing is absolutely critical for me, it is (besides TXAA) the only Anti-Aliasing solution so far which solves the terrible pixel crawling effects in motion which are especially ugly when viewed through the Rift because of its low local resolution.

I am still hoping that there is some serious timing issue as the "minimum default" scene is already reduced to the max in terms of geometry, lights and so on. It can't be normal that UE4s performance with default configuration is really that bad...

spyro

"spyro" wrote:

"artyom17" wrote:

You need to package as the Development build, rather than Shipping, in order for the console to work in a stand alone game.

I would also suggest adding a PostProcessVolume and turning most of the effects off. There are some that cause real big hits on the Rift.

Thank you, but that's actually not my problem (never used the shipping config so far).

I don't understand why you were unable to open the console to issue the stat fps command in the packaged/standalone mode, then. If you were using a standalone game, the console will only open up when pressing ~ (tilde) if the game was packaged as a Development config.

Does that mean, that all Blueprint-injected console commands will also not work when I ship my game? Could you go into details about particularly expensive effects?

No, you only need a Development build (which can still be packaged) if you want to be able to bring up the console. Commands still work - you just can't enter them manually since hitting ~ (tilde) does nothing.

Temporal-Antialiasing is absolutely critical for me, it is (besides TXAA) the only Anti-Aliasing solution so far which solves the terrible pixel crawling effects in motion which are especially ugly when viewed through the Rifts because of its low local resolution.

This one seems really weird to me, because even on monitors, TXAA causes terrible pixel swimming effect. Turning it off is the recommended setting for the Rift.

I don't understand why you were unable to open the console to issue the stat fps command in the packaged/standalone mode, then. If you were using a standalone game, the console will only open up when pressing ~ (tilde) if the game was packaged as a Development config.

That was because the preconfigured console key '~' doesn't work on non-US keyboards (that issue is ignored for years now). I didn't know how to change that (I was able to solve that for my own project in the meanwhile).

No, you only need a Development build (which can still be packaged) if you want to be able to bring up the console. Commands still work - you just can't enter them manually since hitting ~ (tilde) does nothing.

Phew, thank god. ;)

This one seems really weird to me, because even on monitors, TXAA causes terrible pixel swimming effect. Turning it off is the recommended setting for the Rift.

I haven't seen a TXAA demo through the Rift, but it looks absolutely superior on PC monitors (comparison https://mega.co.nz/#!2BRH0YSJ!GBkOsg3Hu8G0t5gw2YsuTWUDd4gNfBVmqHOCnogu-rw).

The temporal anti-aliasing in UE4 gives fantastic results so far (see https://mega.co.nz/#!nNY1kapJ!y8Tp8oH4qEMeXA3253-k_F66DGZSeIzU-wu8cCFwy5I). In VR, the effect is even more dramatic (tried with 'Mobile Temple'). Nearly all he pixel crawling is completely gone, it looks almost comparible to supersampling. Maybe I'll make a small demo where you can toggle it ON/OFF for everyone trying it out yourself.

spyro

I have exactly the same problems.. same scene no way to get anything remotly usable..

My hardware: i7 3770K @ 3.50Ghz with 16Gb ram and a AMD Radeon 7950

I know not that highend but it can run all kind of 'not' ue4 content pretty fast

My feeling is 'direct' mode as it is currently implemented by UE4 is really way more 'performance' penalty then 10% and very unstable..

There must be some bug somewhere that is making it all perform so bad.

"spyro" wrote:

I haven't seen a TXAA demo through the Rift, but it looks absolutely superior on PC monitors (comparison https://mega.co.nz/#!2BRH0YSJ!GBkOsg3Hu8G0t5gw2YsuTWUDd4gNfBVmqHOCnogu-rw).

The temporal anti-aliasing in UE4 gives fantastic results so far (see https://mega.co.nz/#!nNY1kapJ!y8Tp8oH4qEMeXA3253-k_F66DGZSeIzU-wu8cCFwy5I). In VR, the effect is even more dramatic (tried with 'Mobile Temple'). Nearly all he pixel crawling is completely gone, it looks almost comparible to supersampling. Maybe I'll make a small demo where you can toggle it ON/OFF for everyone trying it out yourself.

spyro

I might be thinking of the per object motion blurs then, but I kept seeing people having issues with TXAA on the Rift.

I know what it's supposed to do, I had just seen reports that it caused problems - if that's not the case - heck yeah!

A few things,

Im fairly sure the console key can be changed in project settings.

And just to make sure your aware that the scalabity settings in the editor have no effect on a standalone game and only effect the quality in the editor viewport.

You can change these settings with console commands via blueprint. i.e "sg.postprocessingquality 0" , "sg.shadowquality 1", "sg.effectsquality 1" ect.

The other problem being is that when you switch to vr mode all of those setting are reset back to epic mode so there is no point putting them in an <EventBeginPlay> and you are best binding them to a key via blueprint in the meantime.

And for anyone who hasnt read it heres Epics reference to scalabilty.

https://docs.unrealengine.com/latest/INT/Engine/Rendering/Scalability/index.html

edit* forgot to add "HMD Mirror" will toggle mirror mode.

Ok, I messed arround for about 3 hours now. I simply don't get the scalability settings right.
Epic describes them as follows: https://docs.unrealengine.com/latest/INT/Engine/Rendering/Scalability/ScalabilityReference/index.html

But there is not described HOW TO APPLY this settings actually. There seem to various amounts of INI-Files (not available when launching from editor), there are 'quick settings' in the Editor (seems discarded when packaging the game), there are Blueprint-injected console commands...

Can anyone please give me a quick advice where exactly I have to store the quality settings of the game in a reliable way so that they work from the Editor/new Window and In-Game?

And is it normal that the in-editor version (new window) runs so slow compared with the packaged or 'launched' version of the game (about about 30% faster)?

spyro

(BTW: The picture in the Rift does not update and freezes often when working with the console 'hmd'-commands. I am the only one with this problems?)

"spyro" wrote:

Can anyone please give me a quick advice where exactly I have to store the quality settings of the game in a reliable way so that they work from the Editor/new Window and In-Game?

Sorry I cant help on tht one as ive not looked into that yet myself.
Rarther than worrying about Unreals ini files why done you create your own and read write to that.
I believe thats what the guy who created the VR templates does.

Have you thought about use this plugin?
Ive yet to give it a try myself.
https://developer.oculusvr.com/forums/viewtopic.php?f=60&t=12486

"spyro" wrote:

And why does the in-editor version (new window) run so slow compared with the packaged version of the game (about about 30% faster)?

Im not sure as I currently cant create a stanalone game with my build of 4.4.1 due to some bug.
youve not got 'Realtime' checked in the editor have you?

"spyro" wrote:

(BTW: The picture in the Rift does not update and freezes constantly when working with the console, anyone else?)

Nope seems fine for me.

Good new is it looks like Epic are serious about improving there VR performance. I was search google for any interesting docs on engine optimizations for VR and came across this.

http://www.linkedin.com/jobs2/view/11649449

Im not sure if thats an open position still or there still looking but its nice to see they will have at least one person dedicated to VR performance.

Plus I notice an Enum in there HMD code for the Morpheus as well as the Rift so there preparing to support sony in the future which mean there seriouly going to have to focus on VR performance to do anything remotely usable on the PS4.

FYI: The standalone version seems faster because the editor in the backgrounds eats all the CPU performance when the game is started in the foreground ADDITIONALLY to the game itself. That's particulary strange as the load of the editor seems much higher in this situation.

Long story short:



Boom, judder is gone, performance is about the same as with the packaged version. Please remind that you have to redo this setting in every project (it resets itself each time). Why the hell isn't this the default setting?!

spyro