Meant to be Seen

I just tried Dear Esther with the 1.0.5 rc1 build. I can confirm it works.

The default profile is not good though. You need to press F6 to swap eyes, then hold down F3 for around 5-10 seconds to get a good 3D effect.

Neil, you are THE MAN when it comes to 3D calibration. You've written several guides, and have a really good understanding of 3D. Would it be possible for you to set the default profiles for each game? This would give all users a solid starting baseline to tweak the game to their own eyes using the intuitive SHOCT tool without having to radically adjust settings by swapping the eyes and holding down an F key for 5-10 secs.

Also we seriously need to remap the F keys. Maybe using something like ins, home, page up, del, end, page down, or shift-Y shift-U, shift-I, shift-O, shift-P or some keys less common in games. I know there is probably a better system being developed for this, but a quick code change to remap the keys in the meantime sounds like it would be welcomed.

Loving following the development of this, and can't wait for my Rift! Keep up the amazing work guys!

Thanks for the kinds words.

I've been tweaking the games I already own and they are already included in the profile. So, the pre-existing Skyrim, L4D, L4D2 games should already have basic convergence set. I will double check, but this should be ok. Once Baristan6 gets his Rift, we will also be able to have start-up settings based on the hardware, so that should help too.

We have some ideas on how to make more game profiles readily available to users so it takes significantly less fiddling. Another build is in the works to overcome some of these challenges.

The game profiles config is just a text file. Maybe we should start a thread featuring excerpts of the config for games that still require basic settings in place?

Regards,
Neil

I pushed a separate branch (frameDumping) in my fork. I added a proxy that logs all the method calls to the IDirect3DDevice9 interface into a text file for x frames when you press page up. Not useful to anyone that isn't developing but it can help those developing to get an overview of what calls are being used by any given game.

I'm going to add proxys for most of the other interfaces that there aren't currently any proxies for over the next few days hopefully. Then I'll have a shortened list of methods I have to worry about for any given game by dumping frames out.

Methods with call counts for a single frame of Dead Rising 2. (processed the file in excel)

Interesting. Good luck with that man.

Sorry to make a feature request, but would it be possible to create a generic simple "mono" mode, which renders to texture, then copies to l/r buffers andaligns the images so the centr of the images is now at the IPD distance, then applies the warp. This done without doing any stereo fiddling and purely aiming to get high compatability (like the NTHUSim driver is likely to be).

This might sound like an odd request but I would rather be able to play a game looking correct, with everything at an infinite distance, than have lots of broken geometry.

I'm specifically looking at Dirt2 and 3 here but I'm sure it applies to others too. These games have a separate headtracking path which I've mentioned in another thread and all I'm really looking for is a way to at least play them with optical correction and head tracking.

