Fixed bug #20620, "VertColors and Flat/Soft imported from 2.49 are wrong
(MultiRes)" reported by Manuel R.
* Added function to load level-0 vertex colors
* Added function to load level-0 face flags
* Warning: the 2.5 multires modifier doesn't support multires vertex colors
or multires face flags; that data will be lost if you import it into 2.5.
also added note that adjusting bone radius changes the parent bone for connected child bones, and fix typo on failing to read startup.blend (both pointed out by MikeS on IRC)
- no rotation resulted in NAN location.
- subtraction of pivot done in wrong order made the constraint give odd results when rotating on more then 1 axis.
* The SPH fluid particle algorithm was implemented a bit wrong. This problem could for example result in the fluid moving sideways after being dropped straight to a horizontal collision surface, a very big no-no as far as real world physics are concerned!
* After some extensive code shuffling the algorithm is now much more true to the paper it was implemented from, and more importantly now the physics should be correct too!
* The main thing was that fluids calculations can effect many particles simultaneously, so just a single loop through all particles can't work properly. As a side note this also means that the actual fluid algorithm can't be made threaded :(
* To make things work I also had to reshuffle some general particle physics code, but there should be no functional changes what so ever to other physics types, so poke me immediately if something strange happens.
Note to users: these changes will most probably effect the way previously done sph fluid simulations look, so some parameter tweaking will be needed to get things back looking the way they were.
this is a can of worms, at the moment blender depends on broken behavior for metaballs:
find_basis_mball() can return a metaball object that fails a is_basis_mball() check which makes this logic very confusing (added note about this in mball.c).
Metaballs needs a refactor however at least make drawing fail consistently,
For wire draw is_basis_mball() wasn't being checked, for solid drawing it was (hence the strange wire frame).
For now the motherball needs to exist in the main scene else it wont work.
* Keyframing operators now use the reports system for displaying all its error messages.
- The benefit of this is that users no longer need to check the console for error messages if keyframing fails.
- Unfortunately, reports are not currently viewable in any space/view in Blender, so...
* Added a temporary operator (UI_OT_reports_to_textblock), which can be accessed in the UI from the button which appears in place of the icon when more than one report exists. This dumps the current list of reports to a textblock "Recent Reports", from which they can be viewed.
This isn't really nice, but at least we now have a way to view these again, which makes debugging some things a pain.
* Bugfix #24606 - when trying to add keyframes to F-Curves with F-Modifiers already which alter the curve significantly enough that the keyframes will have no effect, there are now warnings which aim to alleviate any confusion.
Also use const char in many other parts of blenders code.
Currently this gives warnings for setting operator id, label and description since these are an exception and allocated beforehand.
The main reason to have this is so renders can be scripted to write to a specific file without having to do annoying tricks like set a dummy start/end frame range, render an animation and work out the current frame image will be written to, then rename after rendering.
Also made some 'char *' args into 'const char *'
Found and fixed a few problems here, but strangely I don't recall seeing any of these a few months ago when this conversion (probably last) worked well ...
- VBO UV Edge display wasn't allocating a large enough array for drawing.
- VBO UV Edge drawing was using an edge flag with faces.
- notifier for modifiers updating the UV window.
Now object_apply_mat4() can be used as the reverse of object_to_mat4().
Noticeable result is fly mode and 'Apply Visual Transform' dont jump when deltas are used, also means setting matrix from python works as expected.
* In addition to fixing the memleak it's much better to always copy the voxeldata to the texture. Smoke data can change at any time due to some changes, so we can't depend on that data.
* Thanks to MiikaH for finding this!
Transforming strips into locked tracks meant that they were not unlocked properly (i.e. they stayed as temporary "meta" strips). This is now taken into account as part of the step which checks if there's any space for them in those tracks.
NURBS surfaces always used resol{u,v} from spline and never used curve's render resolutions.
Now, if curve's render resolution is non-zero then it'll override resolution for all
splines when rendering (in needed direction only, ofcource).
* Particles didn't want to stay cached, even if there were no actual chages.
* Particle states weren't set properly for times before actual simulation start.
- object updates were not being flushed, so children weren't updating.
- apply the matrix relative to the parent, added this as an option to object_apply_mat4() which allows assigning the worldspace matrix in python without worrying about the parent.
Image editor & texture properties, add new Image, inits 'start' now
to frame 1 for sequences.
Added triple-X warning in Image Open operator, it uses SpaceImage whilst
it can be called from other editors. Code is safe but not correct.
- Revert of my old change in curve->mesh conversion
- Do not ignore DL_POLYs for surfaces -- they will never be filled,
but ignore them for 2d curves -- they'll be filled with INDEX3 parts.
