10:11 
Virtual Reality
VirTra Systems, Inc. (OTC Bulletin Board: VTSI) today announced the sale of a specially modified IVR(TM) simulator to Case Western Reserve University in Cleveland, Ohio.
10:41 3d
(source 3dvf) From the threed.com forum :
“Meet Eva Byte, a TV presenter that has went on air every week on Brazil’s TV Globo network - every week for the past 20 months.”
There are 3 videos to download to get an idea.. The head is really cool, but the body’s animation is not credible yet.
13:42 Game development
Sum up of this article at Gamasutra :
The convergence of film and game production has been predicted for years, but progress has been slow…
(..) In 2003, developers at Lucas Arts and Industrial Light + Magic began an active but informal effort to share techniques and code. The collaboration gathered steam as the Lucas companies consolidated and then relocated as neighbors in a new facility in the Presidio in 2005. Developers are now “right down the hall” from each other, developing on the same code base, staffing projects with crew from both divisions, and tackling problems with the best techniques either side has to offer. It’s not just about sharing assets… we’re building a unified set of technology to produce both movies and games, and give both companies unique competitive advantages.
(..) ILM has been using LucasArts’ game expertise to develop “pre-viz” sketches for its effects sequences. (..) The idea in Lucasworld is that the game division uses its tools to prototype the movie, and then ILM hands over its more sophisticated models, animation data, effects, and technology over to the game division when it’s done.
(..) the most important element in anything we’ve seen is proximity. Without the physical contact between the two branches, none of this communication would be as feasible as it is for them now.
– That’s one step, let’s converge =)
15:30 OpenGL
Damn, look at the Unreal Tournament 2007 screenshots !!!
The Unreal Engine looks really beautiful I can’t wait to test it =)
10:59 Virtual Reality
The eMagin Z800 3DVisor is stereoscopic (SVGA OLED) and headtracked 3DOF (yaw, pitch, roll, no position data). A user on the osg mailing list finds it of “Gamer grade more than VR-grade”. “Likewise, it’s only $800 or so, so you get what you pay for. ;)”
11:41 3d
11:17 Tech
Interesting talk on the sweng mailling list (Software Engineering, as it applies to Game Development) about code review.
Alen Ladavac wrote:
If it is not, the reviewer will (somehow) notify the programmer on what he needs to fix in there.
Rinse and repeat.
From: Noel Llopis
I’ve tried both approaches and neither one worked at all. As you said, the
process would quickly be abandoned and would have to be restarted. The
fundamental problem we ran up against was the attitude of “well, it’s
working”. So thinking of re-writing something or making major changes to it
was a no-no.
On the other hand, for the last year at work I’ve been doing what I think is
the most effective form of code reviews: pair programming. The code that is
written is analyzed and questioned by two people as it happens. Discussions
start at the earliest possible time and things get corrected before they’re
too late.
Pair programming is also a great tool to spread knowledge, a set of coding
standards, and common best practices just by rotating pairs frequently. One
of these days I’m going to write about our experiences so far on my web
site.
From: John Butler:
One thing I personally never liked about code reviews is that they
are after the fact. It was always frustrating for both parties
involved when a developer would write a section of code that would
have to be re-worked (especially since the developer already spent
the time and energy writing it).
I’ve always preferred prevention over “cures”. So at the last company
I worked for I implemented a code-buddy system. Whenever a new
problem is tackled ( a new system is designed, feature added, bug
fixed, etc ) the developer finds another developer to be a “code
buddy”. Before writing code the developer explains their solution to
the code buddy. These are usually quick and informal, but sometimes
can last for an hour or more ( a really good sign, in my mind, that
the code buddy system just saved days of work in the future ).
After the code is written, the developer gets with the SAME code
buddy and does a code review. These go much quicker and are much more
effective because the code buddy is already familiar with the problem
and the solution. In that sense it’s more of a postmortem than a
review ( did the proposed solution work? what didn’t work? ).
For my team I didn’t restrict code buddies to fall within the
developer hierarchy. Senior developers could use a junior developer
as a code buddy, two developers at the same level could help each
other, etc. Just the act of explaining a solution out loud to someone
else was often enough for developers to find holes in their strategies.
Did we do it every time for every task? No. But every time we did use
the code buddy system both parties felt it was an effective and
meaningful use of their time.
P.S. I agree with the earlier comment about pair programming.
Sometimes the code buddy system would lead to a pair programming
situation, which, if the chemistry was right, worked out to be uber-
productive.
There are more solutions and examples of use on the list, go read them 
10:36 Tech
This site is better viewed with :
