This commit is based on the patch & cool design work of Matt. It includes
the new Lamp drawing style, and replaces the Object center dots with a
similar styled OpenGL drawn dot.
Important side-note is that removing the old glDrawPixels() for centers or
lamps will not only make Blender faster, but also prevents crashing on a
couple of cheaper 3d cards (as reported for S3 and Intel on-board cards)
Notes:
- The new default only draws Object centers when selected or active. If
you like to see them always, use the View Properties Panel. You can also
save that in the .B.blend
- The size for centers (and lamps) is in the User settings "View & Controls"
- Unselected Lamps, and their offset lines from zero Z, are drawn in a new
Theme color
Changes and additions in Matt's patch:
- Lamps and centers are drawn fixed size, in pixels. Also the 'sun' lamp
draws screen aligned now.
- Center dots now also draw in blue to denote Library linkage or to show
that an Object has been linked to other scenes.
- When objects are empty (no vertices) they will always draw a center dot.
Otherwise these objects would never be selectable anymore!
- Added theme setting for center size, and initialization
- Removed the old redundant code for drawing centers
- Cleanup of drawing routines, made center dots faster
- Started removing calls to glBlendFunc(). Regular alpha drawing should
become standard, and the (very) occasional exception should return this
to default after usage.
causing Blender to crash. (reported by Levon, thanks!)
Bugfix: InfoWindow, pulldown menu said "Dump 3D window", whilst this can be
any window type... renamed it to "Dump Subwindow" next to "Dump Screen".
marker wasn't on the first or last possible position. Caused by clipping.
As bonus; added Cardinal interpolation option too, which is just that
little bit different! (Cardinal goes through the controlpoints, bspline not)
curves. On sharp 'peaking' curves the handle was calculated
using both X and Y distance. This could result in overshooting.
New code only evaluates the X distance, resulting in much more moderate
sized handles.
Thanks Gabio for the demo file!
us.id when objects were destroyed but not always incrementing when
created. The intent of modifying us.id is to make Python a "user" of the
data so it persists even when it is deleted from Blenders UI. The original
commit was unintentional but Ton thought the idea was OK.
- bug: posemode, bones were drawing names and axes even when hidden
- bug: using softbody guides actually worked on themselves, causing
an infinite loop
- feature: when a pose/bone is completely locked for transform, a grab
will change into rotate by default.
Well, it already worked a bit, but without weight options or edge
stiffness. You now can set the weights using the "Properties" Panel in
the 3D Window (allows multiple selections too) or with Wkey in Edit Mode.
Bezier curves have this too.
NOTE: Lattice SoftBody Goal created yesterday won't work anymore!
I've had to recode weight support for Nurbs Points, using a new weight
variable... this because the existing W variable was in use for Nurbs
already. Also Lattices have this new Weight variable, so the code is nice
uniform. Sorry for the artists who already created complex Lattices... :)
NOTE2: Surface Objects don't support edge stiffness yet
NOTE3: I've removed ancient screen coordinates from the Bezier struct,
which makes - even with added weight and padding - the struct smaller!
Demo file:
http://download.blender.org/demo/test/2.40/softbody_curve_lattice.blend
Animating detailed clothes with softbody becomes messy, so now we'll
try it this way. :)
It simply uses the W (weight) value, as already available in each Lattice
Point. Only had to make it editable;
- NKey panel
- or press W in editmode
Further there's a minimalistic W button in the softbody Panel!
Hess.
In a comment on maillist I already mentioned a weird 0.5 in the code,
which I added to ensure correct rounding to integer frame numbers.
With a variable step size however, this won't work properly. You could
see it in the patch, because the ghost steps were animating.... they
should remain frozen, looks much nicer then. So I've added some fmod
voodoo here.
Vertex-parenting a forcefield to a softbody caused eternal loop :)
It is partially because of the timing system (=weak) but actually also
because derivedmesh calls could also not build meshes all the time!
The locality is restricted to action or user-transform only. Or as it goes
in the code now: by setting a constraint local, it executes the constraint
before it calculates the influence of Action or user transforms.
ALso note that this works in Evil Eulerians. Meaning that when you only
want to copy the X,Y or Z compenent of a euler, it can give unpredictable
results when the other euler values are set, this because euler axis
rotations work on top of each other.
Previously, using the "Stride Bone" tried to get that Bone motionless on
the path by correcting the internal time of the Action. This however caused
too many problems, especially with irregular walks.
The new system also tries to keep the Stride Bone motionless, but this by
moving the entire armature, and not changing the timing of the Action.
Give much nicer results. :)
To make editing Strides easier, I've added a new option in the NLA
panel to disable the path. This way you can quickly switch to editing the
action itself (keying the stride bone) and viewing the result.
- update for the old mathutils rewrite
- update for some other methods ive added
- added explaination of wrapped data
- added a .css file for epydoc gives nice blender/python colors :?
- Bone Ghost drawing now skips axes and names
- "Snap to cursor" now works for parent-less bones in PoseMode
- Prevented assigning in buttons of negative zero (was confusing)
- Copy Location Constraint didn't update Object when it was copying from a
Bone
- Deleting bone in editmode, and connecting bones crashed due to evaluation
of deformation code (only allowed for pose).
on top of each other. Was 100, which gave noise like this in this image;
http://www.blender.org/bf/hairnew.jpg
Made it 200, which solves it for a million hair polygons;
http://www.blender.org/bf/hairnew1.jpg
Also note that hair renders go much faster and better if you insert a real
solid head in it, that will prevent hairs on the back to be inserted in the
buffers. ANd don't make the head Ztransp!
I've been going over the zbuf.c code, which is indeed very ancient,
with a load of old optimizing and redundant code in use.
Added more 'modern' Span support, which fills per face two arrays
with the scanline information in it. That way you can zbuffer a quad in one
run as well. It was also exactly that code that's copied all over in zbuf.c
For now, to prevent issues for the release, the 'render a quad in 1 run' is
only in use for the strand render. Tests reveil a speedup of about 33%.
Will work on this recode later... which would also result in making zbuf.c
threadsafe.
And: bugfix #3398
When using the new 'render emitter' for particles, the orco array for
particles was accidentally used by mesh too.
doc;
http://www.blender3d.org/cms/Hair_Strand_Rendering.722.0.html
- added width control for strands
- made tangent (anisotropic) render an option
(so you can render strands more solid, like metal/wood)
Also:
- ALT+A anim playback with static particles made cursor flashing
in case the paste buffer+length of text was bigger than MAXTEXT ->
fixed this, also a error is shown to the user now. editfont.c needs
still some cleaning but will discuss about this with kaito and intrr.
"Additive" Guides. See also:
http://www.blender3d.org/cms/New_Particle_options_a.721.0.html
This Guide type uses the falloff distance to also define how much the
particle (or hair strand) goes over the path, allowing to create local
extremes, or only local particle generating or hairgrowth. Nice for
spiky haircuts!
Note that the current default generates particles based on the original
amount of vertices and faces, this for vertex group support (which is not
subdivided with modifiers). That means that particles generated on
subsurfed faces still have minor approximation errors.
Note for DerivedMesh users; I've added a new API call:
float *mesh_get_mapped_verts_nors(Object *ob);
Which returns an array of 2 * 3 * float size, containing the vertices and
normals, deformed and subsurfered, but only the original me->mvert amount.
Works in all non-editmode cases.
Is in use now for vertex/weight paint and particles.
