GMsphere (demo based on Deskope from AngelJ)

[AngelJ]

Some media players let you select different video rendering methods. It may be worth trying other methods.

Yeah, turning off hardware acceleration always solved the problem for me. That's if RoTaToR's having the same problem in the first place. I'm not sure from how he described it.

[blindboxes]

Any chance for screenshots for those that hasn't been rifted? Also, how does this compare to Ibex?

http://hwahba.com/ibex/

[geekmaster]

Any chance for screenshots for those that hasn't been rifted? Also, how does this compare to Ibex?

http://hwahba.com/ibex/

Just take a screenshot of part of your desktop, except in the Rift it will wrap around you from way up above to way down below you, and from your left around the front to your right, like a gigantic movie screen far away. No pre-warp. Just raw pixels from your desktop, and we let the RiftDK lenses and head tracking wrap it around you automagically.

It is like the Matrix. Nobody can explain it to you. You cannot take a screenshot, because all you will see is the desktop now in front of you. You have to see it and experience it to understand. Until then, you can only imagine it according to those of us who are Riftfully fulfilled and Riftfully aware, who have described it to you the best that we can.

All I can say is that the pixels are not blurred by software warping, but are a direct 1-to-1 mapping from the desktop to the virtual sphere that surrounds you, so ALL of the pixels are the best that they can be within current hardware limitations.

Although it LOOKS spherical everywhere you look, the lenses display it as an "asphere", which defies reality. You will not realize it until you try to map true spherical content into it, where the very top and bottom will not come to a radial center as expected, but will look just the same as looking forward. From a mathematical point of view, it is like a large square sheet of paper, on which the top edge wraps around to the bottom (like a horizontal cylinder), while at the same time the left edge wraps around to the right edge, like a vertical cylinder. Although not physically possible in three-dimensions, it appears spherical with your restricted FoV while you are inside it. It has four-dimensional properties due to its natural optical apherical projection.

But when it contains your desktop, it looks like a gigantic curved movie screen wrapped beyond your FoV in all directions. And my "background" versions paint interesting patterns in EVERY direction, wherever the desktop does not cover them.

How can I screenshot that?

There, now do you understand?

[blindboxes]

*snip*

I get what you mean. I just wanted to see a screenshot so that I can see how well and how exactly it works. I heard the Rift's resolution just isn't there yet for this purposes, and my interest in the Rift have always been in having more screen-estate area. Well, actually, gaming first but we got that part covered.

I may not have asked this question if you mentioned what exactly this is. Is it fancy patterns in your face if you have a Rift on? Is it about having a virtual worktable? I think I saw another thread in here somewhere that never mentioned what the heck the posted program does, but just tells rift users to try it. If I had some information I could at least imagine it. My addiction to information is crazy, it's probably a side-effect of my work that requires me to read hundreds of datasheets.

[geekmaster]

I get what you mean. I just wanted to see a screenshot so that I can see how well and how exactly it works. I heard the Rift's resolution just isn't there yet for this purposes, and my interest in the Rift have always been in having more screen-estate area. Well, actually, gaming first but we got that part covered.

I may not have asked this question if you mentioned what exactly this is. Is it fancy patterns in your face if you have a Rift on? Is it about having a virtual worktable? I think I saw another thread in here somewhere that never mentioned what the heck the posted program does, but just tells rift users to try it. If I had some information I could at least imagine it. My addiction to information is crazy, it's probably a side-effect of my work that requires me to read hundreds of datasheets.

A "screenshot" is a copy of the memory containing the pixels, saved in a standard image format such as JPEG or BMP. Because this program projects your Windows desktop onto a curved "screen" in virtual space, such a screenshot would be of your Windows destop.

The best we can do is to draw an "artist's rendition" of what it FEELS like while viewing it inside the RiftDK. The problem is that although the virtual "curved screen" containing your desktop LOOKS spherical, it feels like you are not standing at the center of that sphere, but rather that you are standing even closer to the screen. However, no matter which direction you look, you get that same perspective, making it a bit like you are standing in an "alternate reality" with a different set of the laws of physics. It all seems "natural" from a local perspective, but when you look around and try to construct a model of this "sphere like" construct, you realize that you do not have the imagination necessary to depict a physical model of it that can be viewed from outside the RiftDK.

The best I can do is say that it feels like I am standing inside a sphere, but it feels like I am standing closer to the surface of this sphere than its center (no matter which direction I look). I can change the perceived diameter of this sphere by changing the amount of overlap of my left and right views (effectively changing my virtual IPD). I can use this variable offset to create a series of nested spheres of different apparent diameters. I can project "sprites" onto any portion of any of those spheres with a simple "blitter" operation (rectangular area copy) making them appear to be at different distances from me. I can turn on or off any pixel (or subpixel), creating light-emitting spots or areas of any shape or color (or a pattern of colors). I can even project a natural-looking photo, or a stereoscopic pair of photos, onto my spheres. Or I can project adjacent portions of a virtual object onto different adjacent spheres to give it 3D depth.

