This shouldn't be a problem on any graphics card since internally a very old texture format (GL 1.1) is used. In the case of any unlikely screams, a revert of this commit can be done.
- drawing face normals was broken (using wrong index).
- drawing flat faces in solid mode would display ugly tesselation normals (as if the model was made of triangles).
- drawing smooth faces in solid mode would show vertex normals based on tesselation (heavily slant in 1 direction).
now the normals are calculated and stored per polygon (will save some memory too for non tri meshes).
Added option display_type to WM_operator_properties_filesel which defines which file
display type (short/list/icons/default) should be used for file browser.
All current operators are using FILE_DEFAULTDISPLAY display type which means display
type will still be calculated based on type of opening file and user preferences
settings. Recover Auto Save operator is now using long display type so file date can
easily be checked now.
Reviewed by Andrea, thanks!
* Fix: Substep update failed if brush was parented to a canvas vertex. Now substeps are ignored in such case.
* Fix: Wave "open borders" option didn't work for image sequence format.
* Fixed a possible crash after changing surface format to image sequence.
* Some code cleanup.
Contrast helps to adjust IBL (HDR images used for background lighting).
Note: In the UI we are caling it Bright instead of Brightness. This copy what Blender composite is doing.
Note2: the algorithm we are using produces pure black when contrast is 100. I'm not a fan of that, but it's a division by zero. I would like to look at other algorithms (what gimp does for example). But that would be only after 2.62.
Org code was working with isotropic scaling, but when scaling only one axis, it was broken. First fix just disabled completly scale handling. This version only takes into account scaling along local Y axis, as this is the only one affecting that constraint!
Sorry for the mistake, hope this time it will be ok.
Original indices from right operand were used in boolean result derived mesh
which lead to crash if right operand has got more entities (faces/edges/vertices)
than left operand.
Issue was caused by left boolean operand consist of several intersecting manifolds
which make Carve triangulator confused and which can't be resolved in general case.
Added mesh pre-processing before actual applying boolean operator on it. This
preprocessing applies union operation on intersecting manifolds of the same object
so intersection edge loop with second object wouldn't confuse tesselator and correct
result would be returned.
Detecting of intersecting manifolds is based on AABB intersection check which leads
to some extra union operation called, but it's possible to speed things up from
Carve side so union operation of two not intersecting meshes would work faster.
Additional condition for running union for manifold is this manifolds intersects
AABB of second operand, so mesh topology wouldn't be changed at all in areas
where there's definitely no intersection between operands. It might be improved
so only manifolds which actually intersects second operand would be joined
together, but it'll slow things down a bit and prefer to do it only if it'll
be really a problem.
Additional change is fixed memory leak when boolean operation fails to run -
it was missed "delete" call if exception happens in Carve library.
From side effects of this change might be named boolean operation between
suzanne and another object: suzanne is consist of three intersecting open
manifolds, so this new meshes preprocessing leads to missed eyes in result
because of failure of merging two open manifolds. Don't think making suzanne
work for all setups should really be a goal, it's a bit crappy mesh for CSG
algorithms.
In fact, we have to add a CD_WEIGHT_MCOL layer (if not yet present) when updating CD_WEIGHT_MLOOPCOL, else with modifiers modifying the topology (like subsurf), it will sigsev.
That step should probably be done at tesselation time, though…
Also simplifies DM_update_weight_mcol: no need to update CD_WEIGHT_MCOL here, as it is anyway recreated from CD_WEIGHT_MLOOPCOL at tesselation time. Only commented out code for now.
- was looping over all verts/edges/faces to setup the selection store, even when there was no selection store (mselect), since this is fairly common case, add a check.
also use BLI_array_growitems rather then BLI_array_growone to allocate in larger steps.
This has the advantage that it only does 1 alloc at the beginning if the stack variable is too small.
(rather then constantly check to grow one, which is a really huge macro too).
- reserve the array sizes to avoid re-allocing (even though its a lower limit it still helps)
- increase array size in larger steps then 1 by 1.
- avoid a few array lookups.
- use more obvious variable naming to make the function more readable.
The main issue in an implementation of these functions is the need to constantly edit the vertex array and subsequently update the face and edge arrays.
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.
The crash occurred when an action actuator was attached to a non-armature object because objects that aren't armatures do not have pose data. A NotImplementedError is now raised if someone tries to access any of the following with an action actuator attached to a non-armature object:
BL_ActionActuator.channelNames
BL_ActionActuator.getChannel()
BL_ActionActuator.setChannel()