(semi-related I'm going through the git code just now to see what might be done about the Dirt games and Borderlands 2, hopefully with some debugging i can track down the mangled transformation matrix)

mm0zct wrote:Sorry to make a feature request, but would it be possible to create a generic simple "mono" mode, which renders to texture, then copies to l/r buffers andaligns the images so the centr of the images is now at the IPD distance, then applies the warp.

Have you tried setting game_type to 0 in profiles.xml?

There is a mono mode. It's "game_type=0". However this will not look correct on the Rift since you need partial overlap. Maybe it's possible to shift the image in a shader, however then you will lose part of the screen (some gets cropped, some is not there to begin with). Either way it's not exactly ideal.

Thank you! That. Was. Awesome. I don't care if it was mono, but that's the first time I've been able to play a Driving game with a full immersive FOV and head tracking. The separation seemed fine to me, but my eyes are divergent when relaxed.

The shader does the partial overlap shifting in Vireio. Mono game type should work.

mm0zct wrote:Thank you! That. Was. Awesome. I don't care if it was mono, but that's the first time I've been able to play a Driving game with a full immersive FOV and head tracking. The separation seemed fine to me, but my eyes are divergent when relaxed.

I've been working on Dirt2. In the first scene out side the trailer there are over 150 different shaders running with multiple parameters. Some of them need to be modified by the normal method. Others should not be modified at all. A few rotate backwards for some reason... Currently I am identifying the shaders by their address in memory. Problem is the memory location changes each time the game is loaded. If there is another way to identify the shaders we could get dirt2 working properly.

Baristan6 wrote:I've been working on Dirt2. In the first scene out side the trailer there are over 150 different shaders running with multiple parameters. Some of them need to be modified by the normal method. Others should not be modified at all. A few rotate backwards for some reason... Currently I am identifying the shaders by their address in memory. Problem is the memory location changes each time the game is loaded. If there is another way to identify the shaders we could get dirt2 working properly.

How about..

Phase 1:
Intercept the CreateVertexShader calls.
--Save all the individual shaders data to files so you end up with a set of compiled shader files.

Phase 2:
Intercept the SetVertexShader calls.
--Determine which shader is being used by comparing the shader data to the files.
Make note of which shader is being used so you can make a look up table which tells you how that shader (in the form of the shader data) needs to be handled (normal/other/reverse/etc)
(^^ This will involve whatever method you are currently using to figure out which shaders are doing what.)

Normal operation then becomes:
Load look up table that maps shader data to handling method.
Create a collection that maps IDirect3DVertexShader9 pointers to handling methods.
Intercept the CreateVertexShader calls.
--Use the lookup table you created in phase 2 to match the shader data to a handling method.
--Add the shader pointer to the mapping collection.
Intercept the SetVertexShader calls.
--Use mapping collection to determine how the shader specified by the supplied pointer should be handled.


Edit: Thinking further, the above would probably work if the shaders are precompiled. If they aren't then the shader data could be different on different hardware. In which case you might be able to come up with something by intercepting the appropriate D3DX CompileShader/ AssembleShader type functions where the uncompiled shaders would be. Would probably get quite a bit more complicated.

hash the shader itself? or some bits of it at least? can you point me in the right direction for it in the virieo code? I'm happy to sit and tinker with it, i spend most of my working day staring at instruction traces anyway so I might be able to come up with something.

Or the above looks like a fairly reasonable approach. I assume the incorrectly rendered physics objects are getting their translation matrix done that's involved with the vertex shader.

I believe IZ3D would take a checksum of the actual shader and use that for identification.

Thanks to NikH for his Tracker Fix. I always just messed around in vireio for less than 5 minutes in each session since I couldn't stand the little tracking deadzone. However now I see myself actually playing games in this.

cybereality wrote:I believe IZ3D would take a checksum of the actual shader and use that for identification.

Yeah, I think you are correct. I've been reading around and I got that impression reading the IZ3D forum. It looks like Helix mod uses CRCs of the shaders to identify them as well.

Since I want to avoid the sequential rendering desync problem (thanks to those who are tackling it right now!), I've tried out game_type="0" in Mirror's Edge, Skyrim, and various Source Engine games. I do not have a Rift yet, but I am using "Oculus Rift" mode for my tests.

In the source engine games I've tried* using game_type="0" with 1.05 rc1 or the "Test Build" as of Apr 28 (this issue is likely also in earlier versions), the image is much brighter than it should be. Raising gamma in-game lowers it from that level of brightness, so even setting it at the darkest point (2.6 is the max, both in GUI and console), the image is still much brighter than the default brightness setting in normal rendering (I'm using numpad 0 to compare directly). I've tried turning on and off HDR, anti-aliasing, and color correction to see each have no effect on the level of brightness.

Mirror's Edge and Skyrim work perfectly (as far as my eyes can tell without a Rift - I'm aware of the shadow issue in Skyrim, etc.) in game_type="0." While stereo 3D would add a lot to the experience in the Rift, if it were a choice between the two, I'd much rather have a temporally-consistent image between my two eyes (and better performance, too, on my older system) than stereoscopic 3D.

