Rather then only baking parent objects. Only bake objects which are have no parents in the original scene.
This allows for parenting and unparenting within the game engine without gaps in the animation curves.
- 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 ?
bge.types
---------
- removed lists if they were already available in bge.logic and crosslinked
where the list contained description, moved the descriptions in bge.logic
so we have useful thing in one place only
- fixed a lot of bad formatting, like bad indentation and usage of TAB
- changed from literal to codeblocks that smerch for the useful suggestion :)
- whered appropriate I've moved code examples to the end, after notes and all
it is blocking to have a big black block before actually see a method parameters or return type
- have doubt about the list at bge.types.html#bge.types.SCA_MouseSensor.mode
possibly tomorrow will ask Dalai
bge.logic
---------
- added sensor status list
- cross linked with bge.types where needed
- added a section "ShapeAction Actuator" because in bge.types these constants are docuemented, but in 2.5 I don't see the ShapeAction Actuator
(anymore, or for now)
I'll ask Dalai tomorrow or when possible (check bge.logic.html#shape-action-actuator once cambo rebuilds the docs)
- moved descriptions from bge.types lists to logic page where appropriate
- where possible, added custom directive :value: so we have a consistent way to show the value of constants
* 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.
