PBVH used the same verts array as mesh data and shape key/reference key coords
were applying on the mesh data, so on some refreshing undeformed mesh was
displayed.
Added utility functions to get vert coords from key block, apply new vert coords
on keyblock and function to apply coords on bpvh, so now pbvh uses it's ovn
vertex array and no changes are making to the mesh data.
Additional change:
Store key block name in SculptUndoNode, so now shape wouldn't be copied to
wrong keyblock on undo
The most useful effect of this is that set scenes can take the simplify settings from the current scene (render team doesnt have to worry about animators simplify settings).
details...
- updating on frame change now passes the parent scene to object update function. (this was alredy happening for updating tagged objects)
- set scenes objects update first so scenes can depend on set objects however this only happened at once level, now set scenes are updated recursively, so deepest level is updated first.
- collision objects used to only look through the current scene, now set objects are included.
* Enabled premultiplication for packed images
* Added pack/unpack operator to image template
* Moved brightness/contrast corrections to after de-premultiplication in image texture sampling
path -> filepath (for rna and operators, as agreed on with elubie)
path -> data_path (for windowmanager context functions, this was alredy used in many places)
Throwing an exception if the strings too long means scripts need to be aware of string lengths and changing a string length in RNA can too easily break scripts.
Instead honor the string length in RNA_property_string_set()
Was actually a couple bugs:
* VBO bug was that hidden faces weren't being skipped correctly. Fixed that and rewrote this bit of VBO drawing code more clearly (less duplication, less unecessary state, and comments even)
* Second bug was that CCGDerivedMesh wasn't outputing ORIGINDEX data for faces. (it's not doing it for edges or verts either, but I don't know that we need it to.) At any rate, we do need this data for faces so that additional DerivedMeshes on top of subsurf know what faces in the editmesh are hidden.
resulting in sounds that didnt play in the sequencer unless you removed and replaced them with a strip that pointed to the new path.
The way these 2 datablocks work together is a bit odd, I think this is OK for now but should be better defined.
What was happening; if
the old code (2.49) was changing the status from 0 to 1 inside the interface code. e.g. if (!ob->status) ob->status = 1;
Initializing it properly (in blenkernel) and making sure the new status is ever 0 (in rna_object.c) should fix it.
And yes, the log is bigger than the patch !
ShrinkwrapCalcData->vert contains verts from derivedMesh this coordinated
are deformed by vertexCos only for normal projection (to get correct normals)
for other cases this field contains undeformed dm's coordinates and
vertexCos should be used
This modifier used undeformed coordinates from emDM.
Added method getVertCos to emDM, so meshdeform now could use it
to get deformed coordinates form any derived mesh.
* 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.
* Problem was that the sculpt PBVH was only used for redrawing if the derived mesh's vertices were equal the base mesh's vertices, which isn't the case when sculpting on shape keys.
- WITH_LCMS added option, was supported in scons.
- commented web plugin option since its not maintained.
- some formatting changes and removed includes that are not needed for source/creator/CMakeLists.txt.
broke when including the blend path in the modules filename.
- new function BLI_path_basename(), matches pythons os.path.basename().
replace a number of cases where BLI_split_dirfile was being used to get the filename only.
* Now it displays the last report from the global list, not just from operators
* Rather than disappearing when a new operator is run, it stays until it times
out or a new report is added
* Fun animated transitions ;)
http://mke3.net/blender/devel/2.5/reports_header.mov
Now need to investigate report usage with popups. Ideally we can have most
reports non-blocking, so they're less intrusive, only popping up for dire errors.
Problem is many things in Blender right now are marked as RPT_ERROR
when probably RPT_WARNING is more appropriate. Should probably keep
RPT_ERROR for things that demand immediate attention.
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.
[#21994] hair particle system with dupli object set to particle system object itself results in 100% cpu usage
[#22023] [Rev 28117]Can't bake particles?
[#22065] in a particle system, setting the emitter as the dupli object crashes blender after pressing alt+a to animate
* Path drawing now works for non hair particles.
* Should fix the following bugs too:
[#21316] Hair weight drawing is wrong
[#21923] Consistent Crash When Rendering Particle Scene.
[#21950] Path rendering option for particles causes crash
- Also made it so sys.stdin isnt overwritten anymore, instead the interactive consoel overwrites while it executes and restores after.
- removed hope folder from sphinx patch path
Since curve objects could have constructive modifiers, we can't
always avoid setting OB_RECALC_DATA to linked objects (displist
recalculation wouldn't enough for curves with such modifiers)
Reorder callning of add_keyblock and do_ob_key in insert_*key.
do_ob_key shouldn't be called for object with uninitialized key blocks.
NOTE: this commit not fixing problems with slurph
1) Fixed some weird formatting introduced during math-lib cleanups, and some other inconsistencies
2) Optimised the Maintain Volume constraint by taking the value calculations out
Copy All Constraints Operators:
* Added one for bones too
* These are now included in the menus
* Removed some weird/extra code copying/changing/bleh the actcol/totcol stuff...
This constraint allows an object or bone to have their rotations applied as if their origin/pivot-point was located elsewhere. The most obvious uses include foot-roll, see-saws, but could also include more complicated rolling-box examples.
== Usage Examples ==
=== Foot Roll ===
1. Add 'Pivot' Constraint to the bone without any target.
2. Set the 'Y' value of the offset to the length of the bone. Usually this should be negative (if you rig with feet facing 'forwards' along -Y axis). This gives you a pivot point relative to the bone's (preconstraint) location, which should be at the tip of the bone here. Disabling the 'Use Relative Offset' would make this offset be relative to 0,0,0 instead of to the owner/bone-head.
3. Ensure that the 'Pivot When' setting is set to '-X Rot', (default) which means that the pivot will only used when the rotation on the X-Axis is negative to get tip-toe 'roll'.
=== See Saw ===
1. Add a 'Pivot' constraint too see-saw plank object, this time with a target that you wish to have as the pivot-point. It's possible to do this without too (as before), but is less intuitive.
2. Optionally, if you want the plank slightly raised, set the z-offset value, which should make the pivot-point used to be relative to the target with the z-offset applied.
3. Ensure that 'Pivot When' is set to 'Always', which means that the pivot will always be used, irrespective of the rotation.
== Notes ==
* The 'Pivot When' setting has been integrated in the constraint, since this is something that will often be required for these setups. Having to set up additional drivers to drive the constraint to do this kindof beats the purpose of providing this.
* The 'Offset' functionality is probably not presented as clearly as it could be. We may need to go over this again.
* For foot-roll - if any scaling of the foot is required, simply set up a driver on the y-offset to make this dynamically respond to the "scale" RNA property of the bones (don't use the "Transform Channel" vartype since that won't work correct here). However, this shouldn't be common enough to warrant special treatment.
