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

[Martin Poirier]

--- Levi Schooley <levischooley at eaglecom.net> wrote:

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

I'd prefer not "forcing" things in if possible, but
I'm all for code reuse.

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

I think b) would be preferable at this point. Adding a
new Transform Context flag, check for that flag before
conversion and use the BMesh structure if present
(doesn't need to be in a global var, as long as it's
accessible.)

If you need to flush updates to BMesh or whatever,
something can be done for that too (like what Brecht
added to support UV transforms).

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

Some of them are tightly coupled yes, but some could
be uncoupled if wanted. Once you figure out what you'd
need in a custom event loop, we can work out what can
be reused/adapted from Transform.

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

I wasn't sure you did, just wanted to make sure it was
all clear.

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

Now, this is right off the top of my head, but can't
it be done line this:
1- Bevel tool changes topology
2- Transform is used by the users to set the bevel
offset.

Step 2 could be done by setting the vertex normal
direction and length to fit the bevel offset's
direction and factor (since not all corner is
offsetted by the same factor, to keep a constant
distance from all sides of the poly). Then, the
transform function can just move vertex by a constant
multiplier of their normals (stored in the axis
matrix, like what is done for Shrink/Fatten).


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

By parallel offset, you mean moving the faces to keep
them parallel to their original positions, right?
(sort of like what the bevel tool would do for edges)

This could be done using the same trick, setup the
normals (using BMesh) and call Transform.

> Second, I wasn't sure how creating a
> Transform()-like event loop
> outside of Transform() would be received.

It's all good if it's clean code. If you part of the
loop can be reused later for other BMesh tools that
might need it, all the better.

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

Yes, consider the go-ahead given. :)

> 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. Anything I can help with, don't be afraid to
ask.

Martin


 
____________________________________________________________________________________
The fish are biting. 
Get more visitors on your site using Yahoo! Search Marketing.
http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php