* Removed some fields from struct SculptSession:
- Fields drawobject, projverts, and previous_r were completely
unused
- Field `ob' was really unnecessary, changed sculpt functions
to pass the object rather than the SculptSession
This removal of `ob' from SculptSession should should make it a little
easier to continue generalizing paint/sculpt functionality.
There should be no visible changes from cleanup.
More problems with Undo and Render Slots (Image editor)
- Undo storage for operator is now back, but only when new
buffers were added (not when viewing existing)
- A real bug: On undo/redo, the stored buffers were never
retrieved, but always freed entirely.
Note however that when you undo back to a state before you
rendered (or added slots), the render buffers that didn't
exist back then also get freed. A redo doesn't bring it back.
Fixed view selected code. Made MDisps->disps use the
special allocation library I wrote as a
temporary fix to MDeformGroup->dw problems.
Why was the vgroup solution reused? It's really slow,
and its hard to tie in something like mempool or memarena.
The hackish allocator I wrote really needs to go, eventually,
or be folded into guardedalloc.
Also fixed a customdata bug with modifiers.
Layer height used to be controlled with brush radius, quite confusing decision.
Added new property for brushes - height for adjusting affectable brush height
(it could be not only layer height in the future).
Was trying to free audio data from sequencer strips that don't even have audio. Corrected the error in several ways so this will definitely not happen again :-)
- 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.
* Effecting particle properties with textures was possible in 2.49,
but not in 2.5 anymore.
* Now particles have their own textures (available in texture panel
for objects with particle systems), which are totally separate from
the material textures.
* Currently a basic set of particle properties is available for
texture control. Some others could still be added, but the whole
system is not intended as an "change anything with a texture" as
this kind of functionality will be provided with node particles in
the future much better.
* Combined with the previously added "particle texture coordinates"
this new functionality also solves the problem of animating particle
properties through the particle lifetime nicely.
* Currently the textures only use the intensity of the texture in
"multiply" blending mode, so in order for the textures to effect
a particle parameter there has to be a non-zero value defined for
the parameter in the particle settings. Other blend modes can be
added later if they're considered useful enough.
-> 2.50
Actionified ShapeKey IPO-blocks (i.e. "Shape Key Actions") would have
an action channel with the hardcoded name, "Shape", and this action
would be assigned to Object level (although ShapeKey blocks had their
own IPO-block slot, only Objects could have actions, so actionifying
ShapeKey IPO-blocks would wrap a ShapeKey block's IPO's to an Object-
level action).
Hence, the path conversions code would wrongly interpret this action
channel as referring to a Pose Channel instead, thus creating some
invalid paths with a 'pose.bones["Shape"]' prefix wrongly getting
tacked on. To ensure that the converted animation can work out of the
box, a 'data.shape_keys' prefix is now used instead so that these
actions can still be Object-rooted while still being able to correctly
control the Shape Keys. This is because there's no easy way to
identify and then shift such action from Object-level to ShapeKey-
level within the conversion code. The consequence though is that such
converted ShapeKey actions CAN ONLY BE USED THROUGH OBJECT LEVEL (i.e.
via Action NOT ShapeKey editor).
Secondly, the Action/ShapeKey editor version patching code has been
modified so that if a ShapeKey editor view was active when loading an
old 2.4x file, the action gets cleared from the view. This is because
of this didn't make semantic sense: the ShapeKey editor is for
ShapeKey-rooted actions, while the Action Editor is for Object-rooted
actions. The converted files though let Object-level actions be shown
in either one.
Patch #25901 by Tobias Oelgarte.
Bone transformations would be converted back and forth between different
representations when changing modes, which due to numerical errors could
lead to bone transformations slowly changing as you edit the armature.
Now the editmode head, tail and roll values are stored in bones and used
directly when entering edit mode. Head and tail were already there but
now we ensure they are the exact same value, roll was not yet there, so
we have a version patch for it.
The sub version was incremented to 1 for the version patch.
Migrating "redraws" settings from TimeLine view data to per Screen.
The options are now still shown in the TimeLine "Playback" menu
though.
This means that whatever redraw settings you set in a TimeLine editor
will be used throughout a screen (i.e. editor layout) to determine
which editors will get updated during playback, instead of only
certain editors doing certain things at vague times.
---
Also, I moved some version patches pre 2.56 version bump into a
version-check for 2.56. These must've been missed when doing the
release...
.blend1 etc backups.
Proves again that lazy coders only make bad code :)
Implementation note:
The filewindow now recoginizes .blend version backups as
a special type, so filtering for .blend files themselves
ignores it. However, they're recognized correctly as valid
.blend files, and draw an icon as .blend file when filtering
is off. Can become a distinct icon if we want...
oldbump -> original
newbump -> compatible
*new* -> default (3tap)
*new* -> best quality (5tap)
the latter two have an option to apply bumpmapping in
viewspace - much like displacement mapping
objectspace - default (scales with the object)
texturespace - much like normal mapping (scales)
Texture nodes, the Image node didn't get initialized on load.
This caused the node to refuse accepting a new Image if a
file couldn't be found on saving.
* Viscoelastic springs between the fluid particles can simulate all kinds
of viscous and elastic substances, such as jelly and honey. This is
achieved by creating springs dynamically between neighboring particles
and adjusting their rest length based on stretching/compression.
* This nearly completes the currently intended functionality for particle
fluids. The last missing thing is a surfacing extraction algorithm,
which is needed for a proper representation of a sph fluid.
* I also cleaned up and renamed some of the fluid parameters to make the
ui a bit easier to understand.
* One addition to the patch is an option to use "initial rest length" for
the springs, which uses the lengths between the particles at the time of
spring creation as the spring rest lengths instead of interaction radius/2.
This makes the fluid keep it's original shape better (good for very
viscoelastic materials), but can create large density differences inside
the fluid (not really physically correct for a fluid).
* Viscoelastic springs are stored in point cache as extra data.
* Not strictly necessary right now, but better for future.
* Struct data (only boids at the moment) is now written as structs (with dna) so they work between 64 and 32 bit machines too.
* I've getting bad feelings about the point cache index_array for a while (cause for this bug too), so from now on memory cache uses a simple binary search directly on the index data to handle queries to specific data points.
* This is a bit slower than just checking from a dedicated array, but it's much less error prone, uses less memory and makes the code more readable too, so it's not a tough choice.
* Renamed children to "simple" and "interpolated" as this is
easier to explain and more descriptive than "from particles"
and "from faces".
* Also shuffled the child ui around a bit to make it clearer.
* Child seed parameter allows to change the seed for children
independent of the main seed value.
* Long hair mode for interpolated children:
- Making even haircuts was impossible before as the child
strand lengths were even, but their root coordinates were
not similar in relation to the parent strands.
- The "long hair" option uses the tips of the parent strands
to calculate the child strand tips.
* Hair parting options:
- Hair parting can now be calculated dynamically on the fly
when in 2.49 there was a cumbersome way of using emitter mesh
seams to define parting lines.
- For long hair parting can be created by a tip distance/root
distance threshold. For example setting the minimum threshold
to 2.0 creates partings between children belonging to parents
with tip distance of three times the root distance
((1+2)*root distance).
- For short hair the parting thresholds are used as angles
between the root directions.
* New kink parameters:
- Kink flatness calculates kink into a shape that would have
been achieved with an actual curling iron.
- Kink amplitude clump determines how much the main clump value
effects the kink amplitude.
- The beginning of kink is now smoothed to make the hair look
more natural close to the roots.
* Some bugs fixed along the way too:
- Child parent's were not determined correctly in some cases.
- Children didn't always look correct in particle mode.
- Changing child parameters caused actual particles to be
recalculated.
* Also cleaned up some deprecated code.
All in all there should be no real changes to how old files look
(except perhaps a bit better!), but the new options should make
hair/fur creation a bit more enjoyable. I'll try to make a video
demonstrating the new stuff shortly.
- convertblender.c, remove assignments to unused vars.
- readfile.c, fix 2 possible crashes. null pointers were being checked for then used later without checking.
- space_graph.c, use switch statement for automatic color assignment rather then a float array.
This commit partially fixes the problems with Shapekeys from older
files, as seen from the Regression suite (relative.blend and
dolphin.blend in particular).
In older files, keyblock->slidermax was never truly set to 1.0 even
though the UI may have shown such a value (which was bizzarely being
sourced from somewhere else). Hence, after loading the files in 2.5,
the shapekeys wouldn't animate, as the value would get clamped between
0 and 0.
To fix this, I've added a version patch which corrects these
situations in old files, and I've adjusted the slider-RNA code so that
it is not possible to set up such clamping anymore.
TODO:
The fixes detailed here only make it possible for these files to work
again in 2.5. However, I haven't been able to find a way to get the
files to actually work in 2.5 without manually changing the active
shapekey (per object) after loading the files with these patches
applied. Possibly it's just some depsgraph magic needed, unless
there's still some other evil voodoo in the shapekey code