If I want to, I can perform distortion-correction, to flatten out the curvature induced by the RiftDK lenses, but this will smear the pixel data across multiple physical pixels on the RiftDK display, and this goal of THIS project is maximum pixel integrity at the expense of accurate "virtual world" geometry, so that we can display useful text and data in our VR world (including things like email and other interactive documents).

Is that a better description?

[Mystify]

I get what you mean. I just wanted to see a screenshot so that I can see how well and how exactly it works. I heard the Rift's resolution just isn't there yet for this purposes, and my interest in the Rift have always been in having more screen-estate area.

The key here is that the resolution of the virtual screen is just as good as your normal monitor. Its not shrinking the desktop to fit, it isn't rendering it to a texture and leaving you to make out the blurry result. It is giving you the exact same pixels that you would normally see, with all the clarity you normally get, with the ability to look around.

[Ericshelpdesk]

Kinda like an omnimax movie?

[geekmaster]

Kinda like an omnimax movie?

EXACTLY like an omnimax movie, except you are not sitting at the center of the theater. More like you are in the third row!

And no matter which direction you look, you are always the same distance from the screen. The lenses cause pincushion distortion, moving the pixels to the "wrong" (not planar) geometric location (perceived as the inside of a large curved screen), but those pixels are in sharp focus and not blurred by warp distortion correction software.

A nice side effect of the pincushion distortion from the lenses is that the screen seems to wrap around you, giving a very immersive effect. And the head tracking extends that wraparound view all the way around you in every direction. You can see other desktops elsewhere in this "PixelBall" if your Windows desktop is extended to multiple monitors. All of them show up (including the RiftDK, which shows recursive video feedback like a "hall of mirrors"). I plan to remove the RiftDK from the desktop when I render it into the VR PixelBall.

These experiments have been awesomely fun for me. I hope you join me in this VR experience. It can actually be useful, allowing you to work with existing desktop applications (with sufficiently small resized windows so you do not get neck strain using them). And no need to copy the entire desktop into the PixelBall. We can just copy individual windows in there (even if they are buried under OTHER windows on your "real" Windows desktop).

There is no need to display ONLY Windows desktop content in the PixelBall. I have successfully drawn color-animated pixel patterns to every pixel everywhere in it (some of the above "CPU-heavy" GMphere versions). I can also directly render movies and live video into the PixelBall without displaying in a window on the desktop. And I plan to render the internet DIRECTLY into the PixelBall without using a desktop window. I have successfully compiled and tested the chromiumembedded internet browser, and I plan to modify the system render code to draw directly onto PixelBall pixels.

I plan to support panoramic (full wraparound) and stereoscopic (3D) video and images, including viewing data "live" from these websites:
http://gigapan.com/gigapans?order=most_popular
http://3d-360.com/
http://www.ryubin.com/panolab/panoflash/download.html
And fisheye webcams on the internet (live and youtube) like these (unwrapped to a full hemisphere):
http://www.youtube.com/watch?v=bKTCw2cKAKw
http://www.youtube.com/watch?v=wJaUznyD9LE
... and more!

And I want to add cool games and toys too, like this interesting little demo:
https://www.youtube.com/watch?v=Apr1xgsLWes

And of course, I want a 3D construction set (using the Razer Hydra), combining the best aspects of these awesome toys:
http://www.hasbro.com/playdoh/en_us/
http://en.wikipedia.org/wiki/Magnetix
http://en.wikipedia.org/wiki/Erector_Set
http://en.wikipedia.org/wiki/Tinkertoy
http://en.wikipedia.org/wiki/Lincoln_Logs
http://en.wikipedia.org/wiki/K'Nex
And of course, let's not forget this:
http://en.wikipedia.org/wiki/Lego

We need to be careful to avoid trademark infringement while playing with our virtual toys though...

Enjoy!

[Mystify]

I will definitely try this out when my rift arrives, this sounds pretty awesome.

[gray]

I will definitely try this out when my rift arrives, this sounds pretty awesome.

It's very cool, looking forward to the additions mentioned above also.

[geekmaster]

With dual fisheye cameras, we can configure them back-to-back for full 360-degree wraparound like these:
http://www.youtube.com/watch?v=Qa4veMMmvvk
http://www.youtube.com/watch?v=q98PhjIr6N8

Or we can place them side-by-side for stereoscopic 3D 180-degree wraparound like this:
http://www.youtube.com/watch?v=OXGRVG-kDTY

But for stereoscopic fisheye video, we lose the parallax and 3D effect when looking to the sides. I believe we can create 3D when the cameras are moving forward, by using frames delayed a little in time (different viewpoint after moving) for one eye (similar to "Pulfrich effect" 3D video, which normally uses a darkening filter over one eye to cause a perceptual delay).