*Black Mesa, Dear Esther, Garry's Mod, Half-Life 2 + both episodes. I own Portal 2 but do not currently have it installed, and I'm not willing to try it with CS:GO, as it may flag me as a cheater (I would/only play off-line with bots, but I'm afraid that even running the program with Vireio might get me flagged [even if that is absurdly unlikely]).

K701 wrote:Thanks to NikH for his Tracker Fix. I always just messed around in vireio for less than 5 minutes in each session since I couldn't stand the little tracking deadzone. However now I see myself actually playing games in this.

Glad to help out

Just tried beta 12 for the Oculus (previously I had used 1.04), just wanted to give 2 points of feedback, love the tool otherwise!

First of all, the increments for the adjustments are now much smaller, so small that they're hardly noticeable. I found it much easier to adjust in 1.04, now I'm often wondering if I've got the right function key pressed (since I can't see them with the HMD on). It's hard to see what's moving and even in which direction.

I also couldn't bring up the SHOCT calibrator because my laptop doesn't have a numpad (Alienware m11x). It would be great if there was an alternate way of using that.

Recheck your Vireio driver version. The build featured at the beginning of this thread may be later than what you have, and probably fixes these issues. Please confirm.

Regards,
Neil

cybereality wrote:I just tried Dear Esther with the 1.0.5 rc1 build. I can confirm it works.

The default profile is not good though. You need to press F6 to swap eyes, then hold down F3 for around 5-10 seconds to get a good 3D effect.

Thanks Cyber,

I have also go this working on SBS mode now. Reversed eyes then had to hold down F3 for around 10 seconds before I saw any separation. However once this is sorted out looks as good as 1.0.4 again. Not sure what has happened to the default profile in the version increment but glad all working again.

Thanks for yours and Neil's help with this.

Is there a key to get tracking working? I can't get it to work with any game in any mode.

I take it you selected "OculusTrack" from the menu?

I've tried all 4 of the options.

Do you maybe still have an application running that has control of the sensor? do the oculus demos work?

No nothing. The oculus room, tuscany and the first law unity demo all work fine it's (havn't tried anything udk yet since i can't get any demo's to install only the non rift udk).

Baristan6, I know you have much bigger fishes to fry but do you think it would be possible to modify Vireio's d3d9.dll so that it calls an .ini file with [PROXY] setting that would allow to load another dll ?

I went from around 40 to 60-65FPS in Vireio + Skyrim ENB just by playing around with mods, if I could add one more I know we could get even more FPS out of this, or maybe even play in high/ultra with constant 60FPS


Also I think this would have the following benefits:
-more possibilities for other games modding (Dishonored for ex) in Vireio
-one more loadable dll means one more FPS-specialized mod could be added to Skyrim, which means more FPS while still enjoying the updated textures and lighting effects
-possible to load Vireio's d3d9.dll first, which means less risk of breaking the 3D than when loading ENB first, then Vireio
-alot of people have to mess with the system 32 dll to get Vireio working with ENB without CTDing, maybe loading Vireio first would also resolve this

That would be very cool

Hi there! I've been browsing MTBS as a guest for a couple of months now, but decided now was a good time to sign up and contribute.
I'm a freelance developer with some spare time, so I've decided to contribute to Perception.

In regards to the proxy DLL request, I'll look into it and see if I can do it - shouldn't be too difficult

Philpax wrote: In regards to the proxy DLL request, I'll look into it and see if I can do it - shouldn't be too difficult

awesoooome \o/
yeah, I had a feeling it wasn't that much of a hassle but my coding years are a thing of the loooong past
I tried decompiling enb's dll to see how the proxy is inserted so I could insert it in vireio and recompile it, but didn't get far (3 windows errors, one crash, then I was like f*ck that sh*t I suck at coding anyways and grabbed a beer instead)

OmniAtlas over at the Developer Forums has added Oculus Rift "support" to Microsoft Flight Simulator X using Facetracknoir, and Vireio Perception.
Could you please add the Microsoft Flight Simulator X profile to the next release?

Profile:
<profile game_name="MS Flight Sim" game_exe="fsx.exe" game_type="0" separation="0.00358799" convergence="-0.02" swap_eyes="false" yaw_multiplier="25" pitch_multiplier="25" roll_multiplier="1" />

Been working on:

Rendering of both eyes on every frame.


Usefulness in an actual game at the moment:

Zero, still a lot of work to do. Hoping to have the Fixed Function pipeline stuff working reasonably in 2-3 weeks.


