 |
News |
 |
|
Chris and I finished a short 20 minute capture of virtual world interaction.
Chris has been working on this awesome video based on our capture and some of his experiences in the current virtual world scene.
Take a gander at this rough cut of the video (note Chris is still working on the painful job of texturing some of the buildings, so not everything is ready)
Check out towards the end: it has some of Alex's really powerful GUI interaction for editing model placement in world
Posted by: Daniel
|  |
| Meru virtual world |
November 2008 |
|
Back in January 2007, Pat and I started collaborating with Ewen Cheslack-Postava, Siddartha Chaudhuri and Vladlen Koltun to build the best possible open virtual world system from the ground up. Building an engine like this from the ground up is a project that dwarfs Vega Strike, but it certainly has been worth the challenge thus far.
Since then we've gathered more awesome folks onto the team like Professor Phil Levis, Alexandre Mattos and Michael Chung. We've also extended our collaboration to the creative folks at Princeton University with Mike Freedman
In August we finished the first version that looks pretty cool, and you can see an article on it at the Stanford engineering website.
We've already started a collaboration with Henrik on the SPEED limits project here at Stanford that aims to buld an interactive virtual art exhibit and more in a nonphysical, virtual setting.
Posted by: Daniel
|  |
| Exporting 3dsmax models into a virtual world |
March 2008 |
The big challenges in 3dsmax export remain as follows:
a) figuring out how to get multiple uv sets into 3dsmax...and then out of it
b) figuring out how to retrieve particle emitters so that artists can place smoke and fire.
c) parsing animation files to retrieve a list of ogre textures to animate
Then the biggest challenge in import is constructing a shader system of shader specializations that encompass all 3dsmax materials.
Looks like it's gonna be a *long* week ;-)
Posted by: Daniel
| Storing Resource for scripts and 3d geometry in a virtual world |
October 2007 |
Resource Management: We're striving to provide 3 layers of utility for the user.
The first layer is the immutable "it will always be here" layer. I like to think of it as a permanent mapping from a UID to data. I prefer a hash-based scheme since like-data will be stored by the same place in the filesystem, but Pat thinks this is a design detail that should be glossed over in the spec.
The second layer is the most meaningful layer to me: it's the layer where change can occur and is notified to the client. A client needs to know when a resource has been updated, so therefore having a layer where clients can listen for updates is quite useful. Right now the conventional wisdom is having some UID scheme for making unique "names" for something is sufficient. That way everything is nice and uniform under the hood instead of being as chaotic as a UTF-8 syntax for names and all the escaping that goes with that.
I'd prefer to keep human-readable names for the UIDs as well as more complex naming systems in the 3rd layer, which I call the "anything goes" layer.
Posted by: Daniel
| Open Source Raytracing on GPU's |
May 2007 |
At long last I've managed to post the source code of the lab's GPU and CELL raytracer at Sourceforge
I also managed to place my GPU Raytracing power point presentation that I will be giving to NVIDIA tomorrow at that site. Hopefully they find my analysis of ATI's hardware somewhat interesting.
As far as the raytracer goes, I wrote most of the the current working GPU code from scratch, and Jeremy and Tim did older versions of the GPU raytracer, the CPU raytracer and the raytracer that works on the CELL processor.
I'm hoping that at the very least our k-D tree builder is useful to other raytracing researchers, because I know it's impossible to benchmark properly without a decent k-D tree and at least a vectorized raytracer.
Posted by: Daniel
| Lightshop: Manipulating Light Fields in Real Time on a GPU |
February 2007 |
The paper I wrote on inserting light fields into games using the light shop system Billy Chen and I built was accepted to I3D! One of the main applications of this system is manipulating real life objects that take very little effort to capture.
We took a toy spaceship and inserted it into vegastrike with just a few minutes of setup time on the camera gantry we have.
I posted the Paper and Video for interested folks.
Posted by: Daniel
| I3d Paper on GPU k-D Tree Raytracing |
February 2007 |
| I submitted a paper about the raytracer I built as well as the new algorithms it utilized, known as "shortstack" and "pushdown".
The paper focuses on the performance analysis of these new algorithms and GPU raytracing in general. The conclusion is that even though the machine is running at 40-60% of efficiency due to the SIMD nature of the execution units, the raytracer can still get between 15 and 20 million rays per second on extremely complex scenes of hundreds of thousands of polygons.
This equates to interactive framerates on modern graphics hardware
I posted the Video and Final Paper in case anyone is interested.
|  |
Posted by: Daniel
| Raytracing on GPU's |
September 2006 |
So I've been working on raytracing using GPU's in the summer and it' turned out to be a great success on the ATI x1900XT. It may not be using the GPU to maximum efficiency, but it is a very competitive implementation compared with the state of the art, and it outperforms single and dual CPU implementations right now.
I put up a poster at the 2006 IEEE symposium on Interactive ray tracing.
The extended abstract can be obtained from here
Posted by: Daniel
| Lightfields in Vega Strike |
April 2006 |
Since I've been working with Billy Chen on light field stuff for a few months on the side, I decided to integrate them into the Vega Strike engine.
The result was a big success, and I plan to submit a paper to I3D or GDC at some point.
Here's the presentation I gave to my fellow glabbers.
Posted by: Daniel
| ClawHMMer on CELL |
April 2006 |
The folks from the Sequoia project have asked me to be a guinea pig and be the first user outside their inner circle to write a sequoia program: in this case HMMer. So I ported my HMMer code to the CELL processor using seqoia and it appears to be the fastest version of hmmsearch in the world right now!
Looks like they will include ClawHMMer results in their Supercomputing 2006 paper on Sequoia.
Posted by: Daniel
| Tree traversal on GPU |
March 2006 |
In the meanwhile I've been working on understanding the effects of collision detection and tree traversal on graphics hardware. While the memory system performs admirably, execution divergence really seems to be a big bottleneck. Many fragments all need to use the same instruction pointer, limiting the performance to the worst case in a group of tens of threads.
Similar problems may occur in my exploration of graphics hardware on other tree structures like kd-trees for raytracing or graphs.
Many of these datastructures exploit great locality on a CPU since each thread of execution stays in a very constrained portion of the tree, but on a GPU with each thread traversing a completely different part of the tree you really need a beefy memory system to even keep up. It's a good thing most GPU's come with one of those, but it's a bit of a shame they would need it.
Posted by: Daniel
| ClawHMMer at Supercomputing |
November 2005 |
I posted ClawHMMer at clawhmmer.sourceforge.net that has the source code and paper from the Supercomputing 2005 talk.
My talk from supercomputing seemed to go well because I finished a few minutes early and there were enough really good questions to fill my timeslot. I've never given a paper talk before, so it was a very interesting experience, if draining.
Posted by: Daniel
I just took my quals--boy that was a headache
I also submitted an article about ClawHMMer, a streaming protein matching algorithm that runs 10-30x faster than a pentium and 2-3x faster than a highly tuned AltiVec system on hmmsearch. The paper will hopefully be published at Supercomputing 2005
Posted by: Daniel
I published an article in GPU Gems 2 about adaptive subdivision, collision detection and other algorithms that utilize parallel scan and streaming compaction.
The basic idea of compaction is that each pixel scans the number of empty items to the left of it and shift itself over that much. This technique can be used to traverse trees, make adaptive algorithms and a host of other new algorithms.
Posted by: Daniel
| Brook compiler rev |
October 2004 |
Released another version of our Brook compiler to make general graphics computation on the GPU faster.
Hopefully it is well received; it has improved versions of my FFT, adaptive subdivision, collision, and volume rendering code in it, along with many other contributions by many folks on the Brook team
Posted by: Daniel
I released a project called the Raytrix. It explores the computability of beam tracing, and how difficult it is to accurately raytrace a scene. It is impossible to even know if your raytracer will finish tracing it due to the halting problem. The raytrix is a compiler from a program into a scene graph, that, when raytraced, will simulate that program.
Posted by: Daniel
| BabelShader Released |
October 2003 |
| I have released a preliminary version of Babelshader which can translate DirectX Ps 2.0 to ARB fragment ProgramThere is also an untested extension allowing translation of DirectX Ps 2.0 to Nvidia's fp30 fragment programs.Designed to convert between DirectX HLSL output, pixelshader 2.0 and OpenGL's low level shading languages
Allows OpenGL programs to use Microsoft's stand alone HLSL compiler, fxc.exe to compile programs into ARB or fp30 assembly.
|  |
Posted by: Daniel
| Webpage online |
October 2003 |
Hi this is Daniel; I work in Computer Graphics at Stanford University.
Posted by: Daniel
|
 |
|
 |
|
 |
Projects |
 |
|
