- no start 4 split anymore, split 3d win in 3rd screen instead
- print of name active object in 3d window
- added a theme in the file, for manual demo
- no scrub/sync set
- removed text files
- auto save on (per 5 minutes)
- no standard osa rendering
- and i might have forgotten some
All for getting a manual compatible version. but the 4 split in start for
2.30 release caused quite some annoyed reactions.
this is safe initialization only.
based at report from madprof.. he had a 2.30 file without this
data correctly initialized... but how it happens? tuhopuu files?
anyhoo, we might think of splitting do_versions in 2 parts:
1. do_versions initialization of old variables that changed
like physics properties that need to be scaled or so
2. do_init for newly created variables that are not allowed to be zero,
this can safely be done for each file
Updated the Make environment to point to the correct location. The include
paths were still pointing to source/blender/bpython/include while it should be
source/blender/python.
I did not encounter the build problems because I'm always working with the
autoconf build environment.
input. Somewhere in end NaN period this was changed... weird.
Now you can set layers with numeric buttons, including using ALT for
numbers larger than 10, and using SHIFT for extend-select buttons.
for the UI diehards who like to know; when you create a menu block, you
can provide two flags to control behaviour on keyboard input:
UI_BLOCK_RET_1 == return on any keypress (not mouse)
UI_BLOCK_ENTER_OK == return on Enter key
this was not correct in the doc/interface_API.txt , which will be fixed.
even for each redraw! Now its all smooth & fast again.
introduced new kernel API call: int is_basis_mball(ob), this provides a
quick check of the object is the actual basis for the displaylist and
polygonization.
I've tested pretty much everything, but please proof read the code, the fonction calls and IFDEF could be used elsewhere (especially the IFDEFs, I wasn't sure if I had to enclose the whole function or whatnot.
colors. This because of the pretty weird (ab)use of load & make editmesh...
For each added undo step, the load_editmesh was fed with an empty mesh
to assign data to, without knowledge of what was in the original mesh.
That way UV and color data got lost.
Solved it in 2 steps:
1. removing the ->tface pointer from EditVlak, and make TFace a builtin
struct inside EditVlak. This didnt cost much extra mem, since it already
stored UV and color. This enabled some pretty cleanup in editmesh.c as
well, storing tface pointers was cumbersome.
2. for each undo step, it then generates always a tface and mcol block to
link to the undo Mesh.
Even when it wasn't in the actual Mesh, at exit editmode the original
Mesh is used as reference anyway, and undo-meshes are freed correctly.
The enormous commit is because I had to change the BLI_editVert.h file, and
found it was included in about every file unnecessary. I removed it there.
ALso found out that subsurf has code ready (unfinished) to make UV coords for
the displaylist in EditMode as well, nice to know for later...
thus also preserved over exiting/entering editmode (is this desirable?)
Can be turned off easily ...
- "Half-fixes" lost UV info problem with undo. I couldn't get it to
crash or lose UV info anymore, but we now have a memory leak (me->tface).
Ton, please check this!
a follow-path constraint in 2.28c without data assigned.
this patch checks for proper data in a constraint, if not available
it will turn the type into CONSTRAINT_TYPE_NULL
- i will forward the demo file to theeth for further check
