this means use of deprecated struct members gives a warning.
- makesdna.c preprocessor skips this.
- DNA_DEPRECATED_ALLOW is used so readfile.c can do versioning without warnings.
- this exposes some use of deprecated struct members, will deal with this after.
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.
=======================
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.
- 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.
Fix#22018: joining objects with different multires levels loses levesl from the higher multires object
- Synchronyze mulires subdivision level when joining objects
- Apply scale on MDISP layer when applying scale
- Re-calculate MDISP when joining scaled objects
- removed deprecated bitmap arg from IMB_allocImBuf (plugins will need updating).
- mostly tagged UNUSED() since some of these functions look like they may need to have the arguments used later.
Fixed bug #23657, "Modifiers dosen't work when you select diffrent mesh for object"
Multires modifier now adds empty mdisps if they're missing, rather than displaying a warning
Switching an object's mesh will now check for a multires modifier; if found the modifier's total number of levels are reset to match the mesh's mdisps
Switching the mesh also forces a multires update so that sculpted changes aren't lost
* UV data on multires meshes wasn't getting imported properly. Fixed by separately loading in all "first-level" data from the old multires data type into mesh. Note that an "incorrect" data layers might still be loaded and be active on the mesh, but the correct layers should now also show up in the UV layer selector.
Fixes various crashes and redraw problems, most noticeable new feature
is that you can now sculpt on a multires mesh with deforming modifiers
preceding it.
I've left out support for sculpting on multires with enabled modifiers
following it, in this case only the base mesh can be sculpted now. The
code changes needed to do this are just too ugly in my opinion, would
need a more torough redesign which I don't think we should try now. In
my opinion this is also not really an important case, since it's going
to be incredibly slow anyway to run a modifier on a high res mesh while
sculpting.
So, to summarize current state:
* Fastest sculpting: base mesh with no modifiers or multires with only
modifiers preceding it.
* Slower sculpting: base mesh with modifiers, depends on the speed of
the modifiers.
* Not supported: multires mesh with modifiers following it.
for now, it's too fine grained and so becomes a performance bottleneck on some
platforms, while only providing a modest speedup on others. Couldn't find a
simple enough solution to solve this, so for now no multithreading here.
