[Bf-committers] Transform Refactoring

[Ton Roosendaal]

Hi,

>> I hope a drilling tool then can also use the full
>> power of transform,
>> which would be good.
>
> What do you mean by a drilling tool?

A flow like this:

- start drilling tool (mesh editmode); do some init stuff
   the selection becomes the CSG intersector with rest of edit-mesh
- call transform() for the selection
- result can be drawn like subsurf, with an extra displaylist, realtime  
CSG
- exit transform()
- exit drilling tool, convert to mesh or escape

So, within the transform() core, we already have a  
'special_trans_update'. That one is very static & chaotic... it could  
talked to in a more friendly way, maybe with a callback or so.

>> - You're warned Ipos and ActionChannels need to be
>> inserted somehow...
>> that's brain-crunch stuff to get right!
>
> Yes, I'm well warned.
> I'm not sure of something though (you can probably
> answer). Could that be done only as an after transform
> operation or does it have to be done on the fly as it
> is now?

On the fly, for the interactive keypos editing feature.

>> - As you might have noticed, the Object has a
>> quat[4] already, it was
>> scheduled to be used from some moment in the
>> future... with old eulers
>> only optional, or even completely converted.
>
> That's mainly useful for rotation though isn't it?

It's *only* useful for rotation. :)
Quaternions are mathematically much more stable to work with,  
especially for conversions to and from matrices.

>> - What I really miss is the target & result of this
>> work... what is the aim?
>
> Semester seems to start slowly despite mainly heavy
> courses, so I should have time to start laying out the
> ground work (conversion and pre transform, numerical
> handling and probably tackle one of the easy
> transformation (scale or grab)) in the next week.
>
> Could be totally ready for the conference, but that
> depends entirely on school workload.

Hehe!
I didn't mean scheduling, I mean functional targets to illustrate &  
market your work! :)

Targets could be like:

- put blender transform() tools in separate C file, with documented API
- restructure the long code into manageable & understandable  
chunks/functions
- enable transform() functionality for other tools too, like 3d  
transform-widgets, python, etc. This by eliminating the sub-loops and  
make it an 'event handle'
- provide access to transforms based on vertex-normals, face-normals  
(for extrusions for example)

For large code restructure projects it works well to not only have  
technical targets (getting code back in control) but also clearly  
define targets that exceed the current functional level and shows that  
the new code will be future proof for exciting development.

Or in other words; what's in it for our poor users! :)

-Ton-


------------------------------------------------------------------------ 
--
Ton Roosendaal  Blender Foundation ton at blender.org  
http://www.blender.org