Hi Everyone: I just want to add a comment to Jorrit's request. We don't gauge your proposal based on what you initially turn in - we utilize the individual stages of the proposal to help you refine your idea, not critique whether or not you're a good candidate for the summer of code. We only evaluate proposals to see which ones we will accept at the very end, when all of the mentors have had a chance to read all of the proposals and comment on them, in order to help the student solidify the idea they want to get across. So, don't be ashamed to submit a proposal that you think is not representative of what you will turn in at the end.
~Scott Thus Spoke Jorrit Tyberghein: > At first glance looks good but I will look into it more later. Just a > warning. Please > submit your proposal to the GSoC site. Apparently the people at GSoC want > to have a clear idea of how many proposals there will be right now. > You can always > edit your proposal afterwards if there are problems. > > Greetings, > > On Wed, Apr 1, 2009 at 2:14 AM, Jan Lamecki <[email protected]> wrote: > >> About Myself: >> Vacation plans: >> * I am planing to do some work at my university (I have to >> hand >> 'work experience' paperwork this year) - about 12h/week >> * One or two rock festivals - Friday-Monday. >> * One-two week holidays in the mountains - after SoC :) >> Programing projects I have done so far: >> * Imposters (this is reason I feel I may be right person to >> do this :) ) >> with friend, >> C++, OpenGL, with static lighting, rendered with FBO >> and on >> BackBuffer, included export plugin for Blender. >> * OpenGL puzzles >> C++, pieces had bezier edges (smooth), randomized >> pieces, >> triangulated using GLUT and rendered in 3d. >> * Many microprocessor projects (that's my hobby), for example: >> * simple line following robot >> * industrial sensor for tobacco company project >> (winner of company's contest, now in >> implementation stage; my part done) >> * ultrasound distance meter >> * Some web apps: >> * Web chat - with very low latency and connection rate >> Apache Tomcat (Java) + GWT (Java) >> * Route planning using city public transport >> http://findtheway.pl/ >> Python (preprocessing), C++ (server), >> GWT(Java)/JavaScript (client) >> * Many small programs in python/c/c++ (my favorite >> languages), for example: >> * last.fm recorder (python) >> * VHDL device simulator (useful on one of classes I >> attended) >> (c/vhdl/python) >> * Many more ;) >> >> What OS projects I worked on? >> * Patch for perl last.fm ripper (I do not remember name) >> accepted by gentoo, no reply from author. >> * I have written Linux driver for my laptop's IrDA, and have >> sent it >> on irda-users (I have got only three e-mails regarding it, >> so I guess >> nobody uses IrDA nowadays) >> >> Other projects I am applying to for GSoC: >> none >> >> Experience with C++ or Python: >> I am experienced C++ and Python programmer - see project list. >> >> My experience with computer graphics: >> I have written many programs using OpenGL, fragment and >> geometry shaders too. >> I used DirectX last time when newest version was 7 - played a >> lot with >> Direct3D RM (higher level) and IM (lower level) graphics, >> DirectDraw and >> DirectShow (had to write own software for tv card); after >> that I did >> not write many (if any) programs for windows. >> I from ready made engines I only used (very little) blender >> game engine. >> >> >> Crystal Space questions: >> When did I first hear about CS? >> About year ago, did not investigate - I was just looking at >> Open >> Source 3d engines. >> >> Have I worked with CS before? >> No. >> >> My project: >> I would like to implement imposters for CS. >> >> That would include getting basic rendering to work (removing '#if 0' >> in 1.2 >> csMeshFactoryWrapper::SetImposterActive did not make it 'just work >> TM'). >> I was told by res it is not working in 1.4 either. >> >> After that I would develop a measure useful in assessing imposter's >> accuracy. >> I would like to include factors such as: >> * time after rendering/TTL >> life saver - all errors would eventually be fixed by >> rerendering ;) >> * change of view (basic when just 'viewing scene') >> * global parameters change (lighting etc) >> * material change >> * shadows - that I would touch last >> (I would have to get familiar with shadows in CS >> first) >> >> Also important issue is limiting texture memory use - this can be >> achieved >> by putting limit on imposter textures (in allocation). >> Imposters can be invalidated and their texture fragments reclaimed: >> * Time To Live based reclaim - too old (by some engine 'time') >> imposters are considered unusable and freed >> * Damage - some events cause imposters to get a bit 'off' >> (eg lighting change), some cumulative measure should be >> implemented in order to invalidate imposters. >> >> Imposters would be per-object-instance basis created - that is for one >> imposter set for each object occurrence in scene. When rendering from >> given view closest imposter would be found (possibly using kd-tree by >> spatial "nearest to" query) and used. >> >> Imposter set here is structure bound to object allowing to find >> imposter >> for given view easily. >> >> Allocating imposters would be done by using blocks of textures - >> rectangular >> fragments of textures thus optimizing texture switches in rendering >> phase >> (target switches were very costly when I have implemented it). >> If it did not break CS layering I would like to try using extensions >> such as >> NV_fence to get more parallelism on GPU. >> >> Imposters would be rendered using object-space coordinates computed >> during >> prerendering phase. >> Rendering problems: >> * Edges: >> * use GL_NEAREST and 1-bit transparency >> or >> * use alpha transparency >> requires separate blending functions >> for color and alpha >> * Objects which screen-space BBox-es intersect can be in >> strange >> relationships for example at some given screen point there >> could >> be A-B-A combination of objects -this can not be rendered >> correctly >> without using Z-buffer >> * ignore such problems - should not be noticeable with >> small imposters (this is the case here I believe) >> or more correct but slower >> * render imposters with Z-buffer values and use them >> during >> rendering (requires fragment shader) and/or check >> for >> intersecting BBox-es and avoid imposters in such >> situations >> >> My proposed rendering phase is as follows: >> * normal rendering, memorizing candidates for imposters >> * prerendering phase (time limited in order to keep FPS high) >> * imposters are assigned texture fragments and sorted >> by used texture >> * for each imposter texture >> * Zbuffer (and other used) is cleared >> * imposters are rendered (cleaning their imp >> texture fragments) >> * blocking till operation finishes or pushing >> fence (NV_fence) >> * normal rendering, using previously rendered imposters where >> applicable >> * if fences are in use there is need to wait on given >> imposter's fence >> before rendering imposter. >> >> Deliverables: >> * working imposters (to make 'apricot' people happy :) ) >> * documentation describing inner workings of imposters >> This point is quite important because imposters still are not so >> widely >> understood. Leaving documents allowing other people to comprehend >> and >> improve code is very important in Open Source projects. >> * doxygen public api documentation - allowing to just use imposters >> without >> getting too deep into code. It is also essential to highlight >> pitfalls and >> implementation limitations (if any ;) ) >> >> Schedule: >> GSoC: May 23 - start of 'implementation phase' >> >> Jun 15 - working imposter allocation, rendering, TTL reclaim >> Includes writing test app for it or adapting imptest >> >> Jul 6 - imposters-set implemented >> Basic structure storing information about given object's >> imposters >> and their state. Separated in order to underline importance >> of having >> it early designed and implemented - all following code works >> mostly >> by modifying it. >> >> Jul 20 - attached 'damage' properties >> This goal allows to quantify changes in scene. >> Separate goal because there are many places I have to find >> and somehow >> attach to imposters. >> Also sending damage to imposters have to be done carefully - >> we do >> not want to visit all imposters on any lighting change. >> >> Aug 1 - Reclaiming damaged imposters, documentation of internals >> Internals are finalized now - should be documented in order >> to give >> other programmers easier way in to the beautiful world of >> imposters. >> >> Aug 7 - End user documentation, code documentation and cleaned up >> code. >> End user documentation consist mainly of some common use >> cases and >> pitfalls, API is to be documented too. >> >> Why I believe I am right person to do this? >> I have written with friend quite simple imposter engine before: >> * I was designing it and wrote math, rendering on backbuffer, >> imposter rendering math, imposter texture allocator, >> imposter accuracy measure and kd-tree based best imposter >> choice (based only on viewing direction - worked pretty >> well ;) ) >> blender scene export plugin >> * Friend wrote import and FBO/RenderToTexture support and had >> very >> interesting idea of combining per-pixel-lighting and >> imposters - >> unfortunately difficult to implement, so we did not do it. >> I am also discarding this idea here because of it's level of >> complication and required additional processing. >> source code: >> svn: http://jachor.ath.cx/svn/gkiw/trunk/krata/ >> user: guest >> pass: guest >> documentation - polish, sorry: >> http://jachor.ath.cx/krata-docs/ >> screenshot: >> http://jachor.ath.cx/krata-screen.png >> Black spot in the middle is due to 'execute command' >> window. >> These trees are substituted by imposters - tree with >> red rectangle means imposter. >> Due to way the tree model was created imposters differ >> from real objects - I have left somewhere >> transparency in model. >> I have got experience in all involved fields. >> I am familiar with algorithms (I take part in many algorithm >> contests, esp ACM-style) >> and willing to use them! (to keep rendering time low) >> >> ----- >> Every input greatly appreciated - please ask if I made something unclear. >> Thanks for res for initial coments! >> >> ------------------------------------ >> Jan Lamecki >> student of Poznan University of Technology, CS, 3rd year >> location: Poznan, Poland >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Crystal-main mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/crystal-main >> Unsubscribe: >> mailto:[email protected]?subject=unsubscribe >> >> > > > > ------------------------------------------------------------------------------ _______________________________________________ Crystal-main mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/crystal-main Unsubscribe: mailto:[email protected]?subject=unsubscribe
