- bpy.context wasnt being created from the python bpy.types.Context type defined in bpy_types.py (bpy.context.copy() failed for eg.)
- bpy.context.copy() was returning C defined methods like FloatProperty(), which are not useful in this case, removed.
- added relative option to saving external multires data
- renamed multires external functiosn to have save / pack as suffix.
- added TODO's for file select operators that should support relative paths but dont.
- also disable openmp on linux cross compile, mingw currently isnt linking -lgomp
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 !
This prevents header-less panels (such as object name in object properties) from being re-sorted
when dragging other panels.
Also minor tweak, make the 'a' key shortcut to open and close panels only work with there are no
other modifier keys (like alt).
Joe already committed this to render branch in r28545, but it's not in trunk.
The code that was committed doesn't seem to work properly, either, needs braces.
rather than in its own internally used emitting-face-coordinate-system
(which is how the data is stored in DNA - that data now exists in rna as
hairkey.location_hairspace)
Basically this makes the hair information that's in rna a lot more useful,
making it possible to export hair strands to external renderers for example.
This is because the make_links_data_exec don't check for the
object type like before, so try to access the obdata of an empty
and blender crash.
The solution is not the best, we have a new function
allow_make_links_data to check if we can links data from one
object to another.
The real solution is build the menu like the 2.4x, so only
show the options that we allow for the object type that
we have select/active.
Matt, any suggestion ?
* Problem was that the modifier directly accessed ob->derivedFinal, but that wasn't being built if the object was on a different layer. Changed to mesh_get_derived_final.
Notes:
* I fixed this for array and boolean, reported in the bug; there might be other places affected by this mistake. It's an easy fix if so.
* The datamask being passed in isn't especially correct. Possibly we should be accessing the datamask being used to build the array modifier DerivedMesh? Anyway, at least this will get the mesh to show up in the viewport.
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.
* Changed the RNA for RegionView3D to not inherit from "Region", which is "ARegion" in DNA. As far as I know, in order to inherit like that the RegionView3D struct would need to start with an ARegion struct?
* 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.
