> Do we have some jobs for parallelization? There has to be, but I could not > find any in the Ideas list. It would be really helpful if you could suggest > some according to my interests.
Of course there are. That's basic optimization infrastructure that could be applied to just about any area or BRL-CAD. A couple ideas that immediately come to mind would be to implement an OpenCL-based ray-bundle shotline intersection routine for our LIBRT raytracing library. Traditionally, you shoot one ray and compare it against all geometry along that path and then move on to the next ray. With OpenCL, you'd want to shoot a grid of rays (like 32x32) and evaluate batches of them at a time before moving on to the next batch. That helps keep memory usage coherent. As this has to be support implemented for each primitive type independently, a good GSoC proposal might involve just implementing support for our ellipsoid primitive. > Yes I am used to Qt but not with engines like OGRE. I definitely need to look > into the display manager more to get accustomed with its complexity and will > get back to you soon. In "The 2D sketch editor" extending the library of > Archer seems interesting due to my good familiarity with various curves. What > I am afraid here is of my expertise in tcl/tk, can you please elaborate on > its proficiency requirements? Our display manager code is not the prettiest but it's a pretty simple callback-based API. You can see an example in src/libdm/dm-Null.c that does nothing but has all of the callbacks defined. The 2D sketch editor library I referred to is actually implemented in C++ (see src/other/clipper) so you'd only be having to worry about a few bindings in C and Tcl. As a language, Tcl is quirky but usually very simple to learn. That said, you'd probably be able to do most of your work in C/C++ given the main binding is in src/libged/clip.c > Meanwhile I am leaning more towards implementing a "Spacial partitioning API" > due to my foundation in C, computer graphics and data structures. Here I need > to know more about the generality as it would greatly affect the overall > design of all the partitioning schemes. And which all schemes are expected? > BSPs, Octrees, Kd-trees..a 3D voxel grid. Given the utter complexity of this topic, it would beg for a substantial patch that demonstrates familiarity with BRL-CAD's existing spatial partitioning code (src/librt/shoot.c and src/librt/cut.c) like fixing some bug or refactoring something existing into something better. That's not an easy task, to say the least. An API isn't very useful unless it's hooked in, so the project would probably need to focus around refactoring and *encapsulating* the existing two spatial partitioning implementations we have into that API, not writing yet another from scratch. That is, moving a lot of code around and renaming functions while making absolutely sure that everything still works as it did before you started. Keep the questions/comments coming, everyone. Good stuff. Your chances of acceptance are as high as your ability to communicate and interact. We're hoping to accept a lot of students this year but not if we don't know who you are. ;) Cheers! Sean ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ BRL-CAD Developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/brlcad-devel
