Enabled by default and also enabled for older filesm so
there should be no regressions.
In some cases it's useful to not use subdivided uvs for multires.
Removed the DerivedMesh face iterators (they sucked).
This should make subsurf faster. Also sped up multires
a bit (not sure if it's strictly correct, need to look
at it later).
=======================
Added option to baked named "Bake From Multires" which is avaliable for
normals baking and displacement baking.
If this option is enabled, then no additional hi-res meshes and render
structures would be created . This saves plenty of memory and meshes
with millions of faces could be successfully baked in few minutes.
Baking happens from highest level against viewport subdivision level,
so workflow is following:
- Set viewport level to level at which texture would be applied
during final rendering.
- Choose Displacement/Normals baking.
- Enable "Bake From Multires" option.
- You're ready to bake.
Displacement baker had aditional option named "Low Resolution Mesh".
This option is used to set if you want texture for realtime (games)
usage.
Internally it does the following:
- If it's disabled, displacement is calculated from subdivided
viewport level, so texture looks "smooth" (it's how default
baked works).
- If it's enabled, dispalcement is calculated against unsubdivided
viewport levels. This leads to "scales". This isn;t useful for
offline renders much, but very useful for creating game textures.
Special thanks to Morten Mikkelsen (aka sparky) for all mathematics
and other work he've done fr this patch!
Face's totdisp was set to correct value, but memory hasn't been
allocated for disps. Handle this in multires_topology_changed(),
so the whole MDISPS layer wouldn't be totally re-allocated when
applying displacement.
Multires interpolation is now nearly perfect, but has some
issues on faces whose angle to each other isn't relatively
shallow (probably need to use some sort of fast spatial structure
to more accurately project multires points).
It also doesn't work super well with bevel (mostly due to a
flipped normals bug in bevel I need to get around to fixing).
And, for some reason extrude tends to explode the multires
geometry (it should just be copying it).
Since edge cut doesn't do anything yet with face interpolation,
cuts that arn't exactly centered will move the underlying multires
geometry around a bit..
Multires interpolation is considerably better
now, though it still has a problem with occasionally
producing little random tangent spikes. Still, it's
far better then it was.
Also fixed a bug in dissolve faces.
Multires interpolation. It's quite usable yet; I wanted to avoid
subsurfing the multires data and ray tracing original/new
topology. The result is kindof like trunk's interpolation.
I'll see how much better I can get it. I might have to go with
the full-on ray tracing solution. Right now, it's not very good.
Also made it so trunk files with multires open correctly.
Fixed view selected code. Made MDisps->disps use the
special allocation library I wrote as a
temporary fix to MDeformGroup->dw problems.
Why was the vgroup solution reused? It's really slow,
and its hard to tie in something like mempool or memarena.
The hackish allocator I wrote really needs to go, eventually,
or be folded into guardedalloc.
Also fixed a customdata bug with modifiers.
- use NULL rather then 0 where possible (makes code & function calls more readable IMHO).
- set static variables and functions (exposed some unused vars/funcs).
- use func(void) rather then func() for definitions.
Used a crazyspace approach (like in edit mode), but only modifiers with
deformMatricies are allowed atm (currently shapekeys and armature modifiers only).
All the rest modifiers had an warning message that they aren't applied because
of sculpt mode. Deformation of multires is also unsupported.
With all this restictions users will always see the actual "layer" (or maybe
mesh state would be more correct word) they are sculpting on.
Internal changes:
- All modifiers could have deformMatricies callback (the same as deformMatriciesEM but
for non-edit mode usage)
- Added function to build crazyspace for sculpting (sculpt_get_deform_matrices), but it
could be generalized for usage in other painting modes (particle edit mode, i.e)
Todo:
- Implement crazyspace correction to support all kinds of deformation modifiers
- Maybe deformation of multires isn't so difficult?
- And maybe we could avoid extra bad-level-stub for ED_sculpt_modifiers_changed
without code duplicating?
This adds the "Apply Base" feature from my gsoc2010 branch.
Apply Base partially applies the modifier, in that the mesh is
reshaped to more closely match the deformed mesh. The upper-level
displacements are recalculated so that the highest multires level
appears unchanged.
Multires does not currently deal well with too large displacements.
An easy-to-reproduce example: create any mesh type, add multires,
subdivide a few times, then use the sculpt grab brush to drag the
entire mesh over a few units. At the highest level, and at level 0,
the mesh looks fine, but all of the intervening levels will have ugly
spikes on them.
This patch doesn't help with situations where you can't modify the
base mesh, but otherwise works around the problem fairly well (albeit
with a heuristic, not an exact solution.)
work correct with sculpting data now.
Joining two triangles could give incorrect sculpting result for
special topologies, but it's that case that can't be nicely handled
with our layers architecture.
Sculpt data shouldn't be lost when making topology changes without
quads<->tris face converison.
General idea:
- Go through all grid points of each corner and convert per-corner
coordiante to per-face cooredinate
- Apply weights and convert new point to per-corner coordinate
- Use bilinear interpolation to get needed displacement vector
Some additional work was necessery:
- Two neighbour corners could have different displacements along common
boundary. multires_mdisp_smooth_bounds() makes displacement "symmetrical"
- Point could change it's corner, so displacement vector should be flipped
in some way. In some cases it's not only flipping, because corner could
be mapped with some rotation. It's not solved for triangular faces yet,
so only z-axis displacement would be interpolated for tris.
More limitations:
- Interpolation will give incorrect result after quad<->triangle
face conversion.
- When face normal was fillped displacement would change it's direction too.
Fixed bug #20620, "VertColors and Flat/Soft imported from 2.49 are wrong
(MultiRes)" reported by Manuel R.
* Added function to load level-0 vertex colors
* Added function to load level-0 face flags
* Warning: the 2.5 multires modifier doesn't support multires vertex colors
or multires face flags; that data will be lost if you import it into 2.5.
