New VR Features.

[SkateZilla]

I can't even quote each single sentence.. but this is all wrong and no sense. The single pass rendering has nothing to do with split frame rendering and the viewports introduced by VRWorks is nothing like what you wrote above.

May you please get the proper documentation and the sample codes to figure out what's this about? You are mixing the dx calls with the VRWorks API that happen at driver level.

 

I Did not say that at all, What I Said was:

 

Multi-Projection, VR-SLI have all been done before, by both nVidia and AMD.

 

VR-SLI, The Use of One GPU to Render Each Eye (either SBS or OU Format), has already been done and failed because it was not used for VR, but a single large resolution screen, but the function remained in the drivers of both nVidia/AMD, AMD Disabled them, I believe SFR was still a selectable Option in nVidia's Drivers when I Ran an 8800GTS Setup.

 

This SLi/Xfire Mode was and still is called, Split Frame Rendering (SFR). Which was available to Some Titles in DX9.

 

It had it's share of issues, and back in DX9 was supposed to be used to eliminate the Microstutter/judder/latency of Alternate Frame Rendering (AFR), which became more or less the standard. So SFR Was left undeveloped since then, AMD and nVidia Both Used it in their Professional Platforms Drivers Though to allow Content developers to render using SFR if they wanted.

 

Now w/ VR and the 2x 3D View port Alignments (SBS, Side By Side) and (OU Over/Under),

Splitting the Screen space in 2 and Having Each GPU Render Half becomes a efficient way to render the scene,

Each GPU will be responsible for its own Eye and will render each frame directly to each eye, Removing the Latency of AFR, while Increasing Per Eye FPS

 

That's Split Frame Rendering

 

nVidia now Calls it VR-SLi

AMD Now calls it Affinity Multi-GPU

 

 

 

Single Pass Stereo, as nVidia has Labeled it, uses a developed instruction block of the PolyMorph Engine in the GP10x GPUs,

 

AMD and nVidia BOTH did this before in the mid 2000's, however, since VR wasnt around, there was limited use for it, and both Companies didnt develop it further.

 

I'ts not new, and I suspect it will have the same problem they had w/ it before, especially in LARGE SCALE Environments, where depth fighting typically occurs, etc.

 

Vertex Processing is not a Bottleneck in the EDGE Engine, w/ SP-VR, everything is still being done twice, except Vertex Processing.

 

Literally Every Feature inside the VRWorks API/Toolkit, AMD has inside of their LiquidVR Kit, the only difference is one is setup to send commands to nVidia GPU's while the other goes to GCN GPU's.

 

BOTH use the same DirectX Functions already Present in DX9,10,11,12, VRWorks Just talks to GP10x GPUs, while LiquidVR talks to GCN/AMD.

 

It just makes it easier for the developers to code for a specific GPU Family.

 

 

My Original Quote is Here:

Multi-Projection, VR-SLI, VR Works Audio, etc Have all been done way before VRWorks.

 

Split Frame Rendering is not New...

Dont know why everyone is going Gaga over VR-SLI, it's Split Frame Rendering.

DX11 and 12 both support it at it's core, you dont need VRWorks to Program Split Frame Rendering for SLi or Crossfire.

 

Multi-Projection / Single Pass Rendering is not New

is also an Advanced DX11/12 Command Set already Part of DirectX's Capabilites.

 

Multi-Projection is simply a DX Command Set that uses their PolyMorph Engine Instruction Block of their GPU, an Instruction Set that's also on GF10x, GM10x and GK10x

They Simply didnt care about using it for SinglePass Stereo/MP at the Time because VR was no Mainstream, the PolyMorph Engine Block had other functions (Tessellation).

 

VRWorks Audio is not New,

XAudio, True Audio, Aureal 3D Audio, DirectX 11/12 Audio all do the same thing.

 

 

So, AMD's GPU's Can All of the Above without VR WORKs API, Using Simply The DirectX, Vulkan/OpenGL, or Now Discontinued Mantle API, Which Means nVidia's GPU can do them without the need to use their Proprietary API.

Edited June 7, 2016 by SkateZilla

[npole]

BOTH use the same DirectX Functions already Present in DX9,10,11,12, VRWorks Just talks to GP10x GPUs, while LiquidVR talks to GCN/AMD.

 

It just makes it easier for the developers to code for a specific GPU Family.

 

Great, let's use it then! :)

 

...and vertex aren't a bottleneck in EDGE? Then you should explain to me why the fps in VR are inversely proportional to the objects rendered.

Edited June 7, 2016 by npole

[SkateZilla]

DRAW CALL OVERHEAD.

 

And if the ED Team can code their own engine from scratch, I doubt they'd need Shortcut API's.

[npole]

DRAW CALL OVERHEAD.

 

And if the ED Team can code their own engine from scratch, I doubt they'd need Shortcut API's.

 

DCS uses a very limited assets type, the draw calls shouldn't be an issue at all, where did you read that this is currently a problem? I may have missed the developers posting about this issue. Also this won't explain why the performance are degraded even with off screen objects rendering.

 