My PixelBall will be the perfect place to view all this wraparound and 3D (and 3D wraparound) content, including lots of undiscovered stuff out there on the internet. And best of all, fisheye content is already corrected (mostly) by the Rift optics (at certain FoV settings) causing no additional blurred pixels.

Although not a geometrically accurate model of a real-world object, my PixelBall still makes a very interesting and useful tool for VR media creation, consumption, and just plain fun!

[geekmaster]

Check out these relevant hacks for creating "PixelBall" content:

Fisheye lens for your SLR:
http://hackaday.com/2010/04/20/fisheye- ... -your-slr/

Fisheye Digital Imaging For Under $20:
http://aggregate.org/DIT/peepfish/

360 degree video for next-to-nothing:
http://hackaday.com/2010/01/04/360-degr ... o-nothing/

Panoramic scanner camera:
http://hackaday.com/2009/12/29/panorami ... er-camera/

Panoramic and spheric tripod rig:
http://hackaday.com/2010/07/14/panorami ... ripod-rig/

Motorized camera rig makes panoramic shooting simple:
http://hackaday.com/2012/07/24/motorize ... ng-simple/

Spherical and stereoscopic photography:
http://hackaday.com/2010/01/14/spherica ... otography/

Wide angle lens for the ATC2K video camera:
http://hackaday.com/2008/06/30/wide-ang ... eo-camera/

Panoramic ball camera; toss to snap a picture:
http://hackaday.com/2011/10/14/panorami ... a-picture/

Operation StratoSphere:
http://hackaday.com/2013/01/18/operation-stratosphere/

Stereoscopic video taken by using radio controlled aircrafts:
http://www.stereofpv.com/

[dreiter]

Excellent work with this, very good effect. I too would like to be able to shrink the screen a little. Perhaps it's because I am using the B cups, but the screen is so big that I have to make the video player window small to watch a movie like I would at the theater. If you could add some 'zoom' support, I think the program would be nearly perfect.

[AngelJ]

Meanwhile, I am working on a new software framework for this app that should use a lot less CPU overhead.

Can you give anything away about this? For a couple of reasons I was looking into an alternative that talks directly to the DWM (maybe the Magnification API is as good as it gets?).

Anyway, I thought DirectShow looked promising, but while looking into the sample filter PushSourceDesktop I found this line of code:

Code: Select all

    // bitblt screen DC to memory DC
    BitBlt(hMemDC, 0, 0, nWidth, nHeight, hScrDC, nX, nY, SRCCOPY);

I decided maybe I stumbled into the best solution from the start. So I'm gonna go forward with that.

[geekmaster]

Meanwhile, I am working on a new software framework for this app that should use a lot less CPU overhead.

Can you give anything away about this? For a couple of reasons I was looking into an alternative that talks directly to the DWM (maybe the Magnification API is as good as it gets?).

Sadly, it took me WAY TOO MANY HOURS to figure this stuff out again after years of not using it. I needed to get away from those horrible GDI SetPixel() functions and get my hands on the bare pixel bytes without a bunch of extra WINAPI function calls. I figured out a way that works for me.

Should I keep all this hard (re)work a "trade" secret, or should I share it with the world for free?

Well, I am always a generous soul, so I will share my "secret sauce" just like I always do. At the moment I am using this, but I am NOT using the "stretch" feature of StretchDIBits() because it only does "nearest neighbor" and "line/column discard" resizing:

Code: Select all

	int wndX=100,wndY=100,wndW=1024,wndH=1024;
	int iStyle=WS_EX_TOPMOST|WS_POPUP; // fullscreen
...
	WNDCLASS wc = { 0,WndProc,0,0,g_hinst,NULL,0,0,NULL,szAppName };
	hwnd=CreateWindowEx(0,szAppName,szAppTitle,iStyle,wndX,wndY,wndW,wndH,NULL,NULL,hinst,0);
...
	hdc=GetDC(hwnd);
	hdcMem=CreateCompatibleDC(hdc);
	hBitmap=CreateCompatibleBitmap(hdc,1024,1024);
...
	frames++;
	for (y=0;y<1024;y++) for (x=0;x<1024;x++) {
		fbL[y][x]=(((abs((x&511)-256)-frames*2-73)&255)<<16)+(((abs((y&511)-255)-frames)&255)<<8)+abs(((frames*6+27)&511)-256);
	}
	StretchDIBits(hdc,0,0,1024,1024,0,0,1024,1024,fbL,(BITMAPINFO*)&bmi,DIB_RGB_COLORS,SRCCOPY);

It gives me direct access to the pixel framebuffer, and it provides (crude) image stretching and shrinking. I have not finished testing my "pseudo-Bressenham's" blitter code to replace it yet. Last time I wrote a full multi-featured blitter (with inline ASM) based on Bressenham's algorithm was back in about 1992 (and some of those brain cells got "recycled"). Because windows provides such crappy image resizing I will have to write my own (or let OpenGL do it, but that would be "cheating")...


