possiblem, this has to guess when the size is too big so as to re-
well.
If this isnt done, then the number of faces is used to allocate the
initial array to at least avoid many small allocs.
added BLI_array_reserve() to reserve elements and avoid reallocing many
small arrays when the loop starts.
=========================
Documentation: http://wiki.blender.org/index.php/User:Psy-Fi/UV_Tools
Major features include:
*16 bit image support in viewport
*Subsurf aware unwrapping
*Smart Stitch(snap/rotate islands, preview, middlepoint/endpoint stitching)
*Seams from islands tool (marks seams and sharp, depending on settings)
*Uv Sculpting(Grab/Pinch/Rotate)
All tools are complete apart from stitching that is considered stable but with an extra edge mode under development(will be in soc-2011-onion-uv-tools).
There are also some changes that need to be done to libmv but I'm
leaving those out so I can get it patched upstream first.
(Only works with gcc/g++ if we want to use sun's compiler we would need
to get rid of all of our annonymous structs which I don't think
we want to do at this point, example:
typedef struct wmNDOFMotionData {
union {
float tvec[3]; // translation
struct { float tx, ty, tz; }; // this would need to be fixed
// something like this or something similar:
struct { float x, y, z; } t;
};
...
)
Kent
* Accelerated sRGB <=> linear conversion using lookup table, this can speed up
loading of images in the compositor and simple renders quite a bit.
* Dithering now uses the Floyd-Steinberg algorithm. Previously it would simply
randomize each pixel slightly, adding noise, now that should be reduced.
Patch #29309 by David M.
comparing bmesh to trunk, mesh_calc_normals() in bmesh is a much more comprehensive function, calculating mpoly,mface normals, where trunk only calculated vertex normals.
renamed:
* mesh_calc_normals() --> mesh_calc_normals_mapping_ex
* mesh_calc_tessface_normals --> mesh_calc_normals_tessface() - only calculates normals from tessface
* added mesh_calc_normals() - only calculates normals from poltys
this way we can have mesh_calc_normals() remain fast for parts of the code which only need vertex normals to be updated.
only refactor, no func changes- didnt replace mesh_calc_normals_mapping_ex() with mesh_calc_normals() anywhere yet.
The problem was in fact in recent BLI_edgehash changes: a typo in the new macro EDGE_ORD made v0 > v1, instead of v0 < v1. This caused the bug in explode modifier, which (ab)uses that ordering feature a bit…
This commits merges object tracking implementation from tomato branch.
Summarized changes from branch:
- Added list of objects to be tracked. Default there's only one object called
"Camera" which is used for solving camera motion. Other objects can be added
and each of them will have it;s own list of tracks. Only one object can be used
for camera solving at this moment.
- Added new constraint called "Object Tracking" which makes oriented object be
moving in the save way as solved object motion.
- Scene orientation tools can be used for orienting object to bundles.
- Object has got scale to define "depth" in camera space.
- All tools which works with list of tracks or reconstruction data now
gets that lists from active editing object.
- All objects and their tracking data are available via python api.
- Improvements in witness cameras workflow,
byte => float, float => float, byte => byte conversions with profile, dither
and predivide. Previously code for this was spread out too much.
There should be no functional changes, this is so the predivide/table/dither
patches can work correctly.
