[Soc-2009-dev] Several things to get started

[Jingyuan Huang]

Hi all,
I'm quite slow in terms of writing. Here is what I have so far:
http://wiki.blender.org/index.php/User:Yukishiro/User_Specs_for_Light_Paint#User_creates_a_new_light_environment_for_a_static_scene.
I still need to polish many things, but ... I'm a slow writer...

theeth already did a quick review, and broken gave me some new ideas
on IRC. I started another page with all the concerns that would fall
in the design phase:
http://wiki.blender.org/index.php/User:Yukishiro/Design_Specs_for_Light_paint#Current_Concerns.
Eventually the design doc would go there.

Best Wishes
Jingyuan Huang
------------------------------------
Computer Graphics Lab
University of Waterloo




On Tue, Apr 21, 2009 at 6:45 AM, Ton Roosendaal <ton at blender.org> wrote:
> Hi Jing,
>
> Welcome to the gsoc program, I'm pleased to see so much enthusiasm! :)
> See some answers in text below.
>
>> 1. File save & load
>> I'd like to add a new property to Mesh called mcoeffs to store
>> harmonic spherical (SH) coefficients. Essentially it's an array of
>> float numbers whose size is determined by the degree of the function
>> (if the degree is L, then the array size is (L+1) * (L+1)).
>
> You don't mention where these coefficients apply to, I guess these
> values are per vertex? In that case I would first look into using the
> existing "Custom Data" for vertices. You can find the definition in
> DNA_customdata_types.h.
>
> You might define that degree values of 2, 3, 4 are all useful, in that
> case you best create three designated structs or layers for that.
> Something like;
>
> struct SHVertex2 {
>        float values[9];
> };
>
> struct SHVertex3 {
>        float values[16];
> };
>
> struct SHVertex4 {
>        float values[25];
> };
>
> The DNA system does support changes in array size, but these changes
> should be related to new internal data definitions, not to user level
> presets. If you allow a user to change this degree, the code should
> handle it by freeing the old coefficients (or convert) and allocate the
> new propert data blocks.
>
> Blender also supports read/write of 'raw' arrays, without size
> definitions. However, that I would really not recommend, especially not
> in this case.
>
> Further, you also have to define in this case how modifiers or
> 'derivedmesh' is handling this new custom data... how would you paint
> light on animated models?
>
>> There is also another parameter, number of random sample rays for the
>> unit sphere, that requires similar concerns. They are also a concern
>> for light node since light nodes has such coefficients as well, but I
>> haven't gotten that far. :P
>
> You can add your own variables in the Mesh struct for this.
>
>> 2. Button space, layout
>> There has been quite some changes recently in 2.5 in UI. :-)
>> So far I figured out that we are rendering buttons using python and
>> rna. The actual layout can be changed by modifying the python files
>> under .blender/ui. The idea is really neat, but ... how can I add a
>> new context? Now we have buttons in object and render context, but
>> nothing else. If I want to start something experimental in editing
>> context, where should I start?
>
> I would prefer to work with you first to review a good end-user level
> design specs of this feature, that will make answering the questions
> easier too. Implementation can follow design, it seems to me you run a
> bit too fast now. :)
>
>> 3. Render
>> I also have some concerns about drawing light paint mode. First of
>> all, rendering here requires more than what we have now for
>> vertex/texture paint. I would like to get rid of the grid and use the
>> light probe image as background.
>> view3d_main_area_draw is quite big already, so I'm not sure I should
>> spread code within it. I'm wondering if we can have a separate
>> subroutine for light paint mode (e.g. if v3d is in light paint mode,
>> the subroutine would handle all the drawing by itself and skip the
>> rest). Secondly, different shader (assuming that we are going to use
>> glsl) shall be used for rendering since the logic is not quite the
>> same.
>
> Blender 2.5 allows any 3d view to accept a custom callback for extra
> drawing. This callback is currently only in use for transform, but it
> was designed to work for your case as well;
>
> editors/include/ED_spac_api.c:
>        #define REGION_DRAW_PRE         1
>        #define REGION_DRAW_POST        0
>
> editors/space/spacetypes.c:
>        ED_region_draw_cb_draw()
>
> The 'pre' callback has not been inserted in code yet, but that's easy
> to add.
> Assuming you will make a 'mode' like VertexPaint or Sculpt now, you can
> for now just add the flag to the (still in use, but going to disappear)
> G.f. And tweak drawing code in the main view3d_main_area_draw() to skip
> some annoying extras. I'd be careful with this though, I don't like it
> much when 'we think for the user'. All such settings are already in
> user control too. Also that's a topic for the previously mentioned 'end
> user design doc' I'd like to review first. :)
>
> Laters,
>
> -Ton-
>
>>
>> Best Wishes
>> Jingyuan Huang
>> ------------------------------------
>> Computer Graphics Lab
>> University of Waterloo
>> _______________________________________________
>> Soc-2009-dev mailing list
>> Soc-2009-dev at blender.org
>> http://lists.blender.org/mailman/listinfo/soc-2009-dev
>>
>
> _______________________________________________
> Soc-2009-dev mailing list
> Soc-2009-dev at blender.org
> http://lists.blender.org/mailman/listinfo/soc-2009-dev
>