[Soc-2007-dev] Sunday meeting absence: topics for discussion

[Levi Schooley]

> From your message, I think there might be a
> little misunderstanding as to what constitute
> Transform and what does not (either that or I
> read your email wrong, that could happen).

Actually, I wasn't very clear on this point, so your assumptions
are justified. :) But...I also believe I have a fairly good grasp
of the Transform() "infrastructure" and its applications (you did
a great job putting it together, btw, I'm impressed). That is, in
fact, why I am asking these questions. The Transform() family of
functions are very, very close to what I need for both the bevel
and offset tools, and it would be nice to use them for consistency
and, possibly, reduced coding effort. It's just there are a couple
of things I'm having trouble fitting in, and I was wondering if I
should attempt to "force" it, if I could just create my own custom
Transform()-like event loop, or, if anyone else (like you) had any
better ideas.

> a) and b) shouldn't be problems, the generic
> transdata structure was made to be adaptable to
> wrap all kinds of data, there's really no reason
> it can be fitted to work with BMesh
> ...
> What do you mean by "new transform context"?

Yes, but the major problem is accessing the BMesh data. BMesh is
not yet an actual, recognized mesh or object type. It is
"scheduled" to replace editmesh, but until then, a mesh object in
editmode has editmesh data as far as the Transform() functions are
concerned. Since the Transform() functions grab the data from
global variables, the only options would be to a) perform the
editmesh-to-bmesh-and-back-again conversions from within
Transform() (during initialization?), or b) to point to the bmesh
data using another global variable, and to pass a new context
parameter to bypass the normal G.obedit and object-type checks.

> For tools that modify geometry (changing
> topology), that sort of thing is a given (the
> knife tool does it, edge cut does it, ...).

Ah! OK, that's what I needed to hear. I wasn't sure how well that
would be received since there is "already" a system for that
(Transform()), and with the event refactor looming on the horizen.

> However, some functionality used in transform
> can very well be reused elsewhere (I'm thinking
> especially of numerical input here, but the
> mouse input "conversion" functions could be
> reused too and probably others as well).

This sounds good. I hadn't researched using "pieces" from the
Transform() family. I had assumed they were all fairly tightly
coupled. I will see what I can come up with next week to
facilitate code sharing with a custom event loop.

> Transform functions shouldn't modify the
> topology. Actual geometry modification can happen
> before transform (extrude) or after (no example)
> or even both but not during,

I do realize this. So, why am I bringing it up? First, I'm
actually discussing two seperate tools: bevel (the main one) and
parallel offset (a supplement to the current ALT-S behavior).
Bevel modifies topology, but once the topology is modified, the
resulting geometry can be altered using per-vertex linear
transformations (an origin, a directional vector, a value, and a
scaling factor). The trouble comes with a) me wanting to allow the
user to interactively modify the topology, and with b) a major
design goal being to share code with a bevel modifier (not a big
difficulty as long as I'm strictly using BMesh; transform data
kind of messes up that).
The offset tool doesn't modify topology, but I was still planning
on using the BMesh API for the tool, and sharing code with a new
modifier.
Second, I wasn't sure how creating a Transform()-like event loop
outside of Transform() would be received.

Anyway, the major thing I needed to know was if it was OK to
create my own event loop for the bevel tool, and I think you gave
me the go-ahead on that. I'll be doing a bit more research this
next week about other options and possibly sharing code between
the two, and will inform you of my progress.

Thanks!
Levi