Also construct orco uv layer when converting curve to a mesh.
This makes it possible to preserve automatically generated coordinates
("use uv for mapping" option) when using constructive modifiers or
converting curve to the mesh.
With cycles nothing special is needed to preserve texture mapping
after such operations, in blender internal you'll need to change
texture mapping from Generated to UV.
This feature is useful on it's own and also would help in potential
switch 3d viewport to always use DM to draw objects, which would
help making drawing more thread-safe.
give black speckles (self intersection errors) in raytraced shadows.
Motion blur does some extra offsets for free antialiasing in the motion blur
samples, but did not take them into account everywhere.
Issue was caused by render result passing to a compositor
was having a resolution of border when using a camera border
in cases there's no Render Layer nodes.
Made it so resolution in which compositor works does not
depend on whether Render Layers present or not.
Issue was caused by svn rev57566 which didn't take into
account the fact that curves could have dm of type CCGDM
and in this case CDDM_calc_normals_mapping_ex would fail
dramatically.
Added a check around normals update call bout whether
DM is CDDM or not. The same happens in mesh's modifier
stack.
KX_BlenderSceneConverter's destructor freed the contents of several std::vectors without removing those contents from the vectors. Later these vectors are iterated through. Making sure the vectors get cleared solves this problem.
This fix is mostly based off of HG1's patch from the bug report, which had ImageRender::Render() call KX_KetsjiEngine::RenderFonts(). However, I have moved RenderFonts() from KX_KetsjiEngine to KX_Scene where all of the other font and rendering functions are. The real fix for this mess would be to not have ImageRender::Render() have so much duplicate code from KX_KetsjiEngine::Render(), but that's a code cleanup problem for another day.
Update from a script I had in 2.4x, useful if you have mesh data which is _almost_ symmetrical,
there was no good way to automatically make the minor adjustments to make the mesh fully symmetrical.
Options for...
- symmetry-axis.
- blending between the +/- side.
- center mid verts.
Access from Mesh menu.
It removes buttons_header.c file, adds a (small) space_properties.py one, with a PROPERTIES_HT_header class, which simply uses the RNA enum to draw the context buttons.
It also fixes that enum, btw, it always featured all contexts, which means you could (try to!) set through RNA invalid contexts...
Thanks to brecht and dingto for the reviews.
Perhaps real fix would be to make all parts of blender
mandatory and not switchable off, so every area of code
would be compiled and verified after no-functional-changes
commits.
caused by recent changes in normal calculation, however curves were not being very smart about calculating modifiers (calling unneeded re-tessellation for every modifier)
the distance checks could get into a feedback loop so that the result depended on the order of verts/edges.
now you can randomize vert/edge/faces and get exactly the same results.
also made some internal improvements,
- used fixed sized arrays (no need to realloc).
- use vertex tag flags rather then a visit-hash.
- remove 'tots' array that did nothing (not sure why it was added).
Moved all the static variables into a PROCESS
structure which is now passing all over to where
static variables used to be used.
There's still one static variable which is
cubetable, but it's being initialized once
and then used read-only. Maybe we'll need
to move cubetable initialization to blender
startup, but that could wait a bit for now.
For users it means BI rendered viewport
wouldn't crash when using metaballs.
--
svn merge -r57515:57516 ^/branches/soc-2013-depsgraph_mt
