Age | Commit message (Collapse) | Author |
|
=======================
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!
|
|
|
|
|
|
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.
|
|
to multires.c
No functional changes
|
|
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.
|
|
|
|
- MDisp should be re-allocated if face changed amount of vertices
- Allocate disps array in layerSwap_mdisps to prevent loosing all highres data
|
|
multires object.
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
|
|
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
|
|
should not do multires reshape in this case, but just regular apply.
|
|
- Pass MultiresModifierData to reshape functions
|
|
|
|
|
|
multires modifier if both are in the stack (patch #21965)
This patch also removes limitation of multires reshaping when
destination object has got modifiers after multires modifier.
|
|
|
|
fixed by last depsgraph commit and this extra check to avoid unnecessary
free of derivedmesh for sculpt/multires.
|
|
* Multires 2.50 -> Branch compatibility code converting to the new
displacement format. 2.49 -> 2.50 is not functional yet.
|
|
* Smooth brush works again for multires.
* Optimal Display option for multires modifier, same as subsurf.
|
|
* Displacement coordinates are now stored differently, as a grid per
face corner. This means there is duplication of coordinates, especially
at low subdivision levels, but the simpler implementation justifies it
I think.
* ToDo: conversion of existing multires files (2.4x or 2.5x), loading them
may even crash now.
* Editmode preservation/interpolation code also has not been updated yet.
* Multires now works on the CCGDerivedMesh grids instead of CDDerivedMesh,
which should be more memory efficient.
* There are still bad memory peaks (if you're using 32bit) when subdividing
or propagating displacements. Though at least there should be no huge
memory blocks allocated, which windows is now to have trouble with.
* Still found some weird spike artifacts at lower multires levels, some also
happening before this commit. Perhaps computation of tangents needs to be
tweaked more.
* Multires modifier now has viewport, sculpt and render levels. Also the
levels have been made consistent with subsurf, previously the same level
of subdivision was one less for multires.
* Both multires and subsurf modifier now can have their subdivision level
set to 0 for no subdivision.
|
|
* Fixed multires subdivision of a sculpted object. Accidentally broke this when I fixed removing a multires modifier.
|
|
* Fixed a memory corruption bug when deleting a multiresmodifier, was hanging on to a bad pointer. Reported on IRC by lusque
|
|
Attempt to make multires updating a little cleaner by
assuming that no update needs to be performed, and only
doing the update when the modified flag is set (either
by sculpting or using some other tool that needs an update.)
|
|
Added subdivide operator and button for multires.
Since this seems to be the only modifier with an operator defined, I'm not sure if I put it in a good place or not, someone can check on this?
|
|
whether to use brush spacing.
|
|
soc-2008-nicholasbishop branch.
Note: any old code with multires_test() or multires_level1_test() can
just be deleted, not needed by the multires modifier.
|
|
Think global, act local!
The old favorite G.scene gone! Man... that took almost 2 days.
Also removed G.curscreen and G.edbo.
Not everything could get solved; here's some notes.
- modifiers now store current scene in ModifierData. This is not
meant for permanent, but it can probably stick there until we
cleaned the anim system and depsgraph to cope better with
timing issues.
- Game engine G.scene should become an argument for staring it.
Didn't solve this yet.
- Texture nodes should get scene cfra, but the current implementation
is too tightly wrapped to do it easily.
|
|
Fixed bug #9680, Crash on render
Caused by multires sometimes looking at editmesh data rather than mesh data during render
|
|
Fixed bad level calls in sculptmode.
|
|
Fixed bad level calls within multires usage.
|
|
Cleaned up bad level calls for multires; moved most of multires functions to blenkern, where they should have been in the first place. Functionality of the tool is unchanged.
|