For speed, I update my display with head tracking at 60Hz, but I only copy the desktop screen at 24Hz (movie theater standard framerate). I use a single timer driving a DDA timing chain to keep my multiple virtual clocks synchronized.

And those nested "for loops" you see in my code above draw an interesting animated pattern, but the way. I plan to use it for an animated background (one of many) for my "PixelBall").

P.S. This is unfinished code, so please pardon my use of hand-tweaked "magic numbers". Complaints about such matters is one reason a lot of people choose to NOT share their source code. My code suits me well, and that is what matters most to me.

[geekmaster]

Excellent work with this, very good effect. I too would like to be able to shrink the screen a little. Perhaps it's because I am using the B cups, but the screen is so big that I have to make the video player window small to watch a movie like I would at the theater. If you could add some 'zoom' support, I think the program would be nearly perfect.

I agree that desktop screen shrinking is necessary in the Rift, to avoid neck strain from looking so high above you to find the top of your Windows desktop. But we need to be very careful to avoid blurring the pixels unnecessarily while downsizing.

I plan to use a modified Bressenham's blitter to resize the screen, while maintaining sub-pixel accuracy, and while preserving whole pixels on pixel boundaries without unneccessarily "averaging" them with a neighbor (to preserve sharp edges). Most available existing blitter code has a number a various deficiencies that affect speed and/or image quality, so I am using this approach again (which worked will for me about 20-years ago)...

When the text gets down to a couple of pixels wide, I will activate my "software-only sub-pixel wobulation" resolution enhancement technique that I invented/developed/tested recently. Although it works very well on a desktop LCD panel, it makes me dizzy in my Rift, so I need to limit when and were I apply it. However, text is quite readable even when shrunken down to just two or three full pixels wide, and need not align to full pixel boundaries. It requires the Rift to be operated in its native 1280x800 resolution, however (but that is needed to benefit from GPU sub-pixel downsampling anyway).

And yes, I like "bare-metal bit-bashing and pixel-pushing", with direct framebuffer access to the raw pixels, so that I can bend them to my will. Most people are amazed at what can be done with CPU alone (no GPU) with a few "old-school" tricks. But then, even GPU coders need to resort to plenty of tricks too. And not using the GPU will let my code work fine on budget computers that do not even HAVE a CPU. So my methods will have their place with the Rift (especially for low-budget portable applications). And when I *DO* get around to playing with GPUs, aha! I plan to see some people drop their jaws once again...

[AngelJ]

Thanks for sharing geekmaster. I'll have to try that out because from looking at it I have no idea how it works. So you never blit from the screen?

I agree that desktop screen shrinking is necessary in the Rift, to avoid neck strain from looking so high above you to find the top of your Windows desktop.

Did you experiment with higher PPD settings? It makes the screen feel smaller but things get shakier.

[geekmaster]

Thanks for sharing geekmaster. I'll have to try that out because from looking at it I have no idea how it works. So you never blit from the screen?

I agree that desktop screen shrinking is necessary in the Rift, to avoid neck strain from looking so high above you to find the top of your Windows desktop.

Did you experiment with higher PPD settings? It makes the screen feel smaller but things get shakier.

This code does not use the desktop contents. I plan to copy individual windows from the screen using WM_PRINTCLIENT messages. I will still support your method of grabbing from the screen to, which I may need for animation. But I plan to add direct PixelBall rendering to ffmpeg (or perhaps VLC if I can get a clean compile out of that), to avoid needing to do screen captures from the desktop. I also have the chromiumembedded web browser working from a fresh compile, so I plan to render internet content directly into my PixelBall too, bypassing the Windows desktop altogether.

The problem with using "other people's code" is that I want my stuff to work on Windows and Linux, on a desktop PC and on my Raspberry Pi (and on my Ouya when I get it). At least they all support some form of OpenGL, so I will eventually migrate to that when my direct framebuffer rendering is not enough...

The main key point I have been pushing is that content rendering can be significantly slower than head tracking and display updates (i.e. "PTZ Tweening"), such as I mentioned above where I render at 24Hz but display with head tracking at 60Hz. With slow enough content renders, you can use much less power-hungry CPU and/or GPU hardware, which has significant benefits for battery-powered portable applications. Having herky-jerky "Mister Roboto" animated characters around you is much less disturbing as long as you can look around quickly and freely.

I played with a lot of PPD settings. You can go from 1-to-1 which looks like your display is fixed in place, to a high PPD which looks like you are looking through high-power binoculars at very distant pixels. As I mentioned previously, more than about 7x magnification (high PPD) requires that you hold very still (just like while using high-power binoculars in real life). More than 20x generally requires a tripod and/or digital image stabilization, and we may be able to simulate that in the PixelBall too, when you need really high power magnification of very distant very tiny pixels (on one of the outermost concentric PixelBalls).

