Biclops - Open RIFT-Compatibility layer
-
- One Eyed Hopeful
- Posts: 34
- Joined: Wed Jun 13, 2012 11:16 pm
Biclops - Open RIFT-Compatibility layer
What does it do?
[youtube]http://www.youtube.com/watch?v=TjV0jLVC9MU[/youtube]
Mainly, it will do side-by-side 3D stereoscopy, and barrel warp the resulting image to adjust for the RIFT's optics. (So far, the latter is just based on screenshots gleaned from John Carmack's E3 experiments.)
What does it support?
Not a lot, yet. I've tested it with Skyrim and Mirror's Edge so far, but it's really alpha right now. UI's can be pretty weird, Skyrim needs its shadows disabled entirely, etc.
Where can I get it?
NOTE: This uses very similar techniques to intercept the DirectX layer as many common online cheats. I'm not doing anything special to hide myself from VAC or PB or GameGuard, so it's entirely possible that those systems would flag this as a cheat. Use with multiplayer games at your own risk!
You can download pre-compiled versions for the above two games at https://github.com/josh-lieberman/Biclops/downloads, or check out the source code at https://github.com/josh-lieberman/Biclops.
What can I do?
At this stage, there's probably more bugs than not, but play around with it--if you have 3D programming experience feel free to play with the source too. More supported games would be great.
[youtube]http://www.youtube.com/watch?v=TjV0jLVC9MU[/youtube]
Mainly, it will do side-by-side 3D stereoscopy, and barrel warp the resulting image to adjust for the RIFT's optics. (So far, the latter is just based on screenshots gleaned from John Carmack's E3 experiments.)
What does it support?
Not a lot, yet. I've tested it with Skyrim and Mirror's Edge so far, but it's really alpha right now. UI's can be pretty weird, Skyrim needs its shadows disabled entirely, etc.
Where can I get it?
NOTE: This uses very similar techniques to intercept the DirectX layer as many common online cheats. I'm not doing anything special to hide myself from VAC or PB or GameGuard, so it's entirely possible that those systems would flag this as a cheat. Use with multiplayer games at your own risk!
You can download pre-compiled versions for the above two games at https://github.com/josh-lieberman/Biclops/downloads, or check out the source code at https://github.com/josh-lieberman/Biclops.
What can I do?
At this stage, there's probably more bugs than not, but play around with it--if you have 3D programming experience feel free to play with the source too. More supported games would be great.
- Fredz
- Petrif-Eyed
- Posts: 2255
- Joined: Sat Jan 09, 2010 2:06 pm
- Location: Perpignan, France
- Contact:
Re: Biclops - Open RIFT-Compatibility layer
A supid question probably, but do you feed the cameras with a 90x100° FOV or do you use the current FOV and warp the result ? Also, it seems the two frames are from a different point in time, are you doing a dual render at a given time or is the second image rendered on a subsequent frame ?
- brantlew
- Petrif-Eyed
- Posts: 2221
- Joined: Sat Sep 17, 2011 9:23 pm
- Location: Menlo Park, CA
Re: Biclops - Open RIFT-Compatibility layer
Thank you Emerson! Very generous of you to open source this.
As I mentioned in another thread. Tridef should have supported the Rift, because now their usefulness will slowly erode as Rift enthusiasts add open-source stereoscopic support for all the popular titles.
As I mentioned in another thread. Tridef should have supported the Rift, because now their usefulness will slowly erode as Rift enthusiasts add open-source stereoscopic support for all the popular titles.
-
- One Eyed Hopeful
- Posts: 34
- Joined: Wed Jun 13, 2012 11:16 pm
Re: Biclops - Open RIFT-Compatibility layer
Using the current FOVs, for now. I'd expect altering them will differ on a per-game basis.A supid question probably, but do you feed the cameras with a 90x100° FOV or do you use the current FOV and warp the result ?
It's also true that the two frames are one-after-another, time-wise, though if the frame-rate is high enough it's not super-noticable in practice.Also, it seems the two frames are from a different point in time, are you doing a dual render at a given time or is the second image rendered on a subsequent frame ?
This is because, to my knowledge, there's no easy way of rendering the exact same geometry twice--we'd have to essentially record and replay the entire sequence of draw calls and shader passes. It's a tradeoff, and if I'm missing some obvious DirectX mechanism to do it, I'd gladly fix it.
- Fredz
- Petrif-Eyed
- Posts: 2255
- Joined: Sat Jan 09, 2010 2:06 pm
- Location: Perpignan, France
- Contact:
Re: Biclops - Open RIFT-Compatibility layer
That's how the NVIDIA stereo 3D driver does it, by duplicated all drawing calls. But then it's somewhat close to a nightmare to do this, since you need to duplicate all render surfaces and use some heuristics to determine what is going to be directly rendered and what is not.
Anyway that's still a very good first step into a stereo 3D driver, that's how I also did it for my first try on a Linux stereo 3D intercept driver. There will always be some place for improvement, but for now I think the *real* FOV rendering is the most important challenge for perfect immersion.
Anyway that's still a very good first step into a stereo 3D driver, that's how I also did it for my first try on a Linux stereo 3D intercept driver. There will always be some place for improvement, but for now I think the *real* FOV rendering is the most important challenge for perfect immersion.
-
- One Eyed Hopeful
- Posts: 34
- Joined: Wed Jun 13, 2012 11:16 pm
Re: Biclops - Open RIFT-Compatibility layer
I bet they get some assistance from knowing what goes in those mysterious black box drivers that sit beneath it all.Fredz wrote:That's how the NVIDIA stereo 3D driver does it, by duplicated all drawing calls. But then it's somewhat close to a nightmare to do this, since you need to duplicate all render surfaces and use some heuristics to determine what is going to be directly rendered and what is not.
I think messing with the FOV in the intercept layer will only work for reducing the FOV, because I'm betting they cull on a frustum approximating their expected FOV.Anyway that's still a very good first step into a stereo 3D driver, that's how I also did it for my first try on a Linux stereo 3D intercept driver. There will always be some place for improvement, but for now I think the *real* FOV rendering is the most important challenge for perfect immersion.
-
- One Eyed Hopeful
- Posts: 48
- Joined: Mon Dec 12, 2011 5:44 pm
Re: Biclops - Open RIFT-Compatibility layer
So that's why that Skyrim video looks a bit vertically stretched? I wonder how many games would break somehow due to being played in a portrait mode, bet quite a few!Emerson wrote:Using the current FOVs, for now. I'd expect altering them will differ on a per-game basis.
- Chriky
- Binocular Vision CONFIRMED!
- Posts: 228
- Joined: Fri Jan 27, 2012 11:24 am
Re: Biclops - Open RIFT-Compatibility layer
Would it be possible to set the game to 1024x768, then roll the camera 90deg, render like that and then rotate it back for when you display it? It should sort out the aspect ratio for you shouldn't it?
-
- One Eyed Hopeful
- Posts: 48
- Joined: Mon Dec 12, 2011 5:44 pm
Re: Biclops - Open RIFT-Compatibility layer
If you do that then the frustum used for culling geometry will be at 90 degrees to the camera, and we'll probably have missing geometry or graphical effects on the top and bottom parts of the image.
- Fredz
- Petrif-Eyed
- Posts: 2255
- Joined: Sat Jan 09, 2010 2:06 pm
- Location: Perpignan, France
- Contact:
Re: Biclops - Open RIFT-Compatibility layer
I don't know if you already read it, but here is a PDF describing basics of how stereo is implemented in the NVIDIA driver :Emerson wrote:I bet they get some assistance from knowing what goes in those mysterious black box drivers that sit beneath it all.
http://www.nvidia.com/content/PDF/GDC20 ... oscopy.pdf
Yes, the game should be aware of the real FOV that is used for rendering to avoid culling. For now I guess the simplest solution would be to modify this value in the game configuration, but it would be better to find a way to modify this value directly in the game.Emerson wrote:I think messing with the FOV in the intercept layer will only work for reducing the FOV, because I'm betting they cull on a frustum approximating their expected FOV.
For Skyrim FOV config you may have a look here :
http://www.pcgamer.com/2011/11/11/the-e ... -and-more/
And for Mirror's Edge :
http://www.wsgf.org/node/293
I guess simply setting the FOV to 90° won't be enough since the horizontal and vertical FOV are different for the Rift (90 and 110°). Maybe you should also modify the aspect ratio in config files or set the FOV to 110° and discard left and right parts of the image to get a 90° horizontal FOV.
- cybereality
- 3D Angel Eyes (Moderator)
- Posts: 11407
- Joined: Sat Apr 12, 2008 8:18 pm
- Likay
- Petrif-Eyed
- Posts: 2913
- Joined: Sat Apr 07, 2007 4:34 pm
- Location: Sweden
Re: Biclops - Open RIFT-Compatibility layer
Good job Emerson!
-
- One Eyed Hopeful
- Posts: 34
- Joined: Wed Jun 13, 2012 11:16 pm
Re: Biclops - Open RIFT-Compatibility layer
Thanks! It's been a fun project so far.
-
- One Eyed Hopeful
- Posts: 34
- Joined: Wed Jun 13, 2012 11:16 pm
-
- Golden Eyed Wiseman! (or woman!)
- Posts: 1644
- Joined: Fri Aug 21, 2009 9:06 pm
Re: Biclops - Open RIFT-Compatibility layer
How much of the top?
The Rift cuts off the very top and bottom of the image, so it might not be a problem.
The Rift cuts off the very top and bottom of the image, so it might not be a problem.
-
- One Eyed Hopeful
- Posts: 48
- Joined: Mon Dec 12, 2011 5:44 pm
Re: Biclops - Open RIFT-Compatibility layer
So out of curiosity when you run Skyrim with your DLL, what do you set the resolution to, and what FOV have you got in your settings? I'm not too knowledgable about the inner workings of DirectX and stuff, I'm guessing you can't just set the resolution of the game to 640x800 with FOV in the settings at 90 degrees, render the scene twice, grab the scene from the framebuffer each time and then manually output to a 1280x800 window with those images side-by-side?
-
- One Eyed Hopeful
- Posts: 34
- Joined: Wed Jun 13, 2012 11:16 pm
Re: Biclops - Open RIFT-Compatibility layer
Looks like this (parts of the geometry getting culled out at the top).PalmerTech wrote:How much of the top?
I can try to change the FOV to 110 in the game preferences and just change the aspect ratio, which fixes the clipping, but feels weird for some reason.
Right now as the codebase sits, it expects the game to run at 1280x800, and the default FOV (probably somewhere between 75 and 90 in most games). It just squashes when it rerenders the side-by-side, which makes everyone super skinny. On my box, I've been experimenting with correcting the aspect ratio, but it's basically like pan-n-scanning the normal frustum-the sides get chopped off which makes it feel "zoomed" in and therefore not the FOV you'd expect.rajveer wrote:So out of curiosity when you run Skyrim with your DLL, what do you set the resolution to, and what FOV have you got in your settings?
It could be theoretically possible, but I think I'd have to intercept the Win32 calls that setup the original HWND handle to go 1280x800, which gets more complicated (it's not part of the DirectX API per se). Also, I'm not sure the game would support 640x800 as a default resolution, or necessarily even have a good design for an 8:10 aspect ratio (in terms of positioning weapon models on the screen).I'm not too knowledgable about the inner workings of DirectX and stuff, I'm guessing you can't just set the resolution of the game to 640x800 with FOV in the settings at 90 degrees, render the scene twice, grab the scene from the framebuffer each time and then manually output to a 1280x800 window with those images side-by-side?
-
- Cross Eyed!
- Posts: 140
- Joined: Sat Jul 17, 2010 10:28 am
Re: Biclops - Open RIFT-Compatibility layer
I wonder if with the Rift the center pixel is supposed to be when the eye is looking straight ahead or if it represents convergence some distance ahead. The screenshots you're generating look like the later ( if it were straight ahead distant objects would be in the same position in both images).
-
- One Eyed Hopeful
- Posts: 44
- Joined: Thu Jun 07, 2012 7:22 am
Re: Biclops - Open RIFT-Compatibility layer
Hi Emerson, I am really interested in all things VRish, and this work on pre-distortion is really interesting. I did some work on lens correction several years ago, and I'm not sure your code is doing barrel distortion completely "by the book", but then there are many variations depending on the optics you are correcting and your correction already looks good.
Here is a simple test rig that may be of some interest. I put it together in GeeXLab. It may be of interest to those coding directly in OpenGL/GLSL or wanting to write a similar DLL interceptor. You can load in stereo images (the one attached is from WikiMedia) and tweak the values to fit. I made a variant of your algorithm using the values you found, and then added a cubic radial barrel distortion model, that does radial distortion as r' = a + b*r + c*r^2 + d*r^3. I think this distortion gives a slightly rounder barrel distortion, plus its more tweakable to fit different optical configurations. You can switch between the two correction models by switching the value "method" on the roll-out pane with the parameters. Plenty of optimisations could be done on the shader, but it was just a quick demo for testing.
example.png is an example screenshot of geexlab. Put chicago_lion.jpg and DEMO.xml in the same directory and load DEMO.xml into GeexLab and you are away.
Here is a simple test rig that may be of some interest. I put it together in GeeXLab. It may be of interest to those coding directly in OpenGL/GLSL or wanting to write a similar DLL interceptor. You can load in stereo images (the one attached is from WikiMedia) and tweak the values to fit. I made a variant of your algorithm using the values you found, and then added a cubic radial barrel distortion model, that does radial distortion as r' = a + b*r + c*r^2 + d*r^3. I think this distortion gives a slightly rounder barrel distortion, plus its more tweakable to fit different optical configurations. You can switch between the two correction models by switching the value "method" on the roll-out pane with the parameters. Plenty of optimisations could be done on the shader, but it was just a quick demo for testing.
example.png is an example screenshot of geexlab. Put chicago_lion.jpg and DEMO.xml in the same directory and load DEMO.xml into GeexLab and you are away.
You do not have the required permissions to view the files attached to this post.
-
- One Eyed Hopeful
- Posts: 34
- Joined: Wed Jun 13, 2012 11:16 pm
Re: Biclops - Open RIFT-Compatibility layer
Very cool! My distortion was just trying to fit a model onto the screenshot data I had; it's been mostly trial and error so far.
I'm sure that once hardware samples start floating around, all the stuff I've done so far will need lots of tweaking. We'll probably just have to toss up a grid on the display and hand-tweak the algos/constants until we get as close as possible (might even be different constants for different instances of the kit, depending on the assembly tolerances). Worst-case scenario, since the output resolution is fixed, I have a simple distortion map shader to just manually set each pixel's offset in a texture and brute force a solution.
I'll try to get this function as an option in the shaders, and hopefully a bit better of a configuration mechanism to handle the constants and algo swapping. The more options at our disposal, the more likely we can find the right correction once the hardware's out.
My tweaks so far have just been to try and comfortably see 3D on my desktop screen. I'm not really sure what's going to feel comfortable on an actual Rift, we'll find out.
I'm sure that once hardware samples start floating around, all the stuff I've done so far will need lots of tweaking. We'll probably just have to toss up a grid on the display and hand-tweak the algos/constants until we get as close as possible (might even be different constants for different instances of the kit, depending on the assembly tolerances). Worst-case scenario, since the output resolution is fixed, I have a simple distortion map shader to just manually set each pixel's offset in a texture and brute force a solution.
I'll try to get this function as an option in the shaders, and hopefully a bit better of a configuration mechanism to handle the constants and algo swapping. The more options at our disposal, the more likely we can find the right correction once the hardware's out.
There's two adjustable options at play--the eye offset parameter just translates the two cameras on the x-axis, shifting them outwards, the frustum offset's effect is to make the frustum pyramids lop-sided. Kinda like "rotating" the views inward or outward but hopefully keeping a single focal plane instead of just a vertical intersection as you'd get with a plain rotation. This latter option corresponds to convergence. I think some 3D drivers out there probably sample the z-coordinates of vertices getting uploaded to try and auto-judge a convergence value, that would be a nice-to-have someday.LeeN wrote:I wonder if with the Rift the center pixel is supposed to be when the eye is looking straight ahead or if it represents convergence some distance ahead. The screenshots you're generating look like the later ( if it were straight ahead distant objects would be in the same position in both images).
My tweaks so far have just been to try and comfortably see 3D on my desktop screen. I'm not really sure what's going to feel comfortable on an actual Rift, we'll find out.
- brantlew
- Petrif-Eyed
- Posts: 2221
- Joined: Sat Sep 17, 2011 9:23 pm
- Location: Menlo Park, CA
Re: Biclops - Open RIFT-Compatibility layer
http://pc.gamespy.com/articles/122/1225382p1.html
One thing that stuck out to me in this article is the characteristic:
One thing that stuck out to me in this article is the characteristic:
I assume this is a function of the lenses just stretching pixels on the edges more than the center - so there is a higher pixel density in the center. Curious - is this something that the warp drivers need to take into account or does it just naturally occur if the warp function matches the geometry of the lens?Variable Acuity Resolution (VAR) puts more pixels in the center of the image, and fewer in the periphery, mimicking the natural characteristics of the eye.
-
- One Eyed Hopeful
- Posts: 44
- Joined: Thu Jun 07, 2012 7:22 am
Re: Biclops - Open RIFT-Compatibility layer
VAR just sounds like a natural property of the magnification of such systems! You can correct any apparent distortion with a barrel-like correction, so yes the warp drivers take this in to account.brantlew wrote:http://pc.gamespy.com/articles/122/1225382p1.html
One thing that stuck out to me in this article is the characteristic:
I assume this is a function of the lenses just stretching pixels on the edges more than the center - so there is a higher pixel density in the center. Curious - is this something that the warp drivers need to take into account or does it just naturally occur if the warp function matches the geometry of the lens?Variable Acuity Resolution (VAR) puts more pixels in the center of the image, and fewer in the periphery, mimicking the natural characteristics of the eye.
-
- One Eyed Hopeful
- Posts: 34
- Joined: Wed Jun 13, 2012 11:16 pm
Re: Biclops - Open RIFT-Compatibility layer
It sounds like a fancy way of spinning the fact that the image is least distorted near the middle, heh.
-
- Golden Eyed Wiseman! (or woman!)
- Posts: 1644
- Joined: Fri Aug 21, 2009 9:06 pm
Re: Biclops - Open RIFT-Compatibility layer
Yep. It really is a good effect, though, since it lets you get away with using fewer pixels in the periphery. It looks much, much better than a non-compressed resolution of 640x800 would appear at 90 degrees. If you wanted to be really fancy, you could do variable rendering with higher detail in the center of the image, but the returns on that will not be useful till we have much higher resolution.Emerson wrote:It sounds like a fancy way of spinning the fact that the image is least distorted near the middle, heh.
-
- Certif-Eyed!
- Posts: 661
- Joined: Sun Mar 25, 2012 12:33 pm
Re: Biclops - Open RIFT-Compatibility layer
I wonder if you would still notice LOD popping if it occurs as the object moves from the center of your vision to the periphery.
-
- Cross Eyed!
- Posts: 102
- Joined: Fri May 18, 2012 5:31 pm
- Location: Houston, TX
- Contact:
Re: Biclops - Open RIFT-Compatibility layer
Out of curiosity, how much does detail break down when using your eyeballs to scan around the edge of the image inside of a VAR HMD, where the optics are "robbing" pixels from?
From looking at the pre-warped images that people have posted (and the fact that reporters haven't commented on the effect), I'm optimistic that the effect isn't too noticeable. Though, I does seem that everyone is basing their calculations off of John Carmack's sample Twitter image, which he mentioned wasn't as severe as the final distortion ended up needing to be.
I don't doubt that VAR is totally the correct answer right now. I'm just wondering how well it will scale as we approach our Utopian full-FOV displays (which will encourage more eye-only motion).
From looking at the pre-warped images that people have posted (and the fact that reporters haven't commented on the effect), I'm optimistic that the effect isn't too noticeable. Though, I does seem that everyone is basing their calculations off of John Carmack's sample Twitter image, which he mentioned wasn't as severe as the final distortion ended up needing to be.
I don't doubt that VAR is totally the correct answer right now. I'm just wondering how well it will scale as we approach our Utopian full-FOV displays (which will encourage more eye-only motion).
-
- Binocular Vision CONFIRMED!
- Posts: 237
- Joined: Thu Jun 07, 2012 8:40 am
- Location: New York
- Contact:
Re: Biclops - Open RIFT-Compatibility layer
I thought the only way to get reasonable detail in the middle using a shader was to simply render at 2x resolution or something higher and then warp that and scale it down. As this is very non-linear I don't think there is any way a vertex shader can warp the geometry as well, but as post-processing it should be quite simple to do on a higher resolution pixel shading post-processing step. Am I missing something?PalmerTech wrote:you could do variable rendering with higher detail in the center of the image, but the returns on that will not be useful till we have much higher resolution.
Ibex 3D VR Desktop for the Oculus Rift: http://hwahba.com/ibex - https://bitbucket.org/druidsbane/ibex
- brantlew
- Petrif-Eyed
- Posts: 2221
- Joined: Sat Sep 17, 2011 9:23 pm
- Location: Menlo Park, CA
Re: Biclops - Open RIFT-Compatibility layer
Could you render the same view twice - once with a high FOV but low resolution and once with a low FOV but high resolution. Then - just sort of insert the high res image inside the the low res like so.
Now of course the final display resolution of the entire image is extremely high, but because the outside "pixels" are stretched into giant blocks the entire image can be compressed significantly for transmission on the line. The edges between the regions might look funny, but you might be able to do this 3 or 4 times and create a concentric pattern that dropped off gradually in detail.
Or maybe there is a much more elegant way to do this mathematically on the GPU so that the "effective" resolution drops gradually away from the center. I'm thinking something like ray-tracing where you can control the angle of the intersection between the view surface and the light ray.
Now of course the final display resolution of the entire image is extremely high, but because the outside "pixels" are stretched into giant blocks the entire image can be compressed significantly for transmission on the line. The edges between the regions might look funny, but you might be able to do this 3 or 4 times and create a concentric pattern that dropped off gradually in detail.
Or maybe there is a much more elegant way to do this mathematically on the GPU so that the "effective" resolution drops gradually away from the center. I'm thinking something like ray-tracing where you can control the angle of the intersection between the view surface and the light ray.
You do not have the required permissions to view the files attached to this post.
-
- Cross Eyed!
- Posts: 102
- Joined: Fri May 18, 2012 5:31 pm
- Location: Houston, TX
- Contact:
Re: Biclops - Open RIFT-Compatibility layer
In a traditional forward renderer, you'd end up transforming the geometry for the scene twice for the example shown, and another additional time for each extra ring (multiplied by two views for stereo vision). It adds up quick. A better approach may be to just run less expensive pixel shaders, perform less tessellation, etc. on things at the extremes of the view.brantlew wrote:Could you render the same view twice - once with a high FOV but low resolution and once with a low FOV but high resolution. Then - just sort of insert the high res image inside the the low res like so.
[...]
Now of course the final display resolution of the entire image is extremely high, but because the outside "pixels" are stretched into giant blocks the entire image can be compressed significantly for transmission on the line. The edges between the regions might look funny, but you might be able to do this 3 or 4 times and create a concentric pattern that dropped off gradually in detail.
-
- Certif-Eyed!
- Posts: 661
- Joined: Sun Mar 25, 2012 12:33 pm
Re: Biclops - Open RIFT-Compatibility layer
I bet it would work for raytraced games though (the future!)
-
- Cross Eyed!
- Posts: 168
- Joined: Tue Jan 25, 2011 7:53 pm
- Location: Sweden
Re: Biclops - Open RIFT-Compatibility layer
Yeah, a raytracer could possibly even be written to trace out the variable LOD the Rift has. so that you wouldn't waste any processing power on multisampling the edges.
"This is great!"
-
- Golden Eyed Wiseman! (or woman!)
- Posts: 1644
- Joined: Fri Aug 21, 2009 9:06 pm
Re: Biclops - Open RIFT-Compatibility layer
When I place the files in same directory as the Skyrim executables, the game fails to launch and throws me runtime errors. Could I be doing something wrong? Anyone else had trouble, or is something wrong on my end?
- brantlew
- Petrif-Eyed
- Posts: 2221
- Joined: Sat Sep 17, 2011 9:23 pm
- Location: Menlo Park, CA
Re: Biclops - Open RIFT-Compatibility layer
You may be the first tester since you're the only one with the hardware.
-
- Golden Eyed Wiseman! (or woman!)
- Posts: 1644
- Joined: Fri Aug 21, 2009 9:06 pm
Re: Biclops - Open RIFT-Compatibility layer
At this point, I do not have a Rift hooked up, just trying to run it on my laptop display. Going to have a few friends see if they can get it running.
-
- Binocular Vision CONFIRMED!
- Posts: 236
- Joined: Wed Sep 30, 2009 8:29 pm
Re: Biclops - Open RIFT-Compatibility layer
I was abe to get it running - I simply put the files into the main directly and loaded skyrim direct (not through Tridef). Looks promising - man I cant wait to get my eyes into a Rift!!!
On the initial startup it appears that the right view is not working however once in game it works perfect. Also - when entering into the menu screens the right side freeses up as well.
On the initial startup it appears that the right view is not working however once in game it works perfect. Also - when entering into the menu screens the right side freeses up as well.
- brantlew
- Petrif-Eyed
- Posts: 2221
- Joined: Sat Sep 17, 2011 9:23 pm
- Location: Menlo Park, CA
Re: Biclops - Open RIFT-Compatibility layer
@Emerson & Cyber: Just curious about a few things. How easily does the technique transfer from game to game? Does the code transfer easily between games using the same engine or does each game require a similar amount of customization? Or put another way - are there more differences between individual games or between engines?
- cybereality
- 3D Angel Eyes (Moderator)
- Posts: 11407
- Joined: Sat Apr 12, 2008 8:18 pm
Re: Biclops - Open RIFT-Compatibility layer
My issue currently is not with game specific implementations details, but with the hook process even working at all. For whatever reason I have gotten L4D to work, and noticed the Portal 2 also works (surely the engine code is very close since they both use Source). I bet Portal 1 and L4D2 also work. However, most other games I've tried, probably a dozen or so, just crash immediate when trying to run the executable. Sometimes there is an error message, but it is different for each game, sometimes nothing happens.brantlew wrote:@Emerson & Cyber: Just curious about a few things. How easily does the technique transfer from game to game? Does the code transfer easily between games using the same engine or does each game require a similar amount of customization? Or put another way - are there more differences between individual games or between engines?
If I got the initial hook to work, then the 3D would probably work. Most of the code is generic, but some is specific (for example, enabling or disabling the alteration of certain matrices). So there will likely need to be specific tweaks done, but this could even be externalized into a config file or something to make new game profiles easier. But I am just guessing at this point since I don't understand why so many games don't work. And its made even more difficult because I can't really do any debugging with the method I am using, so I am taking shots in the dark here trying to figure out whats wrong.
-
- One Eyed Hopeful
- Posts: 34
- Joined: Wed Jun 13, 2012 11:16 pm
Re: Biclops - Open RIFT-Compatibility layer
I think the general process is the same for most games, but each game has its own unique and quirky ways of doing things. What I've been hacking on the last week or two in my free time is a mechanism that, while it won't relieve the need for game-specific hacks, should at least compartmentalize them so that the driver core doesn't get bogged down with tons of edge cases.
I do think it will be an open question as to how to support games that require specialized injection methods though--doubly so for ones that have some sort of cheat defense mechanism (obviously even if I were to find a reasonable circumvention method that works, if I open sourced it, it would make its way into cheats sooner or later).
I do think it will be an open question as to how to support games that require specialized injection methods though--doubly so for ones that have some sort of cheat defense mechanism (obviously even if I were to find a reasonable circumvention method that works, if I open sourced it, it would make its way into cheats sooner or later).
-
- One Eyed Hopeful
- Posts: 5
- Joined: Fri Jul 06, 2012 9:07 pm
Re: Biclops - Open RIFT-Compatibility layer
Let me first say I'm mostly ignorant on whats possible and not possible with what ya'll are doing. So please forgive my ignorance. =)
Finding thread got me interested enough to do some reading on the subject, and, from what I've found, it seems that both you and cybereality are using the Proxy DLL method to intercept DirectX calls by replacing the DX DLL in the game directory with your own. But, from my limited reading, there are more efficient ways to intercept it that doesn't require you to add support for one game at a time and would just work with all games.
For instance, Fraps uses system hooks to inject itself to capture and modify the image from any DirectX application. This is a description of how Fraps does it:
http://www.ring3circus.com/gameprogramm ... udy-fraps/
In addition, there's an open-source Fraps-alternaive that likely works in the same way:
http://sourceforge.net/projects/taksi/
You might be able to get some ideas or code from that project.
I realize you've been using C++, but I also found a .NET open source assembly "that allows you to safely install hooks from managed code into unmanaged functions. (Note: EasyHook takes care of all the issues surrounding DLL injection - e.g. CREATE_SUSPENDED, ACL's, 32 vs 64-bit and so on)." Its supposedly easy to use:
http://easyhook.codeplex.com/
Also, I'm wondering: why try to re-invent the wheel by making a 4th program that does 3D? If neither TriDef or IZ3D will build in support for the Rfit, could you not use the same kind of hooks to grab TriDef's, IZ3D's, or 3D Vision's output and apply the distortion there? If you could do that, then you wouldn't have to build in support for each game separately and it would work with online games that frown on replacing game files. TriDef and IZ3D both have a financial incentive to make sure that their programs work with as many games as possible and would do nearly all of the programming work for supporting current and future games without you having to do anything other than maintain compatibility with TriDef/IZ3D/3D Vision. In addition, you won't have to try to replicate their 3D features into your code. Furthermore, this would greatly increase the Rift's popularity, since, if someone's favorite game isn't on the list of games that you support, they won't buy it or, worse, return it and give it a bad review.
Again, I apologize if I ended up just talking out of my a** due to sheer ignorance. =/
Lastly, I'm thrilled and appreciative that there are two talented people willing to give so much time so that the Oculus Rift has the software support that it needs! =)
Finding thread got me interested enough to do some reading on the subject, and, from what I've found, it seems that both you and cybereality are using the Proxy DLL method to intercept DirectX calls by replacing the DX DLL in the game directory with your own. But, from my limited reading, there are more efficient ways to intercept it that doesn't require you to add support for one game at a time and would just work with all games.
For instance, Fraps uses system hooks to inject itself to capture and modify the image from any DirectX application. This is a description of how Fraps does it:
http://www.ring3circus.com/gameprogramm ... udy-fraps/
In addition, there's an open-source Fraps-alternaive that likely works in the same way:
http://sourceforge.net/projects/taksi/
You might be able to get some ideas or code from that project.
I realize you've been using C++, but I also found a .NET open source assembly "that allows you to safely install hooks from managed code into unmanaged functions. (Note: EasyHook takes care of all the issues surrounding DLL injection - e.g. CREATE_SUSPENDED, ACL's, 32 vs 64-bit and so on)." Its supposedly easy to use:
http://easyhook.codeplex.com/
Also, I'm wondering: why try to re-invent the wheel by making a 4th program that does 3D? If neither TriDef or IZ3D will build in support for the Rfit, could you not use the same kind of hooks to grab TriDef's, IZ3D's, or 3D Vision's output and apply the distortion there? If you could do that, then you wouldn't have to build in support for each game separately and it would work with online games that frown on replacing game files. TriDef and IZ3D both have a financial incentive to make sure that their programs work with as many games as possible and would do nearly all of the programming work for supporting current and future games without you having to do anything other than maintain compatibility with TriDef/IZ3D/3D Vision. In addition, you won't have to try to replicate their 3D features into your code. Furthermore, this would greatly increase the Rift's popularity, since, if someone's favorite game isn't on the list of games that you support, they won't buy it or, worse, return it and give it a bad review.
Again, I apologize if I ended up just talking out of my a** due to sheer ignorance. =/
Lastly, I'm thrilled and appreciative that there are two talented people willing to give so much time so that the Oculus Rift has the software support that it needs! =)
- brantlew
- Petrif-Eyed
- Posts: 2221
- Joined: Sat Sep 17, 2011 9:23 pm
- Location: Menlo Park, CA
Re: Biclops - Open RIFT-Compatibility layer
@TheInevitable: You might be able to do a post-process of the Tridef output images for warp correction but I think you would need access earlier in the pipeline to accomplish the necessary FOV changes.