+bvhtree cache (if the derived model doenst gets destroyed then the same BVHtree can be used)
this was needed to allow shrinkwrap constraint to be usable.
It has been ready for a long time.. but only got merged now, for 2.49.
EditMesh *EM_GetEditMesh(Mesh *me);
void EM_EndEditMesh(Mesh *me, EditMesh *em);
as discussed on the mailling list, this is to facilitate migration to bmesh.
next step is to merge this this to the bmesh branch. this was done in the 2.5
branch to prevent too great a divergance.
also, made makesdna/makesrna work on cygwin/msvc2008/scons.
Think global, act local!
The old favorite G.scene gone! Man... that took almost 2 days.
Also removed G.curscreen and G.edbo.
Not everything could get solved; here's some notes.
- modifiers now store current scene in ModifierData. This is not
meant for permanent, but it can probably stick there until we
cleaned the anim system and depsgraph to cope better with
timing issues.
- Game engine G.scene should become an argument for staring it.
Didn't solve this yet.
- Texture nodes should get scene cfra, but the current implementation
is too tightly wrapped to do it easily.
From the anti-globalization department:
G.obedit terminated!
Wherever possible, use CTX_data_edit_object(C) to get this
now. It's stored in scene now, and the screen context has
it defined.
So, editmode mesh is back! :)
At the moment only TABkey works and mouse select, 1 vertex at a
time. More will follow of course.
Note for the devs:
- G.editMesh has been removed, be careful with old code.
- EditMesh now is property of Mesh itself
Although it means unlimited editmodes, for migration purposes we
better stick to 1 "obedit" per scene, which is in Context too
- G.obedit will get removed soon, so use CTX_data_edit_object(C)
Or if you can't, just scene->obedit for now
- Also removed the CTX_data_edit_mesh(), this has no meaning
anymore. EditMesh is not context senstitive anymore, only the
edit-object for time being is.
- Martin: I've already tucked some EditMesh pointer in T and
removed all G.editMesh there.
- Particle now use the deflector objects collision modifier data to collide with deflectors and as a result can now use the velocity of the colliding object for more realistic collisions.
- Dynamic rotations are also quite a bit more realistic and are related to the friction setting of the deflector (to get any dynamic rotations there has to be some friction). This is largely due to the separate handling of rolling friction (approximated to be 1% of normal sliding friction).
- Collisions should be a bit faster on complex deflectors due to the tree structure used by the collision modifier.
- Collision should also generally be a bit more accurate.
To be noted: Only the average velocity of individual deflector faces is used, so collisions with rotating or deforming objects can't be handled accurately - this would require much more complex calculations. Subdividing the deflector object surface to smaller faces can help with this as the individual face velocities become more linear.
Now when doing normal projeciton is possible to ask it to project along the normals
that the vertex would have if it was subsurfaced... this gives "better" projections on
low polys.
Point of this commit is to add the feature request from Eclectiel
http://blenderartists.org/forum/showpost.php?p=1181531&postcount=9
workflow as Eclectiel wanted is now possible:
to archieve a nice low-res retopology that aproximates a high-res mesh when subsurfaced:
1 - make base low-poly retopo
2 - apply a shrinkwrap with projection along normal.. and with SS level = N (where N>0)
3 - add a Subsurface with level N
4 - run bretch's script (ss_fit)
*removed commented code about the dropped shrinkwrap options
*Removed references to "cut plane", "limitMesh".. its now called "auxiliar target"
*Added option to shrinkwrap over an selected axis
*"Normal projection" mode is now called "projection" since it can now project over "normal, and any combination X, Y, Z"
*the options "remove faces", "merge" points were removed
*made shrinkwrap work with CVs (curves and nurbs surfaces)
*cleanup shrinkwrap code.. (removed bruteforces and raytree methods)
*Made nearest surface also use "quad" bvh tree (instead of splitting quads in 2 bvh nodes).
Again that leaded to improvements in build and query time.
*BLI_bvhtree_find_nearest api is now following the same concept as BLI_bvhtree_ray_cast
removed code relative to bvhtree_from_mesh_tris.
Its now faster than raytree (both on build and query)
Things tryed:
X=>Y=>Z=>X split (reduces build time.. but increases query time)
bucket sorts
(initial sorts for fast usage of bucket take a long time)
(nth is linear.. so its quite fast already)
Best times archieve with:
*usage of 4-ary trees.. reduces build time and tree size but didnt decreased query time
*quads are on the same node instead of splitting in 2 tris..
(this actually turned on speedup on query time.. since tree size is reduced by a factor of 2)
*test ray-bb before ray-primitive gives better times on both tris and quads
Notes:
measures where made projecting a sphere from inside the head of suzanne.
small bvh fixes:
*allow to create any tree type >= 2
*save split axis
changed shrinkwrap to perform normal cast with raytree and bvh tree and print both times:
Shrinkwrap (OBCube)24578 over (OBSuzanne)504482
target = raytree_create_from_mesh(calc->target): 1260.000000ms
shrinkwrap_calc_normal_projection_raytree(&calc): 1850.000000ms
tree = bvhtree_from_mesh_tri(calc->target): 3330.000000ms
shrinkwrap_calc_normal_projection(&calc): 3780.000000ms
On general query time is bit smaller on bvh tree..
but the build time of bvh is pretty big.
(build time can be removed from both if a cache system is added)
But I am still trying to see how fast I can make the bvh build
*Fixed a few UI things
*Make SimpleDeform and Shrinkwrap to use vertexgroup_get_vertex_weight, a similar function
"static float vert_weight(MDeformVert *dvert, int group)" existed on modifier.c, changed
it a bit and moved into BKE_deform.h
Changed code to remove faces (now quad faces that got one vertice projected are turned on tri)
Merge option is still not very usefull since shrinkwrap does not yet moves unprojected vertices
I'll work on making it more generic.
So far it querys faster than kdtree, but building the tree is slower.
And bvhtree NN uses an heuristic based on the last match.
Shrinkwrap (OBCube)24578 over (OBSuzanne)31658
kdtree
build: 30.000000ms
query: 1360.000000ms
bvhtree
build: 140.000000ms
query: 490.000000ms
Shrinkwrap now uses bvhtree (binary tree, 6dop) for nearest vertex.
+added option to remove faces where all vertices got unprojected
Nearest surface point
+15% faster closest point on point-tri function
(archived by projecting the point on tri-plane and solving the problem on 2D)
(its still using bruteforce on triangles.. I'll add the right data structure later)
+control for normal projection direction (default,inverted,both)
There are some bugs on projection over quads.. it seems to work 100% on fully triangulized meshs
+ Nearest surface point
+ Normal projection
+ Nearest vertex (gives similar results to nearest surface if the target mesh has many vertexs and is a lot faster to calculate)
^^ all bruteforce calculation for now
+ fixed matrix order multiplication
+ request for CD_MDEDEFORMVERT