The API aren't shortcuts, they are libraries, every game uses it, including DCS, it's not that designing your own engine you gonna do low level programming interfacing it directly with the drivers and the graphic card.

 

I think the discussion ended in a circle at this point, the developers will look at VRWorks if they'll figure it's going to give us an advantage.

I think most people (including me) aren't much interested about the reason (or the politic) behind it, we want to have a better performance in VR.

Thanks.

[SkateZilla]

Draw Call Overhead is the common problem of every Simulator that has a Large Scale battlefield w/ Thousands individual objects being rendered within it and withing visual range.

I'm not talking Battlefield 3/4, I'm Talkin DCS, FSX, ArmA II, ArmAIII, etc etc.

 

DirectX has an Upper Ceiling for how many Draw Commands it can process, anything above that limit Affects stability and CPU overhead,

Which Affects FPS, Rendering Errors, GPU Utilization etc.

 

-DX9c Was Designed to handle an Upper Limit of 5K (5000)

(Above the 5K Ceiling, the GPU Usage would Drop Drastically along w/ the Frame Rates)

 

-DX10 Had a Similar Upper Limit of 5-6K (5,000-6,000), was a bit more forgiving if pushed past the limit

(Above the 5-6K Ceiling, the GPU Usage would slowly drop, FPS would also drop, but not as Steep as DX9c)

 

DX11 was Designed to handle around 10-12K (10,000-12,000), was still more forgiving when pushed

-Some games pushed 20K Draw Call stable, just locked at 30Fps Internally),

-Above the Limits w/o Governing was still forgiving depending on how hard it was pushed, some games pushed 50-60K Draw Calls, but would have severe stability issues, other games would push the limit but w/ decreased FPS in those instances.

 

DX12 was Designed to handle 600,000K+,

-and even then, nothing has come close to testing it, so the limit hasn't actually been tested to see if it could be higher.)

 

Seeing the Pattern Here?

 

Now, Every Object (Aircraft, Weapon, House, Building, Fence, Tank, AI Civilian Traffic, Ships, Tree, Bush, Texture Sprite, Terrain Section, Road, Rail Road, etc, etc etc) is a Draw Call.

 

Calls for objects can be grouped, but grouped calls have an entirely different effect on FPS, other engines have stupendously low visibility distance to avoid going over any limits.

 

Bottom Line, If you tried to Run the Current NTTR Map on DX9c, you'd likely crash out everytime, the amount of objects over Vegas are likely up there, and likely past any safe margin for DX9.

 

 

If you search the forums hard enough w/ the right keywords, you'll find the posts in 2011 or so detailing the reason for the decision to go w/ DirectX11.

 

To Give some Scope:

The Draw Call Limits Between DX11 and DX12, and how they effect Rendering

 

Edited June 7, 2016 by SkateZilla

[funkyfranky]

Keep going guys! I'm learning a lot ;-)

No seriously, very interesting read!

[npole]

Draw Call Overhead is the common problem of every Simulator that has a Large Scale battlefield w/ Thousands individual objects being rendered within it and withing visual range.

I'm not talking Battlefield 3/4, I'm Talkin DCS, FSX, ArmA II, ArmAIII, etc etc.

 

Right, while Arma (or FSX, or Prepared, or XPlane) have to manage with an enormous asset, this issue in DCS is not existent: games with non uniform scenarios and object cannot optimize the draw calls (imagine FSX the whole world to cover); while a game with uniform scenario and a limited number of assets (like DCS), normally applies certain procedures to reduce the draw calls, that's is why I'm surprised that it could suffer of a similar problem, unless there's something wrong in the engine.

 

Actually it is dropping from 90fps in a random hangar to 18fps by just turning the head right and left... and this can't be just because of a draw calls overhead, unless you're rendering the whole world object in a given direct and apply to each of those object a different texture without taking in account the ambient occlusion.

 

It's clear that DCS engine suffer by some code optimization, and we are waiting the engine to be fixed (they should seriously look at the DX12) ...and the current situation makes even more obvious the needs of alternate solution to deliver a better performance in VR.

 

As I mentioned in a previous post... while playing on a monitor you would just notice some poor fps, in VR if those fps goes below 45fps, the game became unplayable.. it's not just, it looks bad, it's completely unplayable because of the jitters/ghosting.

 

If you are confident that the same results can be obtained without using VRWorks... the hell, do it! Call it TRUMPWorks, we don't care, the VR squadron is looking for better performances, nor that we care if it's done by nVidia, AMD, or whoever else.

[DerekSpeare]

...

 

Actually it is dropping from 90fps in a random hangar to 18fps by just turning the head right and left...

 

...

 

As I mentioned in a previous post... while playing on a monitor you would just notice some poor fps, in VR if those fps goes below 45fps, the game became unplayable.. it's not just, it looks bad, it's completely unplayable because of the jitters/ghosting.

 

If you are confident that the same results can be obtained without using VRWorks... the hell, do it! Call it DUMPTRUMPWorks, we don't care, the VR squadron is looking for better performances, nor that we care if it's done by nVidia, AMD, or whoever else.

 