[jf031]

I haven't tried this yet, as I don't have a Rift, but please add in an option to have the desktop itself display at 60Hz (or, ideally, at whatever framerate the user wants the desktop to come through). I'm very interested in trying out software with images that tend to render at 50 or 60 fps, such as emulated video games in MAME (in windowed mode, actual game resolution, and in non-3D-accelerated mode so it works in GMSphere) and other emulators. I understand if you don't want to support this, for whatever reason(s), as it isn't incredibly important to me to play emulated games (or 60fps video) in this manner. I'm not even sure if my measly Core2Duo E8400 & AMD Radeon HD5700 can manage it, anway.

Also, I must state that the vast majority of online digital videos are ~30 fps, not 24, as most monitors are 60Hz. There is a definite possibility that forcing 24Hz updates from the desktop will result in (added) jitter on video playback. EDIT: I don't know what I'm talking about, here.

[AngelJ]

...such as I mentioned above where I render at 24Hz but display with head tracking at 60Hz.

That's really clever. It just wouldn't work for things that run at a faster frame rate. I think in future versions of Deskope I'll make the screen capture rate configurable.

[geekmaster]

...such as I mentioned above where I render at 24Hz but display with head tracking at 60Hz.

That's really clever. It just wouldn't work for things that run at a faster frame rate. I think in future versions of Deskope I'll make the screen capture rate configurable.

It works okay to drop frames at regular predictable rates (commonly performed in video framerate conversion) as long as the head tracked panning is smooth. That is why I use 1024x1024 framebuffers for each eye, to support 60Hz head-tracked panning within that buffer between framebuffer content updates. If you move your head too fast, a portion of your image may be clipped (or extrapolated) and you will quickly learn to slow down to accommodate the speed of your hardware.

Using a slower RENDERING framerate may affect your Kill/Death Ratio in blood-thirsty competitive online games, but for that you may prefer a large multi-monitor setup anyway.

I am trying to target value-priced economy hardware usage with the Rift, including the Raspberry Pi or Ouya, where a slower framerate is vastly preferred to NO support whatsoever. However, I certainly CAN support higher framerates (perhaps automatically selected) when the hardware is up to the task.

[dreiter]

So you are basically promising that a new version with every feature you have discussed will be released today. Am I reading this right?

[geekmaster]

So you are basically promising that a new version with every feature you have discussed will be released today. Am I reading this right?

Where did you get the "today" idea? Just because I have a large pile of "bits and pieces" of "proof-of-concept" working code does not mean that I have an app that does it all, ready for others to use. There is a ton of configuration and "glue" logic needed to tie it all together in a consistent and coherent manner.

At this moment. I am in the process of porting my "PixelBall" code (used in GMsphere and other apps) to my Raspberry Pi, but it will either have to display a virtual desktop, or a remote desktop over VNC. I just thought I would pop over here while my RasPi is a busy little beaver doing an "apt-get upgrade"...

Just because I have the knowledge, skills, tools and resources to do something does not mean that I can do it all TODAY. I am only human (or at least mostly human).

[Zoide]

I think dreiter was just joking

[Ericshelpdesk]

So you are basically promising that a new version with every feature you have discussed will be released today. Am I reading this right?

Where did you get the "today" idea? Just because I have a large pile of "bits and pieces" of "proof-of-concept" working code does not mean that I have an app that does it all, ready for others to use. There is a ton of configuration and "glue" logic needed to tie it all together in a consistent and coherent manner.

At this moment. I am in the process of porting my "PixelBall" code (used in GMsphere and other apps) to my Raspberry Pi, but it will either have to display a virtual desktop, or a remote desktop over VNC. I just thought I would pop over here while my RasPi is a busy little beaver doing an "apt-get upgrade"...

Just because I have the knowledge, skills, tools and resources to do something does not mean that I can do it all TODAY. I am only human (or at least mostly human).

I think Geekmaster's lack of transparency in his geekball development has led to over optimistic expectations among his investors and he needs to have more updates letting us know how development is going, what piece he's working on, what line of code didn't compile right, etc. If he can post here every 15 minutes or so, then we can get a better idea of his process and what's leading to his delays in shipping out a useful program.

[geekmaster]

I think Geekmaster's lack of transparency in his geekball development has led to over optimistic expectations among his investors and he needs to have more updates letting us know how development is going, what piece he's working on, what line of code didn't compile right, etc. If he can post here every 15 minutes or so, then we can get a better idea of his process and what's leading to his delays in shipping out a useful program.

You mean that OTHER PEOPLE are interested in my technical exploits that I persue to pique my own personal interests and natural curiosity? Amazing!


Investors? I have investors? When did that happen? How? You do not even know my PayPal address!

