http://www.blender.org/bf/rt3.jpg
It uses Material color and specular, like for the solid faces.
- Depgraph Fix for changing object layers, should re-evaluate dependencies
- Fix for setting curves to 3D by default (on adding a Guide field)
http://www.blender3d.org/cms/New_Particle_options_a.721.0.html
There's no doubt this patch had a lot of good ideas for features, and I
want to compliment Janne again for getting it all to work even!
A more careful review of the features and code did show however quite some
flaws and bugs... partially because the current particle code was very much
polluted already, but also because of the implementation lacked quality.
However, the patch was too good to reject, so I've fixed and recoded the
parts that needed it most. :)
Here's a list of of most evident changes in the patch;
- Guides support recoded. It was implemented as a true 'force field',
checking all Curve path points for each particle to find the closest. Was
just far too slow, and didn't support looping or bends well.
The new implementation is fast (real time) and treats the paths as actual
trajectory for the particle.
- Guides didn't integrate in the physics/speed system either, was added as
exception. Now it's integrated and can be combined with other velocities
or forces
- Use of Fields was slow code in general, made it use a Cache instead.
- The "even" distribution didn't work for Jittered sample patterns.
- The "even" or "vertexgroup" code in the main loops were badly constructed,
giving too much cpu for a simple task. Instead of going over all faces
many times, it now only does it once.
Same part of the code used a lot of temporal unneeded mallocs.
- Use of DerivedMesh or Mesh was confused, didn't work for Subsurfs in all
cases
- Support for vertex groups was slow, evaluating vertexgroups too often
- When a vertexgroup failed to read, it was wrongly handled (set to zero).
VertexGroup support now is with a name.
- Split up the too huge build_particle() call in some parts (moving new code)
- The "texture re-timing" option failed for moving Objects. The old code used
the convention that particles were added with increasing time steps.
Solved by creating a object Matrix Cache.
Also: the texture coordinates had to be corrected to become "OrCo".
- The "Disp" option only was used to draw less particles. Changed it to
actually calculate fewer particles for 3D viewing, but render all still.
So now it can be used to keep editing realtime.
Removed;
The "speed threshold" and "Tight" features were not copied over. This
resembled too much to feature overkill. Needs re-evaluation.
Also the "Deform" option was not added, I prefer to first check if the
current particle system really works for the Modifier system.
And:
- Added integration for particle force fields in the dependency graph
- Added TAB completion for vertexgroup names!
- Made the 'wait cursor' only appear when particles take more than 0.5 sec
- The particle jitter table order now is randomized too, giving much
nicer emitting of particles in large faces.
- Vortex field didn't correctly use speed/forces, so it didn't work for
collisions.
- Triangle distribution was wrong
- Removed ancient bug that applied in a *very* weird way speed and forces.
(location changes got the half force, speed the full...???)
So much... might have forgotten some notes! :)
-- calling mesh.getFromObject(obj) with mesh object now also
copies material properties
-- mesh.quadToTriangle() takes a parameter to duplicate both
Ctrl-TKEY and Shift-Ctrl-TKEY actions
-- assigning None to mesh.verts "clears" the memory allocated
to the mesh (equivalent of Mesh.New(), but on an existing
mesh)
-- exception handler message for mesh.faces[i].uv = [..] more
clear (uv attribute only accepts tuple, not list)
-- fixed bug for meshs with deformed verts when deleting verts
(deformed verts deleted and repacked correctly now, I think)
bug #3367 reported by Chris Want (thanks): ob.mat documentation was
wrong (was not updated); that attribute returns the world space matrix,
not the local one.
a strobe effect synced exactly to a beat, for example, by using non-integer
values.
Is it just me, or are there recently a lot of crashes in sequencer when
using audio strips?
In the NKEY flying panel, you can set "Strobe" to something other than 1
for only displaying each nth picture of the strip. You know the effect
from movies :)
(I put this into the NKEY panel rather than as a effect because effects
only affect single frames (?) while this rather has to do with the
timing... like "Reverse")
- don't get too excited
- allows you to get armatures from a scene
- makeEditable()/saveChanges() puts the armature into out of editmode (pythonically)
- Armature.bones is a dictionary that contains all the bones in the armature and can be iterated
- getters are available for:
name,
roll (dictionary) keys are BONESPACE, ARMATURESPACE
head (dictionary) keys are BONESPACE, ARMATURESPACE
tail (dictionary) keys are BONESPACE, ARMATURESPACE
matrix (dictionary) keys are BONESPACE, ARMATURESPACE
weight
deform_dist
subdivisions
options (list of constants)
parent
children
Setter work only in editmode. Some are not fully implemented.
Type class is embedded in the module. This means the construct is called as follows:
Blender.Armature.ArmatureType()
import Blender.Armature as Armature
arm = Armature.Get('myarm')
for name, bone in arm.bones.items():
...print name, bone, bone.matrix['ARMATURESPACE']
more documentation is forth coming. This is an alpha for this api.
remaining effect type, it didn't make much sense to leave things
implemented in two separate files. Changes include:
* two bug fixes (the getChild() and getMat() methods were using floats
instead of shorts)
* performing clamping on input values
* implementing attributes using tp_getset
* merging Effect and Particle functions: the Particle module exists in
name only, with the Particle.New() and Particle.Get() functions
remaining for backward compatibility (they are in fact identical to
Effect.New() and Effect.Get() functions)
* update of doc/Effect.py (including remove all old references to wave
and build effects)
Deleting a shape key object could crash, when ipowindow open and showing an
active key.
Also: patch from tracker to increase limits of buttons for background image
offset.
Error in BLI_array_randomize(), an unused call in Blender until the
Build Modifier was added. It did a weird modulus I don't really grasp...
somehow that caused the bug (create a corrupt mesh). But why? Dunno...
Selecting Edges in "Cut Away View" (ALT+B) did not work yet for wire view.
Solved it by calculating the closest coordinate for mouse to edge, and
check for that position if it's visible or not.
DXF: when an error message occurs during read, the main call returned
without clearing the used global vars... causing crash on calling again.
ALso: added warning when trying to assign a taper or bevel using Object
itself. (report from opengl tracker :)
Repeated presses of the F* key to go to a buttons context will
now cycle through the sub-tabs within. For example, when at
a different buttons window context, pressing F7 twice will cycle
through to the Physics buttons tab, pressing F10 three times
will cycle through to the Sound buttons tab, etc.
Right after leaving Armature editmode, and entering posemode, the active
bone was not selected (when only the head or tip was selected). This caused
a confusing display of an active but not selected Bone... and not proper
behaviour of UI (buttons) and inserting keys.
Fix#3348
Mirror Modifier, button "Merge Limit" didn't react on left/right click.
- Armature editmode, x-axis mirror edit, didn't mirror alt+s scaling of
B-Bones
ALso: found out that alpha drawing for Envelope Bones in editmode wasn't
set properly.
Also fixed signature to const char* to indicate which parameters can be changed
to make it a bit safer, because constant strings are passed into this function
and changing them caused a crash.
so that it resides in the Effects module instead, with the intent of
soon merging Effect.c and Particle.c into a single file (and somedat
removing references to the Effects.Particle submodule)
He noted that static particles don't work with force fields yet, and
added a fix for it. This however didn't work for the depgraph yet, and
didn't correct the static particle's local space to world coordinates for
the fields. Nevertheless, while reviewing this small patch I thought it
would be fun to add now.
So: static particles now update realtime on forcefield relations. Warning
for potential slowdowns! Also note that work on the real particle patch
still has to be done... something I really will do, but in time. To get
particles correctly integrated in the animation system, quite some new
development has to be done still.
While using automatic IK, a pending redraw event could draw the buttons
window again, reveiling the temporal IK buttons. Using them, after grab,
caused a crash.
Also: noticed that the undo push for transform is called too early, so it
saves the state before 'special_after_trans' was called.
Also: in editmode armature, changed shift+A "Bones" in "Bone".