The best way to get full colour stereoscopic 3d at home is to purchase the nVidia 3D Vision kit. The nVidia 3D Vision Kit is a pair of wireless electronic glasses that blocks out an eye (the lens tint black) while your monitor displays the frame for the other eye. In order for this to be fluent you need a monitor capable of refreshing at 100Hz or more (so 50Hz for each eye).
All you need is an nVidia graphics card from the last 3 years, a 120Hz LCD/100Hz CRT, and the nVidia 3D Vision Kit.
From scratch the most it'll cost you to set this up is; the graphics card: $100, nVidia 32 Vision Kit: $150, and a 3D Monitor: $300. I still have a high-end CRT from 2003 that is more than capable of 100Hz, so if you have a modern computer, saved your old CRT, then it's likely all you only need to purchase is the 3D Vision Kit. I've occasionally seen the 3D Vision Kit sell on eBay for less. e.g.
Those glasses you get from the cinema (under a brand name like RealD) won't work with your monitor so you can't ask Notch to support them in the game. These glasses rely on a display that shows the image for each eye at a different polarity and filters out the image not intended for that eye.
I'm letting people know that while I have been silent work is still progressing on my Direct3D 11 port! It just takes time to emulate OpenGL's functionality in D3D shaders, and I'm also attending university lectures, working on assignments, and my honours project. Sorry for the wait people!
Quote from Xuanz »
when I try to play the game, it says "Can not create texture for left eye" and then closes the application. Do you know what the problem is? I have Left and Right in my .minecraft directory.
Hmm.. That tells me Direct3D 9 has loaded but it fails when it tried creating a texture big enough to draw the left eye in. How much video memory do you have (and out of curiosity what video card - you can find out both of these by running 'dxdiag')?
I'm working on making a native Direct3D 11 backend that intercepts and bypasses the OpenGL calls so all rendering is done in D3D 11, but progress is slow. I've made a list of all of the OpenGL calls Minecraft makes, they're intercepted by my code, and now I have to fill the replacement code in. I've finished the code that emulate's OpenGL's matrix stack and operations, but there is still a lot more to do before I will get the first thing shown on the screen. At the least I must load the textures, load the array pointers, and render the geometry. To get it looking the same as Minecraft I will have to imitate fog and lighting in the pixel shader, and a bunch of other stuff (too tired to think right now!)..
It's just a lot of work.. :/ But I'll power through and it'll be done before I know!
I'm looking forward to the end result when I can experiment with some nice HLSL shaders! :smile.gif:
And, as you say, you could make shaders of your own. Perhaps 3D is just part of what you could be doing here; it could be as sweeping as a generalized Direct3d wrapper for Minecraft which happens to support stereoscopic 3D rendering :biggrin.gif:
I was thinking the same thing. This project was to prove you could use the consumer NVidia 3D Vision kit to play an OpenGL game (a feature I really want myself), and I've shown it can work, but I've reached a performance limitation and now it's time to take my project in a new direction. Perhaps one day it'll be a Direct3D 11 backend that supports custom full screen resolutions, HLSL shader effects, antialiasing, and stereoscopic 3D!
I can't find any more information about that extension... :/ I guess nVidia experimented with it then removed it.
I was looking into the source code of Minecraft and it mostly uses OpenGL 1.1 calls and only 3 extensions, so it seems completely feasible to map the OpenGL calls somewhat directly into Direct3D. Of course you'd loose compatibility with GLSL shaders (which we could replace with a new set of HLSL shaders :biggrin.gif:) and it'd fix tons of problems! I could perfectly sync the eyes, it would run significantly faster since I can render directly into a Direct3D texture, the 3D Vision crosshair would show natively, and I could add extra render settings since it'll be purely Direct3D (settings like anti-aliasing and frame smoothing come to mind). I would want to use Direct3D 11 to simplify the wrapper, because it's the only version of Direct3D that has render lists - and render lists enable me to record the drawing commands and play them back multiple times (once for each eye). But using Direct3D 11 will limit my wrapper to only run on Windows Vista and 7. Would loosing compatibility with Windows XP be worth it?
Anyway it's 1:40 AM in Australia so I'm off to bed!
One possible way could be by recording the OpenGL calls as Minecraft draws one eye then play back the identical calls for the other eye (this introduces some special cases like what if Minecraft updates a texture half way through drawing one eye, do I record and play that back too?) I guess only experimentation will tell!
I think that sounds like a perfectly reasonable approach. I daresay the inconvenience of the special cases would be less than that of the staggered eye output.
But then I might have to modify the code behind every OpenGL call (or at least scan the source for all those that Minecraft uses - not counting any mods that use additional calls like the shader mod) and modify it so it also logs what it's doing.
Another way would be to edit minecraft.jar (which I'd like to avoid because it'll break with an update). If you decompile minecraft.jar with MCP you can see that once per update Timer.updateTimer() is called which calculates how much time has passed since the last frame. If we can get Minecraft to think no time has passed between drawing the first and second eyes then the eyes should theoretically be drawn at the exact same point of time in the Minecraft world.
Timer.updateTimer() uses System.currentTimeMilliseconds() to find out what the current time is so it can calculate the difference since last time. System.currentTimeMilliseconds() is part of the Java runtime library so I don't think I can edit that. I can add a line of code to the top of Timer.updateTimer() so the timer doesn't update if I'm drawing the second eye. This is the easiest method, but the eyes won't be perfectly in synced - if you're in multiplayer and another player's position has updated even if the game thinks no time has passed then the other player will be drawn at a different position for each eye.
There are pros and cons of doing either method, and if I am going to do anything it'll be at the OpenGL level. I'll look into display lists (an OpenGL way of letting you record commands then play them back exactly - though I wonder about the speed of recording into a display list every frame) because it'll beat modifying every OpenGL call.
Of course if you have a steady frame rate >60fps then this is a lot of effort for little result.
Apologies for the long post - it helps to find a solution when you explain the problem aloud! :smile.gif:
I don't quite understand the cross-eyed thing. Still a great mod!
Thank you!
Cross-eyed is a bit difficult to focus first, and works best if you're playing the game in a small window or sitting a bit back from the screen. Also I wouldn't recommend playing it for half a day straight on cross-eyed unless you want some serious eye strain. But it is a cheap way to try out 3D without needing any special kind of glasses.
Basically the image the right eye sees is shown on the left half of the screen, and vice versa. Then you look at your screen cross-eyed. As you go cross-eyed you'll notice the two images come closer together and overlap. Try to get them to overlapped perfectly (in my experience this is easier if you focus on something static like the cross hair while wiggling the mouse so the background animates).
That update seems to have added a few extra FPS. Nice work! (but don't stop now).
I have more ideas on how to speed this up. I definitely know the performance problem exists at the OpenGL/Direct3D border - probably because each frame is going GPU(GL)->CPU->GPU(D3D) - at 1920x1080/32bbp that's 8,294,400 bytes each way per eye per frame! I've discovered there are some OpenGL extensions that allow you to use Direct3D resources - specifically let OpenGL draw straight into a Direct3D surface. Hopefully if used correctly the GPU will draw straight into the Direct3D texture without needing to transfer anything through the CPU. But, the problem with OpenGL extensions is they're vendor specific - this extension I'm looking at is nVidia specific.
Quote from Laurina »
One thing that was mentioned earlier I've found to be true, so I'll make the point once more:
The images for each eye are are rendered in a sort of staggered way - the image for the left eye is not the match for the right eye, but rather the right image is the next frame in time. This means that when things move fast or when framerate is not high enough, you get a lot of mismatch between the eyes. If it would be possible to make sure that each frameset contains a left and right image taken at the exact same time, that would eliminate the problem and make low framerates much more bearable to play.
That's actually a more interesting problem than it first seems. My code is working at the OpenGL layer and has no concept of what Minecraft is doing. So I can't tell Minecraft to draw the scene twice, so instead I let the game loop run twice - once for the left eye and once for the right eye so you're actually getting alternating frames to each eye. If you can maintain a steady 60fps (30fps per eye) this should be no problem, actually if you can maintain 120fps then each eye is updating as fast as the NVidia 3D Vision glasses can show. Anyway I do agree that it is distracting at choppy framerates. I'll look into ways to get the eyes rendering together. One possible way could be by recording the OpenGL calls as Minecraft draws one eye then play back the identical calls for the other eye (this introduces some special cases like what if Minecraft updates a texture half way through drawing one eye, do I record and play that back too?) I guess only experimentation will tell!
Update out! See top post. I've improved the performance of the stage where the OpenGL image is copied into a Direct3D texture. There are still more improvements to be done and I haven't worked on the other stuff yet.
Quote from Laurina »
Coding something to draw a crosshair at, say, the average Z depth of a small area at the center of the view would work just as well - that is pretty much what the Nvidia driver does.
That wouldn't be so hard - but you need to disable Minecraft's cross hair or else it will interfere. I can't do that without modifying minecraft.jar (which I want to avoid since it means my mod will break with updates).
Quote from Laurina »
The option to ignore the configuration values and use the standard Nvidia setup would be interesting too, and quite a bit less work to implement than coding your own crosshair system, I suspect.
That would also allow the use of Nvidia's convergence hotkeys as well, and just maybe it would make the crosshair appear.
Yeah but it wouldn't stop you from seeing double crosshairs (infact the z-depth of Minecraft's crosshair might interfer with the NVidia's cross hair making it appear a lot closer than the actual depth where it should be).
First of all: It is a glorious thing you're doing here, and very very nice work so far.
Thank you very much!
Quote from Laurina »
1) As already observed above, there is a hard FPS hit using this. I can alleviate that to some extent by lowering resolution to 720x480 (rather than native 1920x1080). Obviously it doesn't look very good that way.
Yeah, I'm going to work on that issue. It's to do with me locking GPU resources each frame - I've thought of a bunch of ways to speed it up.
Quote from Laurina »
2) A minor issue compared to item 1, but one that would be nice to fix nevertheless; enabling the Nvidia 3D vision crosshair. Turning it on and off manually doesn't produce a crosshair, although the on-screen-display of the driver outputs text about it being turned on/off.
I don't think that will work unless I manually draw the NVidia 3D Vision crosshair in because of the way I'm mixing OpenGL/DirectX. I will experiment. Likewise I'm ignoring the depth values the NVidia 3D Vision controls tells me to use and overriding it with the values you set in the configuration tool I provided. I could add an option to ignore the custom depth values and use NVidia's instead - then you can use the 3D Vision dongle's wheel to adjust the depth!
I have a problem, the 3D and textures look color but with only 1 problem, they all have a lack of color. Red color to be specific ><
Are you using Red/Cyan glasses? The problem with the anaglyph (tinted glasses) is that the lens are tinted to only let specific colours through to each eye - so you are going to loose one colour channel (out of red, green, blue) to one eye, and that colour will instead be sent to the other eye. With Red/Cyan glasses you sacrifice red. There's nothing I can do about that.
You can also get Green/Magenta and Blue/Yellow glasses. I think Blue/Yellow glasses will give the best effect because you sacrifice blue, giving the sky and water a washed-out grey/slightly-green tinge but otherwise sand, grass, and wood retain it's colour.
Mining a cloud shouldn't give you some awesome ultimate reward because it's very simple to reach a cloud (climb a mountain or block your way up).
Maybe you could use a bucket with the cloud and it cuts a square out of the cloud as it flies over to collect water vapour. What you'd use water vapour for I don't know.. Steam powered engines? :biggrin.gif: Placing a bucket of water into a furnace could have the same effect.
Is the only problem the performance or is there something not working?
Quote from Orcworm »
The 3D effect is definitely there, the only problem is it crushes my FPS, looking at 9-12 on fast / tiny @ 1920x1080 with 2 480s :tongue.gif:.
Edit: Actually, configuring the game using your file and then starting it seems to crush FPS whether 3D is on or off, getting only 25-30 with 3D disabled.
I think I may know what's causing this. I'm locking a Direct3D texture to draw the output of the game in to, and I think this locking has a performance penalty so there should be a way to significantly speed this up. I'll look into it soon! Thanks!
0
0
The best way to get full colour stereoscopic 3d at home is to purchase the nVidia 3D Vision kit. The nVidia 3D Vision Kit is a pair of wireless electronic glasses that blocks out an eye (the lens tint black) while your monitor displays the frame for the other eye. In order for this to be fluent you need a monitor capable of refreshing at 100Hz or more (so 50Hz for each eye).
All you need is an nVidia graphics card from the last 3 years, a 120Hz LCD/100Hz CRT, and the nVidia 3D Vision Kit.
From scratch the most it'll cost you to set this up is; the graphics card: $100, nVidia 32 Vision Kit: $150, and a 3D Monitor: $300. I still have a high-end CRT from 2003 that is more than capable of 100Hz, so if you have a modern computer, saved your old CRT, then it's likely all you only need to purchase is the 3D Vision Kit. I've occasionally seen the 3D Vision Kit sell on eBay for less. e.g.
http://www.ebay.com.au/itm/Brand-New-Nvidia-3D-Vision-Glasses-Kit-FREE-SHIPPING-/230630999332?pt=AU_Components&hash=item35b2adc524#ht_1584wt_1047
Those glasses you get from the cinema (under a brand name like RealD) won't work with your monitor so you can't ask Notch to support them in the game. These glasses rely on a display that shows the image for each eye at a different polarity and filters out the image not intended for that eye.
0
Hmm.. That tells me Direct3D 9 has loaded but it fails when it tried creating a texture big enough to draw the left eye in. How much video memory do you have (and out of curiosity what video card - you can find out both of these by running 'dxdiag')?
0
It's just a lot of work.. :/ But I'll power through and it'll be done before I know!
I'm looking forward to the end result when I can experiment with some nice HLSL shaders! :smile.gif:
0
I was thinking the same thing. This project was to prove you could use the consumer NVidia 3D Vision kit to play an OpenGL game (a feature I really want myself), and I've shown it can work, but I've reached a performance limitation and now it's time to take my project in a new direction. Perhaps one day it'll be a Direct3D 11 backend that supports custom full screen resolutions, HLSL shader effects, antialiasing, and stereoscopic 3D!
0
I was looking into the source code of Minecraft and it mostly uses OpenGL 1.1 calls and only 3 extensions, so it seems completely feasible to map the OpenGL calls somewhat directly into Direct3D. Of course you'd loose compatibility with GLSL shaders (which we could replace with a new set of HLSL shaders :biggrin.gif:) and it'd fix tons of problems! I could perfectly sync the eyes, it would run significantly faster since I can render directly into a Direct3D texture, the 3D Vision crosshair would show natively, and I could add extra render settings since it'll be purely Direct3D (settings like anti-aliasing and frame smoothing come to mind). I would want to use Direct3D 11 to simplify the wrapper, because it's the only version of Direct3D that has render lists - and render lists enable me to record the drawing commands and play them back multiple times (once for each eye). But using Direct3D 11 will limit my wrapper to only run on Windows Vista and 7. Would loosing compatibility with Windows XP be worth it?
Anyway it's 1:40 AM in Australia so I'm off to bed!
0
"The first support is added a year ago, but from time to time this extension disappears from the drivers implementation."
I'm going to continue my investigation.. o_o
0
But then I might have to modify the code behind every OpenGL call (or at least scan the source for all those that Minecraft uses - not counting any mods that use additional calls like the shader mod) and modify it so it also logs what it's doing.
Another way would be to edit minecraft.jar (which I'd like to avoid because it'll break with an update). If you decompile minecraft.jar with MCP you can see that once per update Timer.updateTimer() is called which calculates how much time has passed since the last frame. If we can get Minecraft to think no time has passed between drawing the first and second eyes then the eyes should theoretically be drawn at the exact same point of time in the Minecraft world.
Timer.updateTimer() uses System.currentTimeMilliseconds() to find out what the current time is so it can calculate the difference since last time. System.currentTimeMilliseconds() is part of the Java runtime library so I don't think I can edit that. I can add a line of code to the top of Timer.updateTimer() so the timer doesn't update if I'm drawing the second eye. This is the easiest method, but the eyes won't be perfectly in synced - if you're in multiplayer and another player's position has updated even if the game thinks no time has passed then the other player will be drawn at a different position for each eye.
There are pros and cons of doing either method, and if I am going to do anything it'll be at the OpenGL level. I'll look into display lists (an OpenGL way of letting you record commands then play them back exactly - though I wonder about the speed of recording into a display list every frame) because it'll beat modifying every OpenGL call.
Of course if you have a steady frame rate >60fps then this is a lot of effort for little result.
Apologies for the long post - it helps to find a solution when you explain the problem aloud! :smile.gif:
0
Thank you!
Cross-eyed is a bit difficult to focus first, and works best if you're playing the game in a small window or sitting a bit back from the screen. Also I wouldn't recommend playing it for half a day straight on cross-eyed unless you want some serious eye strain. But it is a cheap way to try out 3D without needing any special kind of glasses.
Basically the image the right eye sees is shown on the left half of the screen, and vice versa. Then you look at your screen cross-eyed. As you go cross-eyed you'll notice the two images come closer together and overlap. Try to get them to overlapped perfectly (in my experience this is easier if you focus on something static like the cross hair while wiggling the mouse so the background animates).
0
You're welcome!
I have more ideas on how to speed this up. I definitely know the performance problem exists at the OpenGL/Direct3D border - probably because each frame is going GPU(GL)->CPU->GPU(D3D) - at 1920x1080/32bbp that's 8,294,400 bytes each way per eye per frame! I've discovered there are some OpenGL extensions that allow you to use Direct3D resources - specifically let OpenGL draw straight into a Direct3D surface. Hopefully if used correctly the GPU will draw straight into the Direct3D texture without needing to transfer anything through the CPU. But, the problem with OpenGL extensions is they're vendor specific - this extension I'm looking at is nVidia specific.
That's actually a more interesting problem than it first seems. My code is working at the OpenGL layer and has no concept of what Minecraft is doing. So I can't tell Minecraft to draw the scene twice, so instead I let the game loop run twice - once for the left eye and once for the right eye so you're actually getting alternating frames to each eye. If you can maintain a steady 60fps (30fps per eye) this should be no problem, actually if you can maintain 120fps then each eye is updating as fast as the NVidia 3D Vision glasses can show. Anyway I do agree that it is distracting at choppy framerates. I'll look into ways to get the eyes rendering together. One possible way could be by recording the OpenGL calls as Minecraft draws one eye then play back the identical calls for the other eye (this introduces some special cases like what if Minecraft updates a texture half way through drawing one eye, do I record and play that back too?) I guess only experimentation will tell!
0
That wouldn't be so hard - but you need to disable Minecraft's cross hair or else it will interfere. I can't do that without modifying minecraft.jar (which I want to avoid since it means my mod will break with updates).
Yeah but it wouldn't stop you from seeing double crosshairs (infact the z-depth of Minecraft's crosshair might interfer with the NVidia's cross hair making it appear a lot closer than the actual depth where it should be).
0
Thank you very much!
Yeah, I'm going to work on that issue. It's to do with me locking GPU resources each frame - I've thought of a bunch of ways to speed it up.
I don't think that will work unless I manually draw the NVidia 3D Vision crosshair in because of the way I'm mixing OpenGL/DirectX. I will experiment. Likewise I'm ignoring the depth values the NVidia 3D Vision controls tells me to use and overriding it with the values you set in the configuration tool I provided. I could add an option to ignore the custom depth values and use NVidia's instead - then you can use the 3D Vision dongle's wheel to adjust the depth!
0
Are you using Red/Cyan glasses? The problem with the anaglyph (tinted glasses) is that the lens are tinted to only let specific colours through to each eye - so you are going to loose one colour channel (out of red, green, blue) to one eye, and that colour will instead be sent to the other eye. With Red/Cyan glasses you sacrifice red. There's nothing I can do about that.
You can also get Green/Magenta and Blue/Yellow glasses. I think Blue/Yellow glasses will give the best effect because you sacrifice blue, giving the sky and water a washed-out grey/slightly-green tinge but otherwise sand, grass, and wood retain it's colour.
Here is a list http://en.wikipedia.org/wiki/Anaglyph_image#Possible_color_schemes of popular colour schemes and what colours they sacrifice.
0
Maybe you could use a bucket with the cloud and it cuts a square out of the cloud as it flies over to collect water vapour. What you'd use water vapour for I don't know.. Steam powered engines? :biggrin.gif: Placing a bucket of water into a furnace could have the same effect.
0
Is the only problem the performance or is there something not working?
I think I may know what's causing this. I'm locking a Direct3D texture to draw the output of the game in to, and I think this locking has a performance penalty so there should be a way to significantly speed this up. I'll look into it soon! Thanks!