[Soc-2006-dev] SoC weekly reporting

[Brecht Van Lommel]

Hi Nicholas,

Great progress you're making here! But I have some questions
about the implementation.

Nicholas Bishop wrote:
> a) What I've done this week:
> Now that I've got a large amount of work done on the sculpting tools,
> I've been focusing on how I'm going to do the multiresolution
> modeling. I've created a small implementation that mostly works. (It
> works well going from a higher level to a lower level, but has some
> trouble going in the other direction.)

How are the displacement vectors computed? Relative to the global
frame, or some local frame? Do the higher resolutions follow correctly
when you scale or rotate the base mesh?

Also, for Catmull-Clark, you probably have to store the displacements
for all vertices at each level, since Catmull-Clark also moves the original
vertices. Butterfly subdivision schemes were invented to solve this, but
they have disadvantages as well and would just be too much effort.

> I don't yet have a wiki page up on it, but here are the highlights:
> * It's not a modifier. I spent several days learning about the
> modifier stack (those modifier stack wiki pages were helpful there,
> thanks Artificer) and I attempted to code a multiresolution modifier,
> and it worked well enough in terms of manipulating the data, but
> getting edit mode and sculptmode and any other mode to interact with
> it properly didn't seem possible, at least in the current modifier
> stack implementation.
> * My solution to this problem, which is hopefully acceptable, is to
> add a Multires pointer to the Mesh struct. I added a new button to the
> "Make" buttons in the Editing buttons (in the column with VertCol,
> TexFac, and Sticky.) So to use multiresolution, the user clicks on the
> Make button next to the Multires label. This initializes the Multires
> pointer in Mesh and pops a new panel in to the Editing buttons which
> has a button to add a new subdivision level, and a slider to switch
> between levels.

I'd really like to see a clear design doc on this, preferably not after
it is implemented. This is really something that should be reviewed
by others also.

For example, what about data attached to vertices or faces, like
shape keys, UVs, vertex colors and vertex groups. Is that preserved
when switching to a higher resolution? What happens when you edit
these at a higher resolution and then go back? Or similarly, what
happens when you edit the mesh, like removing vertices, and then
switch to a lower resolution?


Personally I think this should really be using the modifier stack,
because it solves some of the above issues, and basically allows for
nicer integration with the other tools. I think it is doable, if you only use
the modifier stack for display:

Editing in sculpt mode would not have modifiers enabled, which should
keep the implementation simpler. Modifiers would seriously hurt
performance anyway. So sculpt mode would edit this multires data stored
in Mesh, and make sure it's saved there once sculpt mode is exited.

Then the subsurf modifier could use that data as it subdivides to displace
the vertices. This would place some restrictions on the position of the
modifier in the stack, because the multires data would still need to be
available at that level. But with Ben's modifier recode that issue might be
solved also.

Making this work with 'simple subdivide' is easiest, but for Catmull-Clark
you'd also need to use the subsurf modifier in sculpt mode. But it would
only be used when switching resolution or exiting sculpt mode. A function
could be added to retrieve a DerivedMesh at a certain subsurf level. The
vertex coordinates from that DerivedMesh would then be used to compute
the displacement vectors or the higher resolution mesh. That won't be too
fast, but for switching resolution levels or exiting/entering sculpt mode
that's acceptable.


I hope that explanation was a bit understandable. :)

Cheers,
Brecht.