- making local object data - Curve/Mesh/MBall lost references to linked materials.
- joining a linked mesh object into a local one lost the link.
As well as these reported bugs, checked all local functions for consistency/correctness and found other cases which would also fail.
- making local metaball didn't ensure unique ID name.
- make_local_armature() was missing check for object users - main body of code would never run.
- local particles didn't set the dupli-group or textures to extern.
checked all local functions for consistency/correctness.
* Collision modifiers are disabled here by intention, but particles and softbody were copied the wrong way over :)
* On a further note I don't really get this whole "link modifiers" thing as it just copies the modifiers. As modifiers aren't ID blocks there's no sense in calling this linking!
* Secondly I don't think particles, smoke etc should be considered as modifiers here at all, meaning they shouldn't be linked/copied. These "modifiers" only read the mesh data at a certain location of the stack, but don't actually modify the mesh in any way (more info here http://wiki.blender.org/index.php/User:Jhk#Modifier_Stack_proposal).
- render check for ortho/panorama combination wasn't working since the flags were not initialized at the time of checking.
- disable panorama button in ortho mode.
Object.is_modified(scene, 'PREVIEW') function for python exporters to check if any modifiers or shape keys are applied (weather the original mesh can be used for exporters).
problem and crash
- It turns out we still need the "copyob" still, if for nothing other
than making sure that the unkeyed transforms can get restored. This
was removed originally as I thought that just reevaluating the
animation would work.
- Removed a buggy line of logic that was causing crashes when there
was no animation data. It's better to just assume that if animation
data exists, that something exists there.
- Make Duplicates Real was not clearing data such as the new animation
data or constraints.
So, it turns out that dupliframes weren't that bad to restore... the
old version didn't do truly accurate transform freezing as it didn't
update ancestors too. However, as a modelling tool, this will probably
suffice.
- 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.
- use BLI_math functions for removing rotations from objects and pose channels.
- add unit_axis_angle() to avoid setting the Y axis inline anywhere rotation needs removing.
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?
they have some rotation-affecting constraint (i.e. Track To and Copy
Rotation) targetting, transforming the objects (directly, using GKEY
-> grab) becomes unreliable.
This was caused by a typo in some code checking for some
OB_NO_CONSTRAINTS under "flag" instead of "transflag"
Since 2.5x blender has been using CD_MASK_BAREMESH for updating objects since object_handle_update() no longer has access to G.curscreen to calculate the mask from viewports.
The problem with this is after an initial calculation, CD_MASK_MTFACE may be required on draw, so it would recalculate the modifier stack multiple times per frame.
One case which caused this is armature animated mesh with texface in a dupligroup.
Fix this by having customdata_mask member in the scene, this isn't great design but at least fixes the bug and only changes a few files.
Makes adding new flags give ambiguous results and also makes it less easy to tell whats intended.
In some places it looks like OB_RECALC_TIME should be left out too.
This would have made bug #25003 very simple to find.
- Objects had their quats normalized when calculating their matrix, this is inconstant with pose bones and isn't useful for animation.
Also it wasn't normalizing the delta rotation so these would give bad rotations.
- Converting between rotation modes BKE_rotMode_change_values() assumed normal length quat. changing quat to euler rotation for eg could change the bone.
- Clear rotation and transform were not normalizing the quat when 4d loc was disabled on quat rotation, corrected and also made it so the quat scale is restored after conversion so animations curves dont jump.
There is 1 case in mat3_to_quat_is_ok() where quat_to_mat3 on an unnormalized quat is needed, for this I had to add an ugly static function quat_to_mat3_no_assert(), but overall its worthwhile IMHO to be able to find incorrect use of rotation conversion.
also added note that adjusting bone radius changes the parent bone for connected child bones, and fix typo on failing to read startup.blend (both pointed out by MikeS on IRC)
Also use const char in many other parts of blenders code.
Currently this gives warnings for setting operator id, label and description since these are an exception and allocated beforehand.
Now object_apply_mat4() can be used as the reverse of object_to_mat4().
Noticeable result is fly mode and 'Apply Visual Transform' dont jump when deltas are used, also means setting matrix from python works as expected.
- object updates were not being flushed, so children weren't updating.
- apply the matrix relative to the parent, added this as an option to object_apply_mat4() which allows assigning the worldspace matrix in python without worrying about the parent.
object_apply_mat4 was incorrectly negating the matrix values,
This worked in most cases but even when it worked would end up with negative scales too often.
now when no negative scale is used they will all stay positive and from my tests it works in all cases now.
committed r32598 to fix [#24309] Reloading file with incorrect path location.
Setting the curves ctime when updating the object data overrode the animated value.
For now just set the ctime on newly added curves with will work as the user expects in most cases.
This is weak design IMHO because the ctime value can be set to anything but is reset on changing frames even if its not keyed.
With curves created via python or linked in this can still result in a bad ctime value.
the cu->ctime was never set if the frame wasnt changed, so adding a curve and parenting could be done without a frame change leaving the cu->ctime value at zero.
changing the frame or rendering after this would make the parent relationship jump.
Set the curve->ctime in object_handle_update(), this way its set on file load and when linking in new curves.
Another option is to do this when parenting but probably this would miss other cases where its needed.
--- fixes report by ronan ducluzeau
Scale default cube on X axis to -1.
Rotate it on X axis to 33°.
Parent cube to lamp.
Clear parent and keep offset.
Cube's scaling value on X axis pass from -1 to 1
Cube's rotation value on Z axis pass from 0° to 180°
the bug was in object_apply_mat4(), caused by applying a non-normalized matrix to the rotation.
Blender 2.4x also had this problem, surprising nobody noticed!.
- 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.
This should help silence complaints from some about "dloc",etc. not being easily keyable.
It's also a nice way to have instances of animated objects located in different places, by animating either the standard transforms or the deltas, and then modifying by not animating the other version to keep the instances from going to a single point. This was a common newbie problem in 2.4x.
