[Soc-2006-dev] SoC weekly reporting

[Nicholas Bishop]

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.

> 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.
Yes, that's true. Unfortunately, it may be necessary to use on of
these more complicated subdivision schemes. (See my latest weekly
report for why.)

> 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.
I've got a wiki page up now:
http://mediawiki.blender.org/index.php/BlenderDev/Multires
Experimentation is key right now; I doubt this project can be worked
out entirely "on paper" without doing any code.

> 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?
For now, only location and topology data is stored. (No point dealing
with extra data until the subdivision algorithm is nailed down.) Once
it's ready, I don't see adding the extra data as a large problem;
interpolating UVs and similar data shouldn't be any more complicated
than doing it for vertices.

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.

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

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.

-Nicholas