Hopefully in time ED will really have DCS running like a military level simulator with VR, and I think they will. It might take a few more years, but I've waited 20 years just for CV1 and this, so it's ok. I think they are fully aware of the demands on optimization that VR creates.

[hansangb]

must....have Direct12!!! Holy cow...what a difference.

[SkateZilla]

must....have Direct12!!! Holy cow...what a difference.

 

it's what happens when you take away the Driver Layer (or as I call it "compatibility layer") that is DirectX, and send all the GPU instructions Directly to the GPU with little to no chaperoning done by DirectX.

 

ps You can thank AMD for that too.

[SkateZilla]

Right, while Arma (or FSX, or Prepared, or XPlane) have to manage with an enormous asset, this issue in DCS is not existent: games with non uniform scenarios and object cannot optimize the draw calls (imagine FSX the whole world to cover); while a game with uniform scenario and a limited number of assets (like DCS), normally applies certain procedures to reduce the draw calls, that's is why I'm surprised that it could suffer of a similar problem, unless there's something wrong in the engine.

 

There's ALOT going on in DCS, other Sims load and unload items into the memory as they get within a certain or extended distance, that's how it manages everything for the player.

So when you start up in NAS Oceana, you're not gonna load the textures for NAS Fallon, nor the objects or Radio Beacons etc.

 

The Lag when Loading textures sometimes just by jumping to external and back to cockpit is actually kinda annoying in FSX.... but that's the way it is.

 

 

 

 

Actually it is dropping from 90fps in a random hangar to 18fps by just turning the head right and left... and this can't be just because of a draw calls overhead, unless you're rendering the whole world object in a given direct and apply to each of those object a different texture without taking in account the ambient occlusion.

 

.

 

What airfield were you at, not 100% sure, but When you look left, it will still render objects outside of the hanger even though you cant see them directly. *supposedly*

 

So if you look toward a massive city w/ plenty of objects etc, it's gonna dip, should NOT dip that bad though.

[Milopapa]

Well, I can confirm I also see some funny stuff with FPS.

 

I tested a lot with one of the P-51 missions in the Openbeta and sometimes when I look at a certain place (mountain range with sun and water reflections) it will give me 90fps, then I look away (or at the dashboard) and when I look back at the exact same place, it will go down to 45, no matter what I do.

This would also happen the other way around.

And yes, sometimes even looking at an empty blue sky (zero objects to draw) will not give me 90fps.

[Wags]

Hi all,

 

A little update that I'll talk more about in this weekend's live stream:

 

1- Added VR zoom toggle

2- Added ability to map VR view re-center to a controller (not just Num5)

 

Thanks

[Kayos]

Hi all,

 

A little update that I'll talk more about in this weekend's live stream:

 

1- Added VR zoom toggle

2- Added ability to map VR view re-center to a controller (not just Num5)

 

Thanks

 

Awesome :)

[SageOT]

Awesome news! Thanks Wags.

 

Sent from my SCH-I545 using Tapatalk

[Milopapa]

Hi all,

 

A little update that I'll talk more about in this weekend's live stream:

 

1- Added VR zoom toggle

2- Added ability to map VR view re-center to a controller (not just Num5)

 

Thanks

 

What about the other features you talked about last time (pixel density, mouse control etc)?

When are they released to Openalpha?

 

thx

[AstroEma]

Hi all,

 

A little update that I'll talk more about in this weekend's live stream:

 

1- Added VR zoom toggle

2- Added ability to map VR view re-center to a controller (not just Num5)

 

Thanks

 

And what about us Vive users? Is DCS an Oculus only program?

[cichlidfan]

And what about us Vive users? Is DCS an Oculus only program?

 

Where did Wags specify a headset? I am pretty sure the Vive is a VR device, too.

[AstroEma]

Where did Wags specify a headset? I am pretty sure the Vive is a VR device, too.

 

I know, I am just being provocative. :)

I'd like to know when Pixel Density will come to the Vive.

[hansangb]

Does Vive support that? Also, do keep in mind that DCS supported DK1. LONG before Vive was even announced. So you have to give them some slack in terms of nomenclature.

 

cichlidfan, I think Wags did mention he was using the Rift.

[dennya]

Is there a way to toggle VR off in the current version short of unplugging the Oculus? I'd like to run on the main screen while setting up some controller configs for various planes, and then re-enable VR.

[SageOT]

Is there a way to toggle VR off in the current version short of unplugging the Oculus? I'd like to run on the main screen while setting up some controller configs for various planes, and then re-enable VR.

 

Uncheck "Auto detect Oculus Rift" close the game and restart. When ready to go back to VR, check the box and restart. That's the only way I'm aware of for now.

[whitav8]

Simply turn off the Oculus and then restart the game

[cichlidfan]

Simply turn off the Oculus and then restart the game

 

Your's has an off switch?

[Frusheen]

Anyone know when Wags is doing his live stream?

 

EDIT: Disregard. Found it.

Edited June 12, 2016 by Frusheen