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)
* Caching of the start and end stills were just referencing the original imbuf (which got premultiplied after the caching), so as a result most of the time the premul was applied twice.
* Now the start and end stills are stored in the cache as duplicates of the original (non modified) imbuf.
they have some rotation-affecting constraint (i.e. Track To and Copy
Rotation) targetting, transforming the objects (directly, using GKEY
-> grab) becomes unreliable.
This was caused by a typo in some code checking for some
OB_NO_CONSTRAINTS under "flag" instead of "transflag"
For Constraints, there's now a working "Local" Space for Objects
without parents. This is defined as relative to the object's rotated
set of axes which results from rotation that gets set via "rotation"
transform properties.
I'm not sure whether this different behaviour between parented and
unparented objects will be too confusing (and thus require separate
settings + a round of version patching), so I'll wait until we get
proper testing from experienced riggers first.
- values were added to both the classes __dict__ as well as the internal StructRNA.
- made properties available from the type since this is where the python api assigns them:
>>> bpy.types.Scene.frame_start
<bpy_struct, IntProperty("frame_start")>
- rename RNA_struct_type_properties() -> RNA_struct_type_properties(), added RNA_struct_type_find_property()
Support for physics is done by skiping the modifiers that
don't support mapping to original mesh. This mapping is
required to report the hit polygon to the application
by the rayCast() function.
Support for graphics is done by using the same render
function that blender uses for the 3D view. This guantees
equal result.
Limitation: there is still a known bug if all these conditions are met:
- Display list enabled
- Old tex face with a several textures mapped to the same material
- no armature or shape keys
- active modifiers
In this case, only a part of the mesh will be rendered
with the wrong texture. To avoid this bug, use the GLSL
materials or make sure to have 1 material=1 texture in
your old tex face objects.
* The whole case of lib linking and pointcaches is not very well defined currently, but this fix sets the behavior of sb to the same as other physics currently.
* A proper fix will be easy to implement after a good physics baking ui is added.
1) Added a new operator to swap the order of strips within a track
(Alt-F).
This makes it possible to select two strips (or more precisely, two
islands of consecutive + selected strips) in a single track and change
the order in which the appear without needing a extra tracks to
perform the move through.
As usual, the non-overlapping rules apply, so there may be some cases
where swapping in this way is not possible without adjusting the
intermediate strips first manually. Otherwise, everything just gets
too tricky to manage deciding what adjustments should be done to the
obstructing strips to make a fit.
2) Freeing meta-strips didn't free their local data properly (i.e.
modifiers they may have had).
3) Adding strips to tracks, where the endframes for the strips
overlapped would cause problems with incorrect ordering of strips. I
still need to double-check whether evaluation works ok in this case...
* When a simulation is baked no dynamics calculations should happen anymore (even outside of baked frame range) since these can be very time consuming and baked simulations are supposed to be fast!
- metaball tessellation functuion was calculating density when it didn't need to.
- image drawing was using a float as a loop counter, in extreme cases this could cause an infinite loop.
- remove/comment unused vars.
Added new option for applyong modifiers on splines' points. This moves
tesselation point and path would be affected by modifiers which are applied on
splines' points.
* When euler-rotation F-Curves had a single keyframe only, the view
would be artifically extended to fill up to 57 (this comes from the
radians to degrees calculations) due to a combination of the bounds-
finding function enforcing a minimum separation of 1 unit between
min/max. This has now been moved to the operator-level where it gets
applied AFTER these conversions have taken effect
* F-Curves with samples only (i.e. baked F-Curves) would be ignored by
these operators. Was caused by using a poll calback that only
considered whether there were keyframes. Hopefully this is sufficient;
otherwise a hybrid poll method will be needed.
The tool-redo depends on a working undo system, so it can rewind
a step and then redo operator with new settings. When a user
disables undo, this won't work.
Now the properties for redo operator (toolbar, F6) will grey out
when a redo isn't possible.
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.
That primitives, which used ri crash blender, flips normals just after creation
and this normals flipping calls layers interpolation, but MDISPS layer
contains no data still.
Just added checking to layerInterp_mdisps.
* 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.
