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 > -- Project Manager of Crystal Space (http://www.crystalspace3d.org) and CEL (http://cel.crystalspace3d.org) Support Crystal Space. Donate at https://sourceforge.net/donate/index.php?group_id=649 Personal page: http://users.telenet.be/jorritTyberghein/ ------------------------------------------------------------------------------ _______________________________________________ Crystal-main mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/crystal-main Unsubscribe: mailto:[email protected]?subject=unsubscribe
