[Bf-committers] Transform Refactoring

[Martin Poirier]

--- Ton Roosendaal <ton at blender.org> wrote:

> Hi,
> 
> A couple of notes;
> 
> - I miss the 'flow split'; where transform can
> become handler by making  
> an initialize(), doit() and exit() stage.

I had that in my personal papers, just didn't write it
in the wiki yet.

> And how an API for this would like?

The API could be plugged in in several places:

- As a new transformation

- As different constraining modes

- Linked to key events


> - Generic 'type independance' sounds good, but
> nevertheless you'll find  
> that some types just need complete different
> handling. Like vertices  
> vs. objects, or armature bones.

> And will we use this
> for single-value  
> editing like weights, path-twisting, etc?

Yes and no.

Yes, it could use the same numerical typing, mouse
handling and other independant reusable parts, but
they don't really fit in the general data structure
(although the related parts could be skiped altogether
if a certain flag is raised. Since the actual
transformation itself happens in a different function
for each transformation, the specials cases would be
handled apart from the rest in a clean way). This
would also include the warp function which is a very
special (and weird) case. 

Also, these don't fit in my "transform chaining" idea.
(Soon to be more explicitly describe in the wiki)

> - My previous remark on 'abusing transform()' was
> serious... but what I  
> meant is transform() can become that good that we
> don't have to abuse  
> anymore. :)

Yup. If it is compartimentized enough, all the
"abusing" will be limited to their own little sandbox
without creating the current horror of special cases.

> 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?

> - 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?

> - yes you'll need the old values in the struct, it's
> better not to do  
> any incremental stuff, but always transform from
> fixed start (=old)  
> values

True that, especially when switching constraints.
Something I had overlooked.

> - The MMB workflow suggestion; I'd like to see
> that... current MMB  
> trick works based on largest motion, not closest
> axis. But it might work!

Loq Airou kinda works like that for translation
constraint (closest axis I mean).

I'm pretty sure it will have a limited impact on
workflow, since most of the time, closest axis would
be the same as longest motion.

> - Quote: "Transformation is always done on the
> matrix and then  
> transfered back"? That's very dangerous... I still
> have to see the  
> first reliable routine to extract size/rot/loc
> values on a compatible &  
> predictable level. Here especially ipo key inserting
> makes it hard.

Totally agreed. When writting that, I mainly thought
of translation transformation. I've taken it out of
the wiki, it will belong in the per transformation
specific section when that is done.

> - 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?

> - 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.

Martin


		
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com