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

[Ton Roosendaal]

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
>