[Soc-2006-dev] SoC weekly reporting

[Brecht Van Lommel]

Hey,

Nicholas Bishop wrote:
> Hello Brecht, here are some answers to your questions:
> 
>> 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?
> Using local coordinates (Mesh.mvert.co). Moving, rotating, and scaling
> all work fine, both in and out of edit mode.

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.

> Dealing with the user adding or deleting vertices/edges/faces in edit
> mode is harder, and I don't have a good answer for that problem yet.
> One solution would simply be to "forbid" it: pop up an error message
> when the user attempts to do it.

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.

> This sounds like a lot of extra complexity without offering any
> advantages. By simply replacing the mesh data (Mesh.mvert, Mesh.mface,
> Mesh.medge) on switching to a multires level, almost everything that
> already works with meshes (sculpting, editmode tools, modifiers) will
> work without any modifications. No need to create extra data, convert
> to DerivedMesh, or any of the other necessary steps when working with
> modifiers.

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

Brecht.