Requested progress status update: I am now double-buffering my Raspberry Pi framebuffer access, and only touching the real framebuffer once per frame now, to copy my back buffer into the framebuffer. MUCH faster. I am about to fold my text-only head tracking testing code into my framebuffer handler so that I can look around at the pixels all around me.

More updates later (but real life will suck a large chunk of time soon). I need to figure out how to incorporate my real life stuff inside my virtual world...

[dreiter]

Where did you get the "today" idea? Just because I have a large pile of "bits and pieces" of "proof-of-concept" working code does not mean that I have an app that does it all, ready for others to use. There is a ton of configuration and "glue" logic needed to tie it all together in a consistent and coherent manner.

At this moment. I am in the process of porting my "PixelBall" code (used in GMsphere and other apps) to my Raspberry Pi, but it will either have to display a virtual desktop, or a remote desktop over VNC. I just thought I would pop over here while my RasPi is a busy little beaver doing an "apt-get upgrade"...

Just because I have the knowledge, skills, tools and resources to do something does not mean that I can do it all TODAY. I am only human (or at least mostly human).

I think dreiter was just joking

Definitely a joke, but I am glad to see geekmaster is still keeping tabs on his fan base.

[geekmaster]

I thought of another analogy for using your Windows desktop in GMsphere: it is like you are reading a newspaper with your nose inches from the page (except you are farther away and the newspaper is the size of a large building). Remember, in the Rift DK, you can see the pixels if you look closely (i.e. "screendoor"), so try that on your real desktop monitor...


Hint: Small windows help a lot, so resize them down to where they are useful in the PixelBall VR environment...

[Ericshelpdesk]

Any chance you would be able to make it either mimic or emulate 3D vision?

So many games to live inside of that could be improved with a huge faked 3D screen. This setup would be a good interim step on those games that don't scale well to rift emulation, but would look spectacular on an enormous curved monitor.

I've already got a 78" 3D screen, I want BIGGER.

[geekmaster]

Any chance you would be able to make it either mimic or emulate 3D vision?

So many games to live inside of that could be improved with a huge faked 3D screen. This setup would be a good interim step on those games that don't scale well to rift emulation, but would look spectacular on an enormous curved monitor.

I've already got a 78" 3D screen, I want BIGGER.

I watched "Sintel 3D SBS-Half" lastnight, after I migrated my GMsphere code into the SDL rendering module of mplayer. Now I can render video (including stereoscopic 3D) directly into my "PixelBall" environment used in the GMsphere app. I will release it after I fix some bugs (mostly color artifacts from changing the IPD by cropping the centers, on YUV-encoded video frames). I also do not support other video formats yet. But SBS 3D video is not a problem (it works GREAT!). Essentially, each eye has its own PixelBall (if you can imagine that).

Beware that 720p SBS-Half movies (like Sintel) are already only 640-pixels wide per eye. Then you crop 90-pixels off the center (45-pixels per eye) to adjust for IPD. Using direct one-to-one pixel mapping (no extra pixel distortion) your total FoV extends just beyond your FoV on each side, but the video ends up not very tall (only 360-pixels tall with letterboxing, or much less with letterbox removal). Alternate choices are to keep the original 720p and expand the width to 2560 pixels (1280 per eye), but at the Rift high magnification the interpolated pixels do not look as good as on a desktop LCD, and the video frame extends to 212-degrees (more than 180), pushing a lot of important detail outside your FoV, and needing to look over your shoulders to watch the sides of the screen does not work that well for content designed for a standard movie screen. Another possiblity is to leave the original SBS-Half video in its original form, and just let things be too tall and narrow (preserving the most visible undistorted pixels you can get). 1080p SBS-Half content would help, but a lot of online SBS-Half content (including youtube HD) is only 720p...

My goal is to get this working on my Raspberry Pi too, which is why I did not convert from YUV to RGB (using the CPU -- too much overhead). I will probably need to do the colorspace conversion (if needed) in a shader to work on the RasPi. For now, my RasPi version of GMsphere just displays interesting patterns wrapped around you (no desktop). But you can look around you with Rift head tracking now, even on a RasPi. You can find that demo in the "Rift Pi" thread.

And no matter what you do, you can still see the pixels, but it is still really awesome! I very much prefer viewing undistorted pixels on a virtual ASPHERIC screen (i.e. GMsphere), than distorted pixels on a geometrically accurate spherical projection (i.e. VR Player from StephaneLX), especially when viewing text (as on a Windows desktop). Each environment has its own niche applications. And I plan to support accurate geometry as a user-selectable option when I migrate my 360-degree 3D panorama viewer into this code (later)...

[michal]

Any chance this will ever be available for Mac OS X? Or is that outside the scope of your ambitions?

Regards,
Michal

[geekmaster]

Any chance this will ever be available for Mac OS X? Or is that outside the scope of your ambitions?

Regards,
Michal

I have part of this codebase working on Linux (and in my Raspberry Pi), so getting it on MacOS and Android should be fairly easy. I do not have a Mac to test it on though...

