Distributed web-based raytracer - Tim L.
First off, a little bit of a primer. Ray tracers are programs that render 3d images or animations by simulating interactions between light rays. This method is the most physically correct and can simulate very complex things such as reflections, refractions, and shadows very elegantly. This is different from the method games and other realtime applications use to render 3d graphics because raytracers are very slow for complex scenes.
For an example raytracer, see PovRay.
Now, raytracers are very easy to get off the ground, and even if you guys don't know the math and/or physics, I've written a few and I can explain most of the concepts in about an hour. You can find hundreds upon hundreds of free raytracers out there, even ones in Java, so just making a raytracer would be very unoriginal. The biggest hurdle to any tracer is performance. It is not uncommon for a complex image to take an hour to trace. So, here's my project idea:
The idea is to utilize the networking capabilities and web-based nature of Java to create a distributed ray tracer, a tracer that uses many computers to speed up processing. We would make a ray "server" that users could set up with a scene to render, and then tracing "clients" could connect to the server and rendering individual chunks of a scene. The server would send scene data to each client, and the client would send back finished chunks of pixels. The server would then update all the connected clients with finished pieces of images so that each client would see the results of all the other clients as well.
The ultimate flashy demo would be using this distributed tracer for a realtime animation. Normally tracers are far too slow for animation, but if a distributed tracer had a lot of computers connected to it, for example, in one of the computer labs on campus, then we could approach realtime speeds. The server would then get the clients to render "future" frames in the animation and send back "current" images, in essence streaming the animation.
Further Idea: Collaborative Scene Definition - Carl
This is just something that I'm throwing out there, but what if we expanded upon the idea further. Can we come up with a creative way to allow simultaneously logged on users to collaboratively define scene, either before or even during the rendering process? This could be an added capability, so we could have a "normal" mode where a scene is defined somehow and then distributively rendered, or the collaborative mode could be used. Who knows what kind of behavior this would lead to? It would be somewhat analagous to a wiki in theory, but I'm sure that it would produce dramatically different results. Any kind of resulting image would likely be more surreal or just plain weird than a standard scene. Also, what would happen if two people defined their own scenes, and then these were somehow combined and raytraced together? If there was no single object looming in the foreground, can we come up with an algorithmic way to present both scenes, superimposed so that elements of both are visible? Sure this would sometimes appear as a jumbled mess, but it's possible some neat stuff could emerge from it. Again, just something to think about.
Better Further Idea: Context-Free Scene Definition Grammar - Carl
To get an idea for what I was talking about in class check out: http://www.ozonehouse.com/ContextFree/
Go here to see some pictures that people have made using this software: http://www.flickr.com/photos/tags/contextfree/
The interesting thing to do in the context of a raytracer would be to extend the same context-free approach to any scene definition language we would use. This would allow us to make similar images out of simple shapes repeated thousands or millions of times across all three dimensions.
Hypothetical Program Design - Carl
Well, seeing as though our project is required to go through three presentable iterations, and as though raytracers can basically be expanded up to infinite complexity (PovRay), we have plenty of opportunities to expand our software. It seems as though there is an obvious starting point for the program (the rendering core). Correct me if I'm wrong, because I've never written a raytracer before, but I think this core would be encompassed by a single primary function: drawPixel. This function simply determines the color for a single pixel. The reson it is done pixel by pixel is to allow for the distributed architecture to be added on. I think our first iteration should probably consist of only a local renderer, so we can focus on getting this function written correctly. At this point the program will also likely only render scenes that are perhaps hardcoded into the software. Sometime in iteration 2 or 3 we can add a scene description language, which will hopefully include context-free elements like I mentioned before. Iteration 2 will probably add the distributed capabilities.
Collaboration Ideas - Tim L.
Personally it seems that this project would be well suited to a group design followed by a division of labor for coding. I seem to be the only one who's implemented a raytracer before, so I could work on that while someone else handles the networking side of it (Zach?). Someone else can work on scene description and the context free stuff (Carl?), and the other person can handle the user interface (Tim P.?).
Distribution of labor, not design - Carl
We're obviously going to need to split up the coding amongst the four of us, but I think it's very important that the program is designed as a coherent whole, rather than having the four of us each coding independently then trying to mesh our stuff together. I've got some ideas for the SDL (scene description language), as well as for the networking/distribution and for the UI. I'm sure everyone else has plenty of ideas for these things as well. I propose that before we start coding we all get together in a room with one (or more) whiteboards and come up with a design that we can ensure will work when the disparate parts are integrated.
I agree. -Tim
Related Projects
Comments (0)
You don't have permission to comment on this page.