ED_view3d_init_mats_rv3d was calling glMultMatrixf() which was mostly harmless but could also lead to confusing bugs (2 reported previously).
Looked into this and every call to ED_view3d_init_mats_rv3d except for object drawing, doesn't need this so made a second version of ED_view3d_init_mats_rv3d - ED_view3d_init_mats_rv3d_gl which does the matrix multiplication, remove confusing checks in selection code.
mouse coords would with cont. grab would wrap at short.
use mouse coords as int rather then short.
this problem still happens on linux because of XTranslateCoordinates
1. Removed pinning, at least until after trunk
reintegration (it's a usefull feature, but
incomplete).
2. Ripped out the subclassing code I originally
wrote so bmesh would be more usable for modifiers
(I ended up improving CDDM instead).
3. Inlined some of the macros in bmesh.h, still need to
do the macros in bmesh_operator_api.h.
4. Removed the BMESH_ITER_*** macros (except for BMESH_ITER_INDEX).
They were too clunkly to be worth it.
from Andy Braham (andybraham)
This adds support for empties to reference images and draw in the 3D view.
Modifications from the original patch.
- use an empty draw 'image' type
- use image aspect ratio for non-square-pixels
- when the image is not found, still draw the frame.
the same, but big changes have happened both on the outside and on the inside.
New UI:
* The old parameters were quite true to the underlying algorithm, but were quite obscure
from a users point of view. Now there are only a few intuitive basic parameters that
define the basic fluid behavior.
** By default particle size is now used to determine the interaction radius, rest
density and spring rest lengths so that it's easy to get stable simulations by simply
emitting particles for a few frames and adjusting the particle size (easy when the
particle size is drawn) so that the fluid appears continuous (particles are touching
eachother).
** Stiffness - in reality most fluids are very incompressible, but this is a very hard
problem to solve with particle based fluid simulation so some compromises have to be
made. So the bigger the stiffness parameter is the less the fluid will compress under
stress, but the more substeps are needed for stable simulation.
** Viscosity - how much internal friction there is in the fluid. Large viscosities also
smooth out instabilities, so less viscous fluids again need more substeps to remain
stable.
** Buoancy - with high buoancy low pressure areas inside the fluid start to rise against
gravity, and high pressure areas start to come down.
* In addition to these basic parameters there are separate advanced parameters that can
either be tweaked relative to the basic parameters (or particle size) or defined
independently.
** Repulsion - the stiffness parameter tries to keep the fluid density constant, but this
can lead to small clumps of particles, so the repulsion keeps the particles better
separated.
** Stiff viscosity - the normal viscosity only applies when particles are moving closer to
eachother to allow free flowing fluids. Stiff viscosity also applies smoothing to
particles that are moving away from eachother.
** Interaction radius - by default this is 4 * particle size.
** Rest density - by default this is a density that the particles have when they're packed
densely next to eachother.
** Spring rest length - by default this is 2 * particle size.
* There are also new options for 3d view particle coloring in the display panel to show
particle velocity and acceleration. These make it easier to see what's happening in the
fluid simulations, but can of course be used with other particles as well.
* Viscoelastic springs have some new options too. The plasticity can now be set to much
higher values for instant deletion of springs as the elastic limit is exeeded. In addition
to that there is an option to only create springs for a certain number of frames when a
particle is born. These options give new possibilities for breaking viscoelastic fluids.
New in the code:
* Most of the fluids code is now thread safe, so when particle dynamics go threaded there
will be a nice speed boost to fluids as well.
* Fluids now use a bvh-tree instead of a kd-tree for the neighbor lookups. The bvh-tree
implementation makes the code quite a bit cleaner and should also give a slight speed
boost to the simulation too.
* Previously only force fields were calculated with the different integration methods, but
now the fluid calculations are also done using the selected integration method, so there
are again more choices in effecting simulation accuracy and stability. This change also
included a nice cleanup of the whole particle integration code.
As the internals are pretty stirred up old particle fluid simulations will probably not
work correctly straight away, but with some tweaking the same level of control is still
available by not using the "relative versions" of the advanced parameters (by default these
are not used when loading old files).
ASCII lookup table wasn't being freed when when the rest of the glyphs were.
Also found own bug where mesh stat text was using wrong sized array (char[3] as char[4]).
Very bad crashing in using "Not AA fonts" and drawing length info
on EditMesh. This uses the call BLF_draw_ascii() which apparently
corruptes then badly. Disabled the call for now, and wait for fix.
In the course of testing, added proper strlen storage for draw
in this code.
Added strlen
Fixed join meshes, and an annoying modifier bug (making modifiers
not work in editmode). Also fixed a tesselation bug.
Also got edge slide to work right, yay! Dunno why I couldn't get
it working right before; took me twenty minutes to fix.
most local modifier,GPU,ImBuf and Interface functions are now static.
also fixed an error were the fluid modifier definition and the header didnt have the same number of args.
- use NULL rather then 0 where possible (makes code & function calls more readable IMHO).
- set static variables and functions (exposed some unused vars/funcs).
- use func(void) rather then func() for definitions.
- modifier code was using sizeof() without knowing the sizeof the array when clearing the modifier type array.
- use BLI_snprintf rather then sprintf where the size of the string is known.
- particle drawing code kept a reference to stack float values (not a problem at the moment but would crash if accessed later).
also minor functional changes
- OBJECT_OT_make_links_data() type property is now assigned to the operator property (so popup menu can find it)
- removing BG image now returns cancelled if no image is removed.
Use object's displists for storing deformed tesselated curve. Was unable to
totally get rid of curve's displist because of how texture space is calculating.
Child-of constraint issue: on adding, it wasn't checking owner
correctly for Bones, resulting in a constraint working in wrong
space; it looked as if transform was applied double when moving
the object. Only adding via Py API went wrong btw.
Also found a silly check for drawing constraints, which caused
constraint initialization to happen for every object on every
redraw!
Implementation note: con->flag CONSTRAINT_SPACEONCE was only used
for child-of constraints in Bones, so I've patched it on file
reading to always set the flag. Marked with XXX, so it can be
removed one day. Now at least things get corrected well for
imported armatures.