It works in VirtualBox, so you should be able to at least test it with a Windows VM on your Mac, as it is now. You need to pass the Rift USB port through to the VM, but it works great for me (and others). That is how I tested the Rift head tracker code for linux (linux VM in VirtualBox on Win8, with Rift USB passthrough to VM). In your case, put Windows inside the VM to run GMsphere. At least it will give you a taste of what we described above...

[Ericshelpdesk]

Any chance you would be able to make it either mimic or emulate 3D vision?

So many games to live inside of that could be improved with a huge faked 3D screen. This setup would be a good interim step on those games that don't scale well to rift emulation, but would look spectacular on an enormous curved monitor.

I've already got a 78" 3D screen, I want BIGGER.

I watched "Sintel 3D SBS-Half" lastnight, after I migrated my GMsphere code into the SDL rendering module of mplayer. Now I can render video (including stereoscopic 3D) directly into my "PixelBall" environment used in the GMsphere app. I will release it after I fix some bugs (mostly color artifacts from changing the IPD by cropping the centers, on YUV-encoded video frames). I also do not support other video formats yet. But SBS 3D video is not a problem (it works GREAT!). Essentially, each eye has its own PixelBall (if you can imagine that).

Beware that 720p SBS-Half movies (like Sintel) are already only 640-pixels wide per eye. Then you crop 90-pixels off the center (45-pixels per eye) to adjust for IPD. Using direct one-to-one pixel mapping (no extra pixel distortion) your total FoV extends just beyond your FoV on each side, but the video ends up not very tall (only 360-pixels tall with letterboxing, or much less with letterbox removal). Alternate choices are to keep the original 720p and expand the width to 2560 pixels (1280 per eye), but at the Rift high magnification the interpolated pixels do not look as good as on a desktop LCD, and the video frame extends to 212-degrees (more than 180), pushing a lot of important detail outside your FoV, and needing to look over your shoulders to watch the sides of the screen does not work that well for content designed for a standard movie screen. Another possiblity is to leave the original SBS-Half video in its original form, and just let things be too tall and narrow (preserving the most visible undistorted pixels you can get). 1080p SBS-Half content would help, but a lot of online SBS-Half content (including youtube HD) is only 720p...

My goal is to get this working on my Raspberry Pi too, which is why I did not convert from YUV to RGB (using the CPU -- too much overhead). I will probably need to do the colorspace conversion (if needed) in a shader to work on the RasPi. For now, my RasPi version of GMsphere just displays interesting patterns wrapped around you (no desktop). But you can look around you with Rift head tracking now, even on a RasPi. You can find that demo in the "Rift Pi" thread.

And no matter what you do, you can still see the pixels, but it is still really awesome! I very much prefer viewing undistorted pixels on a virtual ASPHERIC screen (i.e. GMsphere), than distorted pixels on a geometrically accurate spherical projection (i.e. VR Player from StephaneLX), especially when viewing text (as on a Windows desktop). Each environment has its own niche applications. And I plan to support accurate geometry as a user-selectable option when I migrate my 360-degree 3D panorama viewer into this code (later)...

I've never seen a 3D movie that didn't suck compared to the 3D I can pull out of my wall.

By 3D vision, I mean specifically nvidia 3D vision. I want a pixelball level screen specifically for 3D gaming that's not necessarily related to rift 3D games. For example, the new X-com is never going to be a good candidate for rifting, but looks awesome with nvidia 3D vision on a large flat screen. Because the size of your screen is a major component in how much you can do with the view, I would love to be able to throw it into a sphere.

[geekmaster]

I've never seen a 3D movie that didn't suck compared to the 3D I can pull out of my wall.

By 3D vision, I mean specifically nvidia 3D vision. I want a pixelball level screen specifically for 3D gaming that's not necessarily related to rift 3D games. For example, the new X-com is never going to be a good candidate for rifting, but looks awesome with nvidia 3D vision on a large flat screen. Because the size of your screen is a major component in how much you can do with the view, I would love to be able to throw it into a sphere.

You need to remember that your entire horizontal FoV contains LESS THAN 640 PIXELS per eye! It is an awesome experience for some things, especially if they are designed for this environment.

Nvidia 3D vision is very much tied to their product line, and if it does not detect one of their 3D devices it reverts to anaglyph 3D mode. There are other drivers you can use, or just use Vireo Perception.

That said, I do plan to support SBS 3D content on your desktop, but extracting data FROM your video card to map into the PixelBall environment is framerate limited (certainly not 120 Hz). Perhaps I can make it faster by doing this all in a shader running on a GPU shared by the Rift and the desktop (Rift and main monitor plugged into same video card). Amazing things can be done with shaders, and the GMsphere program is fairly trivial (which is what attracted to my attention to Deskope from AngelJ in the first place).

