Just look at that and tell me it would’nt be perfect in VR =)
- VR Go
- VR Lemmings
- Lessons from the VR field #1
- Creating VR games – the fundamentals
- VRLux – PostMortem
- VRST 2012 Keynote: Improving the VR experience
- A history of VR (in French)
- An introduction to Immersive Virtual Reality (update)
- Existing VR games ?
- Some news
- New immersive cubes
- Quick links #10
- Body representation in VR
- Razer Hydra – Cheap magnetic tracking
- #2: Eric Hodgson on spatial perception, redirected walking & the split between Old VR vs. New VR | Judderverse VR on Redirected Walking – Playing with your perception’s limits
- #100: Sébastien Kuntz on Virtual Reality Presence & Lessons from 13 years in VR | Judderverse on A Definition of VR
- Near Field VR: Stop-Motion-Kunst in Virtual Reality | VRODO | Deutschlands News-Seite für Virtual Reality und Augmented Reality on Redirected Walking – Playing with your perception’s limits
- Valve’s Entry to VR Targets the Standing Experience | The Games Pusher on Redirected Walking – Playing with your perception’s limits
- 'Holocommander' Oculus Rift RTS Prototype Emerges from Global Game Jam on HoloCommander
- HoloCommander | 3D/VR/AR on HoloCommander
- Episode 2: Eric Hodgson on spatial perception, redirected walking & the split between Old VR vs. New VR | Voices of VR Podcast on Redirected Walking – Playing with your perception’s limits
- Hasan khedr on Lessons from the VR field #1
- Global Game Jam – Oculus Rift Projekte | Bloculus Das deutsche Oculus Rift News Blog on VR Lemmings
- VR Lemmings | VRMonkey on VR Lemmings
- September 2015
- January 2015
- January 2014
- January 2013
- November 2012
- August 2012
- July 2012
- December 2011
- November 2011
- September 2011
- July 2011
- June 2011
- May 2011
- April 2011
- March 2011
- February 2011
- January 2011
- December 2010
- November 2010
- October 2010
- September 2010
- August 2010
- July 2010
- June 2010
- May 2010
- April 2010
- March 2010
- February 2010
- January 2010
- December 2009
- November 2009
- October 2009
- September 2009
- August 2009
- July 2009
- June 2009
- May 2009
- April 2009
- March 2009
- February 2009
- January 2009
- December 2008
- November 2008
- October 2008
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- February 2007
- January 2007
- December 2006
- November 2006
- October 2006
- September 2006
- August 2006
- July 2006
- June 2006
- May 2006
- April 2006
- March 2006
- February 2006
- January 2006
- December 2005
- November 2005
- October 2005
- September 2005
- August 2005
- July 2005
- June 2005
- May 2005
- April 2005
- March 2005
- February 2005
- January 2005
- December 2004
- November 2004
- October 2004
- September 2004
(If you didn’t sleep enough, don’t try to understand the following)
If one day you’re in Visual Studio 2005, creating an object that comes from a DLL compiled with Visual Studio 6, you might run into some allocators issues. Normally things go smoothly because your object is allocated and deallocated with the VC2005 allocator if you create it yourself, or by the VC6 allocator if you’re using specific creation functions that come with your DLL.
What can become very tricky is when this object has a virtual destructor, which means that your object was allocated with the 2005 allocator, but is deallocated with the VC6 allocator. This is not good, and will probably result in a crash nearly impossible to solve unless the above-mentionned DLL is re-built for 2005. Which may not always be possible if you the owner of the DLL doesn’t want to do it himself or give his source code.
Here’s a solution (I’m really happy we have code gurus here..) : allocate the memory for this object using the VC6 allocator. How do you do that? Easy (aha)! Simply load the VC6 runtime dll (msvcrt), find the pointer to the allocator function, and call it !
vc6handle = LoadLibrary(TEXT(“msvcrt”));
typedef void* (*vc6_malloc) (size_t _Size);
vc6_malloc vc6funcptr = (vc6_malloc) GetProcAddress(vc6handle,”malloc”);
TheClass* toto = (TheClass*) vc6funcptr(sizeof(*TheClass));
toto = new (toto) TheClass;
You’ll notice that the new function takes the buffer that was allocated as a parameter. This is not the regular C++ allocator, but a custom one that can take a previously allocated buffer.
I won’t even explained how they did understand the problem …
Any question? =)
Today gentlemen, we will be talking about VR displays!
Read “The state of VR – Displays“.
After speaking about the applications of VR, let’s talk about the devices used to interact with those virtual worlds.
Read “The state of VR – Devices“.
Introducing the PanoramaScreen :
The PanoramaScreen is a cylindrical projection environment for 360°-panoramic projections, which has been developed at the ZKM | Institute for Visual Media in collaboration with the iCinema Research Centre, Sydney since 2005.
The screen has been implemented to display panoramic movies via 4 or 6 projectors, such as 3D animations or video footage. For the recording of 360°-moving imagery, the Institute specially developed a high resolution 360°-PanoramaCamera.
The screen can also be used for stereoscopic VR-applications. Furthermore, the environment is equipped with an 8-channel audio system and offers by means of the Panorama Display Software, a software system developed at the Institute, a wide range of applications for interactive real-time applications, which are being further developed in the context of international artistic and research projects and co-operations.
The first version of the PanoramaScreen [PSI] measures 3.50m in height and 10m in diameter. The second version of the environment with currently a higher resolution [PSII] measures 2.80m in height and 8m in diameter.
Thanks to Whaly
Ken Wittlief, a senior engineer at Vuzix (formerly Icuiti Corp), “makers of VideoEyewear and other micro display systems”, has written an excellent article about do’s and don’ts when creating a stereoscopic entertainment. Here are some highlights of the article, but I highly recommend you to read it all :
(…) our depth perception is only good out to approximately 200 yards. Beyond that distance everything appears to be flat, and we use sideways motion to judge distances. (…)
The first rule of getting it right: you have to know how the images will be viewed. You are creating a virtual space in front of the viewer and you must know what that space is, before you can start placing shapes and objects at different distances. The reward for your attention to this detail is that it is possible to create images that will appear to exist in real space, across the front of the theater, extending halfway out the screen towards the viewer, and receding back for 200 yards or more.
(…) Focus is an issue with no easy solution. The best we can do with existing systems is to not violate the convergence/focus lock the viewers eyes have learned over their lifetime too harshly. [Don't] push objects off the screen more than half the distance to the viewer (…).
(…) The average person has an Inter Pupil Distance (IPD) of 2.5 inches. (…) limit the separation on the screen to the minimum IPD that might be present in the audience: around 2 inches.
(…) The second rule for getting it right: don’t turn the audience into giants! You must use the correct camera separation for the camera field of view. For animation this means that first you must put your viewer into the virtual space itself. If you are animating bugs then how tall is your viewer? Do you want it to feel like the person watching the film is 6 feet tall, looking at bugs on the ground? Or do you want to bring your viewer down to bug size, so his eyes (your cameras) are the same distance apart as the bugs eyes?
(…) The third rule for getting it right: set your cameras to converge on the most distant objects in view, and adjust your separation so that infinity is 2 inches apart at the screen, and let the foreground objects find their own place in that space. Resist the temptation to converge your cameras on the center of attention. If you really want to lock the viewers attention on one area, then use a depth of focus effect to blur the rest of the image, so the viewer will not be inclined to look around the area at other things.
(…) The fourth rule for getting it right: you must know the timing of the projection system. (…) But when objects move quickly there comes a point when your brain sees the left view in one place, and the right view in another place, but then the left view has moved considerably and your brain cannot pull them together. The result is you see two objects: the stereoscopic 3D effect is lost.
Nec is introducing the N704iµ, reportedly having a stereoscopic screen. I can’t find any more information than this picture, so if you come across something interesting, please leave a comment =)
From what has been revealed so far, “Larrabee” appears to be the codename for a so-called “many-core” [>8 cores] architecture that will include a variety of actual products and implementations. (…)
Larrabee parts will have ten or more in-order cores per die. Each of these cores (…) will support up to four simultaneous threads of execution.
So while Intel won’t publicly talk about any actual products that will arise from the project, it’s clear that a GPU aimed at real-time 3D rendering for games will be among the first public fruits of Larrabee, with non-graphics products following later.
Daniel Pohl (c) The Inquirer
Intel employee Daniel Pohl was on hand at last week’s IDF to give demonstrations of a version of Quake 4 that uses real-time ray tracing running on Intel hardware. Charlie at the Inquirer managed to catch the demo, and he published an account of it this morning that attempts to get at where the GPU is eventually headed as a product.
(…) there’s no doubt that Intel is serious about bringing this technology to real-time 3D games.
[But] because of the demands of the ray-tracing engine, Pohl had to swap out many of the game’s detailed textures in favor of reflective surfaces that exploit ray tracing, because there was no horsepower left over for texturing. It’s also the case that the demo required four quad-core machines ganged together, and even then it didn’t run at a playable framerate. So those reflective and refractive effects are nice, but they’re not worth that kind of horsepower requirement, especially when you compare the overall look of the resulting game to what single G80 can do with the right coding.
(…) ditching rasterization for some kind of pure ray-tracing approach is such a giant step backwards in terms of performance that when you factor in the fact that you’re forced to trade programmable shaders for a limited palette of flashy reflective/refractive effects, then sticking with rasterization is a no-brainer.
[Larrabee would seem to be] an ideal architecture on which to run a much more sensibly designed (higher quality, and faster) *hybrid* engine, that traces rays on-demand for secondary effects, while using Z-buffer, REYES, or similar pipelines for primary visibility.
So we won’t get realtime Renderman today :-/
Those two show a state of VR in 1993, with an impressive list of videos and applications. It would be really nice to have one such video now =)