I've been smooshing together examples/tutorials from http://www.codesampler.com/dx9src.htm and using the result as a minimal test app.

What I have working

• I now have Mono side-by-side working with both sides being rendered every frame using Perception while running this test app.
• This invloves duplication of render targets (no support for render targets built with the CreateTextures yet) and duplication of drawing calls (only Clear and DrawPrimitive are done so far).
• Lost device recovery is working on alt-tab out and back (a good test to make sure all objects allocated in the default pool are being released properly. Took me a while to find the one object I wasn't releasing)

This is obviously still a long way from working with a proper game but I'm pretty confident I'm on a viable path.

Side Note: Perception + DX debug runtime + test app = mess of flashing colours. Ideas? I gave up trying to use the debug runtime to figure out a problem yesterday because of this.


What I still need to do

• Implement drawing duplication for the rest of the functions I haven't duplicated yet (though this is quick and easy)
• RenderToTexture textures may need duplicating and a proxy Texture needs to be created to facilitate this.
• Override GetBackBuffer to return the stereo backbuffer rather than the default
• Heuristics* for determining which render targets need duplicating. (going to start with the ones I've seen in various Nvidia 3D automatic presentations)
• Heuristics* will need to be overrideable on a game by game basis. Don't know what the best approach will be for this until we can figure out what might need overriding and how we can identify these objects.
• Something to do with viewport changes
• Plus much more I can't think of right now I'm sure.

Even more technicals:

• I've either moved up (into the main proxy class) or removed almost the entire contents of the Fixed proxy. This is the only proper concrete proxy subclass I've done anything with so far.
• Created proxies for surfaces and a stereo capable surface based on that.
• - These stereo capable surface proxies are returned by the device proxy to the calling application in place of any normal render target surface (even if we don't want to duplicate that particular rendertarget, they are returned as stereo surfaces in a mono mode).
• - Any time the calling application sets a render target we cast back to stereo render target and store the stereo render target in the device proxy. The device render target is set to the current active eyes target in the stereo pair.
• When drawing, the active stereo render targets are used to set the device render target to which ever eye we want to draw. Then the drawing is done, then we switch to the other eye and draw again.

Question:

What situation was causing the crash in StereoView initialization that required the addition of the delay? I've currently got it removed as it doesn't seem to make any difference and EndScene seemed a weird place for the init of StereoView to be happening.



References about Nvidia 3D Vision Automatic which have plenty of useful info on passive 3D in general :

1. http://developer.download.nvidia.com/wh ... _Guide.pdf
2. http://www.nvidia.com/content/GTC-2010/ ... TC2010.pdf
3. http://developer.download.nvidia.com/pr ... nd_Out.pdf
4. http://www.nvidia.com/content/PDF/GDC20 ... oscopy.pdf

2, 3 and 4 and variations on the same presentation given in different years at different conferences. The differences in each one contain the most interesting information.


*Lots of good starting places for Heuristics and discussion of overriding them in the Nvidia presentations.

Did a fresh install of windows on my old system, nothing on it except steam and the Vireio driver, still no head tracking in L4D2, Portal 2, Skyrim (havn't tried anything else)

@ChrisJD: I am not sure why the crash happens. It was a problem on many games, though. You should not remove the delay unless it is breaking something or there is a good reason to take it out (for example if you find the source of the crash the fix it). Thinking about it more it could have been related to device loss/recovery not working originally (but now it should work) so maybe the delay is no longer need.

I agree that EndScene() is a strange place to put the initialization, but I was just focused on getting something working. Feel free to refactor the code if you find a better way to do it.

@Endothermic: Does head-tracking work in official Oculus demos? Do you have a Logitech mouse? The Logitech software should be uninstalled since it conflicts with the head-tracking.

cybereality wrote:@ChrisJD: I am not sure why the crash happens. It was a problem on many games, though. You should not remove the delay unless it is breaking something or there is a good reason to take it out (for example if you find the source of the crash the fix it). Thinking about it more it could have been related to device loss/recovery not working originally (but now it should work) so maybe the delay is no longer need.

I agree that EndScene() is a strange place to put the initialization, but I was just focused on getting something working. Feel free to refactor the code if you find a better way to do it.

Ok, thanks, I'll keep that in mind. In my current working branch I moved the StereoView initialization so that it gets started up with all the other objects that I'm maintaining to handle the simultaneous rendering. It's not possible to have a delay there at start up with anything less than a thread sleep kind of wait (and it shouldn't be needed). It's all fully initialized after the actual device is created and before the device is returned to the calling application.

The same block of initialization code is used both at start up and on lost device recovery. From what I have read that seems to be best practise for device recovery and it is working OK.

Time will tell on the delay, when I have more of the code implemented to allow me to test with actual games. I'll test it across all the currently supported games if I even manage to get the whole thing working before thinking about sending a pull request to get it merged with the master.

Endothermic wrote:Did a fresh install of windows on my old system, nothing on it except steam and the Vireio driver, still no head tracking in L4D2, Portal 2, Skyrim (havn't tried anything else)

Silly question, are you running both the game and perception in administrator mode?

cybereality wrote: @Endothermic: Does head-tracking work in official Oculus demos? Do you have a Logitech mouse? The Logitech software should be uninstalled since it conflicts with the head-tracking.

Yes both the tuscany demo's, the oculus room and also the first law space demo all work fine. Yes I have a logitech mouse but it's only an M100 so it's just installed as an HID compliant mouse, there is no logitech software installed.

baggyg wrote:Silly question, are you running both the game and perception in administrator mode?

No I wasn't but I just have and there still isn't any tracking.

Is it possible to allow the distortion factor to be reduced in a way that doesn't greatly reduce the field of view? In HL2 I have to reduce it quite a bit to get things feeling right but it really reduces the usable screen space.

shiva wrote:

Philpax wrote: In regards to the proxy DLL request, I'll look into it and see if I can do it - shouldn't be too difficult

awesoooome \o/
yeah, I had a feeling it wasn't that much of a hassle but my coding years are a thing of the loooong past
I tried decompiling enb's dll to see how the proxy is inserted so I could insert it in vireio and recompile it, but didn't get far (3 windows errors, one crash, then I was like f*ck that sh*t I suck at coding anyways and grabbed a beer instead)

Done. As you said, it wasn't very difficult; just ran into a few strange issues along the way. Baristan6 should merge my changes into the main branch soon - when he does, simply add proxy_enabled="1", and proxy_dll="your/dll/path/here/some_d3d9.dll" to your game profile in profiles.xml, and it should all work.

ChrisJD wrote:

cybereality wrote:@ChrisJD: I am not sure why the crash happens. It was a problem on many games, though. You should not remove the delay unless it is breaking something or there is a good reason to take it out (for example if you find the source of the crash the fix it). Thinking about it more it could have been related to device loss/recovery not working originally (but now it should work) so maybe the delay is no longer need.

I agree that EndScene() is a strange place to put the initialization, but I was just focused on getting something working. Feel free to refactor the code if you find a better way to do it.

Ok, thanks, I'll keep that in mind. In my current working branch I moved the StereoView initialization so that it gets started up with all the other objects that I'm maintaining to handle the simultaneous rendering. It's not possible to have a delay there at start up with anything less than a thread sleep kind of wait (and it shouldn't be needed). It's all fully initialized after the actual device is created and before the device is returned to the calling application.

I agree that initialization in EndScene, as well as a frame-based delay, is not ideal. However, it's quite likely that appropriate initialization time is application-dependent; for now, a delay is probably the easiest method of ensuring there are no strange issues with disrupting the game's own initialization. Unless it poses an issue, probably best to leave it as-is for now.

Philpax wrote: Done. As you said, it wasn't very difficult; just ran into a few strange issues along the way. Baristan6 should merge my changes into the main branch soon - when he does, simply add proxy_enabled="1", and proxy_dll="your/dll/path/here/some_d3d9.dll" to your game profile in profiles.xml, and it should all work.

Does this mean that one could use the Helix d3d9.dll for shader corrections?

Afaik Helix' dll relies on nvidia's api and thus can't work for this. That said, the actual fixes for the shaders should be the same, so it should be possible to port them.