My main goal for GMsphere (and the PixelBall rendering concept) is as a giant wrapound HUD to be used inside other video games and such, allowing limited use of desktop application, web surfing, and social networking without needing to exit VR space). You could have your game in front of you, and various windows and control panels on either side of you (sort of like transparent cockpit windows).

I am sure we will discover other uses, but the key to this whole concept is minimal pixel distortion from 1-to-1 pixel mapping, which also allows it to be used on low-power devices like the Raspberry Pi. And yes, I do have a version of GMsphere (called pixelpi) running on my RasPi (see the "Rift Pi" thread for a download link).

Trying to emulate or even interface with Nvidia 3D Vision seems impractical at this time, unless somebody can suggest a simple method (with references). I like simple...

[Ericshelpdesk]

I've never seen a 3D movie that didn't suck compared to the 3D I can pull out of my wall.

By 3D vision, I mean specifically nvidia 3D vision. I want a pixelball level screen specifically for 3D gaming that's not necessarily related to rift 3D games. For example, the new X-com is never going to be a good candidate for rifting, but looks awesome with nvidia 3D vision on a large flat screen. Because the size of your screen is a major component in how much you can do with the view, I would love to be able to throw it into a sphere.

You need to remember that your entire horizontal FoV contains LESS THAN 640 PIXELS per eye! It is an awesome experience for some things, especially if they are designed for this environment.

Nvidia 3D vision is very much tied to their product line, and if it does not detect one of their 3D devices it reverts to anaglyph 3D mode. There are other drivers you can use, or just use Vireo Perception.

That said, I do plan to support SBS 3D content on your desktop, but extracting data FROM your video card to map into the PixelBall environment is framerate limited (certainly not 120 Hz). Perhaps I can make it faster by doing this all in a shader running on a GPU shared by the Rift and the desktop (Rift and main monitor plugged into same video card). Amazing things can be done with shaders, and the GMsphere program is fairly trivial (which is what attracted to my attention to Deskope from AngelJ in the first place).

My main goal for GMsphere (and the PixelBall rendering concept) is as a giant wrapound HUD to be used inside other video games and such, allowing limited use of desktop application, web surfing, and social networking without needing to exit VR space). You could have your game in front of you, and various windows and control panels on either side of you (sort of like transparent cockpit windows).

I am sure we will discover other uses, but the key to this whole concept is minimal pixel distortion from 1-to-1 pixel mapping, which also allows it to be used on low-power devices like the Raspberry Pi. And yes, I do have a version of GMsphere (called pixelpi) running on my RasPi (see the "Rift Pi" thread for a download link).

Trying to emulate or even interface with Nvidia 3D Vision seems impractical at this time, unless somebody can suggest a simple method (with references). I like simple...

http://www.tridef.com/forum/viewtopic.php?f=2&t=3248
I think we have a winner.
TriDef can do side by side output.

Now you can 3D while you 2D in your 3D.

[dreiter]

It's quiet in here.....too quiet....

[geekmaster]

It's quiet in here.....too quiet....

Okay, status update:

I figured out how to capture entire individual window contents (including parts you need to scroll to see) on the desktop, even when they are minimized or partially covered or offscreen (using the PrintWindow interface). I also figured out how to use windows API calls to do high quality window resizing (not nearest-neighbor), so that GMsphere can scatter your individual desktop windows anywhere in the PixelBall (even off the main destop), and you can reduce their size while they remain readable, to reduce neck-strain. Good things come with patience...

I also have a limited-functionality version of GMsphere PixelBall running in my Raspberry Pi. I called that demo "pixelpi" and I published an executable in the "Rift Pi" thread.

As mentioned previously, I plan to add built-in support for a video player and a VNC client, so you can bypass the desktop copies and render directly into the PixelBall environment (for increased efficiency and rendering speed). And VNC will let you remote access desktops on other computers too.

I also have some working GPU GLSL shader code working in my RasPi that I plan to use with this project, and I was SHOCKED at how fast it runs. Wow! I want to do as much of this in the GPU as possible after seeing what a different GPU code can make (especially on the RasPi).

And of course, I will support other devices too (Ouya, x86 linux, and perhaps Max OSX too)...

[Ericshelpdesk]

When my rift gets here, I'll need to figure out how to hack this into my work computer without setting off alarms. My biggest complaint when I go into the office is that I give up my monitors at home for a 15" laptop screen. This could fix that problem.

[michal]

And you don't think anyone at work will notice that you're wearing a huge box on your face?

[BOLL]

And you don't think anyone at work will notice that you're wearing a huge box on your face?

The alarm would probably be software policies preventing installs A box on his face might actually raise less suspicion, especially if he's working in a separate office.

As reference, my previous job was as IT-admin at an office. I never walked around looking at what people did, I just noticed when odd stuff appeared in the maintenance software :p The few times I did notice weird activities was when I unannounced went to their office for on site maintenance or when debugging a machine and strange files were everywhere, haha.