Hello! My name is Brent Davis. I'm currently a sophomore at Coe College (Iowa, USA) majoring in CS with a minor in mathematics. I have taken a few relevant courses (eg, computer graphics with a focus on OpenGL) but most of my programming experience comes from outside of classes. I have been spending the last few weekends putting together a game - my goal is to make it available for purchase somewhere, perhaps Desura; if that works out it will be my first "published" project. I'll post a link to what's been done so far here, as a sort of example of my coding and organization style. It's still in very early stages (college is keeping me awfully busy at the moment!) but I feel that what *is* there is fairly solid, albeit short on comments.
http://dl.dropbox.com/u/17635193/RisingWater.zip It's a NetBeans IDE C++ project, bear with me :P; req'd libs include GLEW, SDL, boost_filesystem, lua5.1, and DevIL (I know, I'm using something other than oiio... I hadn't heard of oiio before I started looking at the GSoC list of organizations, so that's my excuse :) ). Other than that, I've created a small program that displays and applies effects to .nif (3d model format) files, and got some experience with multithreaded programming (Boost::Thread) last summer doing mathematics research on-campus. -- I've made a small commit on my fork of oiio as part of the requirements for application. You can view it here: https://github.com/btdavis/oiio/commit/23f6f623d16181eff2604bf17953526fa597d61b -- As for project ideas, I'm definitely interested in working with iv. I'm hoping some of my experiences with interactive programs will be applicable. I tested a few large images (approx 10000x7000 pixels) with iv and it struggled to display them when zoomed out - thus, one idea for a project: to improve support for large images. Increasing the number of GL textures from 4 to 16 (evidently, enough to store the entire image) brought performance right where it usually is with smaller images, and letting the GL drivers decide which textures need to be resident is a nice option, but it is difficult to determine how many textures the system can handle (aside from video memory, we'd need to know available system memory, swap space, etc, not to mention differences in implementation between drivers). Using mipmaps would be another good way to minimize the amount of data that needs to be stored, transformed - ie, from one pixel format to another - and sent to OpenGL. It seems (correct me if I'm wrong) this functionality is already in the ImageCache, and the option is available in the iv preferences, but I saw nothing to suggest that it was actually being used while creating and loading textures. What I have in mind is to generate (or load, with appropriate file formats) mipmaps with oiio, and load those as top-level textures, so as to avoid having to pass around hundreds of MB of texture data. Assuming the texture tile size is as big as the window, it shouldn't ever be necessary to use more than 4 textures at a time with prudent use of mipmaps -- this would definitely benefit large images. Reorganizing the code to work around disk i/o more effectively sounds good as well. I'm thinking a threaded approach would work here - one thread reads from disk while the main thread makes requests for future images (I haven't dug too far into the actual image cache/loading code so I don't know if this sort of thing is already implemented somewhere or not). The main thread would do something like "Confirm images are loaded"->"Send images to PBOs"->"Request next set of images"->"Render". This will probably find some good use with respect to the video playback features as well (as would the mipmaps). As a side note, I'd be interested in working with the video playback, should that opportunity be available. I don't have much experience with qt unfortunately but I'd love chipping away at the back end, with the timing and such. Hopefully I've managed to make sense of my ideas :). Looking forward to your feedback, Brent Davis
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
