[Soc-2006-dev] SoC weekly reporting

[Nicholas Bishop]

> The problematic situation I'm thinking of is this:
> - sculpt detail in higher resolution
> - go to base mesh
> - rotate the base mesh 180°
> - go to higher resolution again
>
> Now, if the displacement vectors aren't rotated along,  then the higher
> resolution will have displacements in the wrong directions.
You're right, rotation doesn't behave correctly. It works fine going
from a higher level to a lower level, because then vertices are simply
copied, but going in the other direction, the mesh gets squashed. I'll
look into this some more.

> This could result in the user switching a lot between multires levels.
> Typically the user will want to see more detail than the base mesh while
> editing. So when they want to do a boolean op, do some weight painting,
> add a material, etc, they would have to switch back to the base mesh, do
> the operation, and then switch to a higher resolution again.
>
> Of course it would be possible to work around these limitations, by
> mapping the data back to the base mesh and such, but this is the type of
> thing that the modifier stack is already solving, and it's sufficiently
> complex that we wouldn't want to maintain two solutions to the problem.
Pretty much any type of topological operation (booleans,
adding/deleting elements in edit mode, etc) is going to require some
complicated code to transfer the topological changes up and down the
multires chain. I'm sure it's possible, but I haven't given it a lot
of thought -- multires doesn't need to deal with topological issues
(except for subdivision, of course) in order to be useful. For
non-topological operations, like weight painting, materials, etc.,
they can all be done without switching levels, and unlike what happens
when you paint on a subsurf mesh, _all_ the vertices of the model will
be accessible to the tool, not just the ones in the original base
mesh.

It's important to remember that with multires, the base mesh isn't
anything special or different from the other levels. Once multires is
applied to the mesh, which happens only when switching levels, all
tools can treat it as a normal mesh, and multires handles the rest.

> With the current design, multires would effectively replace the subsurf
> modifier. There's only so many subdivision levels a computer can handle,
> and users will use them all up. By itself that is not a bad thing, except
> that important functionality would be lost, or would need to be implemented
> again. The latter resulting in duplicate and harder to maintain code. I'm
> thinking particularly of:
>
> - Editing the base mesh in edit mode in with vertices on the final subsurfed
>    mesh, with quick incremental subsurf updates.
> - Weight, vertex painting and UV editing on the final subsurfed mesh, with
>    data mapped back to the base mesh.
> - Different subdivision levels for display and render.
> - Creases and Subsurf UV.
> - Keeping vertex group, vertex colors and other data.
> - Applying modifiers in arbitrary order (once Ben is done), like first armature
>    deform and then subdivision. That's the current order, and doing the other
>    way around would break the weight painting in existing rigs, and lose the
>    smoothing out effect that subsurf has (think a tail rig for example).
As I mentioned above, the behavior that multires should have in many
of these situations is very different from that of subsurf. Subsurf is
purely a display modification, whereas multires meshes have to make
all the new points/edges/faces editable.

> But, outside of sculpt mode, the user may want  to pose or animate
> the mesh, and you have now a problem, because the mesh is
> now so heavy you cant easily deform or edit it.
Multires is perfect for this -- you just switch to a low-res level,
then switch to a high-res level for rendering. (I plan to add a second
level slider, much like the subsurf modifier, that will automatically
choose the high-res level at render time.)

> So, if you do it outside of the stack, you need a way to feed back the
> results to the stack, for other operations.
The mesh is already fed back to the stack. Multires applies changes
directly to the mesh object. It has no problem with other modifiers
applied to it, including Subsurf and Armature.

>
> that can be a command to convert a given level of mrm to normal
> subsurf modifier (but you must be sure you use same subdiv
>  algorithm) or a placeholder modifier to take the result. i would
>  probably favor convert but if you implement not equivalent
> subdiv, you'll need the latter
Converting to a regular subsurf mesh doesn't make much sense because
multires adds new details at higher levels.

> the important point is to not  have to deal with the full derived mesh
> in edit mode, but only the base one.
Multires works fine in edit mode, so long as the user doesn't add or
delete vertices or faces. It's true that edit mesh is slower than
sculpt mode, so it helps to set the multires controls to one of the
low-res levels, but it isn't required. Having multires available in
edit mode is quite useful, we don't want to disable that.

At this point, I really think it will help us all out for you to see
the implementation I've been experimenting with. I'll commit it to my
CVS branch, and we can easily revert it later if we want to. (I'd
prefer to create a patch instead, but I can't figure out how to get
the cvs command to include new files in the patch.)

-Nicholas