Went through and commented all the code in ipo.c, tidying up formating and coding style in places, and also rearranging to have a more logical order in some places. There shouldn't be any major issues arising from this commit.
removed calc_curve_subdiv_radius(), curve radius is now calculated the same way as tilt.
Added radius interpolation menu matching tilt interpolation, needed to add "Ease" interpolation type to keep 2.47 curves looking the same.
this way each edge/segment gets the same number of points matching the resolution value.
before, a nurbs curve would have the same number of points no matter if it was cyclic or not.
This will make slight changes to objects on an animated path, but only noticable if the path has a low resolution.
bug [#11744] NurbCurve Radius incorrect - now dosnt show bad results with order 4 on non-cyclic curve.
* when check_valid_nurb_u/v fails, no curve is allocated or drawn.
* knotsu/v could be NULL but some functions didn't check for this, make sure this is checked for everywhere.
* The interface didnt change check the order when the bezier u/v flag was set, added functions clamp_nurb_order_u/v that takes into accound the number of points and the bezier u/v flag.
the problem was that the buttons would use the first nurb if there was no 'lastnu', but the makeknots function only checked for lastnu. this meant the knots would not get re-allocated on
values would be written outside the array.
added checks for a nurbes orderu being larger then pntsu.
This has the same effect as the curve having only 1 point. (its display list is not generated
but it is still added but a dummy displist with zero points is made)
memcpy was also being used where the memory overlaped (probably worked in most cases but this is incorrect and valgrind complained), use memmove
instead.
This time is was due to different accuracy of floating point computation,
now it uses does a comparison a bit different to avoid this.
Also changed the vectoquat function to be threadsafe.
* Most were uninitialised vars
* Fixed whitespace in a few places
* The change I made in rendercore.c -> do_bake_shade() was for an uninitialised var, but I hope it does't cause any rendering errors...
Just a quickie feature I needed here at work- the previous linear
interpolation of tilt in curves can give nasty pinching problems
when trying to do flowing curves like a ribbon. This commit lets
you choose the interpolation type, between Linear, Cardinal, and
BSpline. The code was already set up for it pretty easily, mainly
needed to make the choice visible to the user.
Example:
http://mke3.net/blender/devel/etc/tilt_interp_types.png
Works on selected curve 'lines', menu in 'curve tools' panel in
edit mode.
This commit refactors curve selection system to use certain curve selections
functions that encapsulate setting of selection flags. New function to select
adjacent control points was introduced too. Refactoring made it possible to
simplify certain existing selection functions quite a bit.
New functionality was delivered as well. Select more/less works now with NURBS
as expected. Also two new curve selection functions were added: Select Every Nth
and Select Random.
See http://wiki.blender.org/index.php/BlenderDev/Curve_Selection_Tools for
further information.
curve - added curve_type() to return the curve type
BPyModule & gen_library - works with text3d now, can also make new text3d through bpy.curves.new
Added Draw.Label() so scripts can draw can using freetype.
widgetwizard - use Draw.Label
(saved files cannot read back, they crash).
The implementation of this option was plain accident that it even worked
once... you cannot use the API in blender that way.
Log again:
Log:
1)
Bugfix: Beziers in curve didn't calculate the tilt values correctly for
the endpoint and not for all handle types. That way deforming curves didn't
extend the tilted deform either. (IRC report by Jahka)
2)
If you setup a Proxy for Armatures, the protected bones now have an error
pupup for buttons and for some of the tools in 3d window (constraint edit
mostly).
Also the Bones Panel shows a note when the bone is not editable.
really cool to get this working solidly, but there are many potential problems with the
triangle face creation across the flat surfaces, especially when there are holes inside
the curves. Maybe this could be a fun project for someone better at this than I? :)
Taper object curves still cause similar problems...
* Made the curve radius affect the 'Nsize' curve normal drawing too, so you don't need a
bevel to see the value.
They're getting rare, but here's another bugfix from issue since NaN days:
Orco texture coordinates for surfaces didn't work *at all*!
(Try 2 nurbs spheres in 1 object). Fixed!
but they got this case! :)
Bug was that for autohandle, the previous position of handle was used for
calculating the position too, which I really don't remember why... (that
is code from 10 years ago). Problem with that approach is that extreme
changes in handles don't go correct immediately, but need to itterate a
while. Or even worse, can give NaN values, resulting in this:
http://www.blender.org/bf/ipobug.jpg
Now the handle points are fully recalculated, as it should.
Creating texture coordinates for Curve bevels didn't allocate a correct
sized memory block when both U and V directions of a bevel are circular.
This will also fix "UV orco" for such curves (like donut shapes).
front/back is selected), the UV coordinates for curves should also be
corrected.
This commit re-uses the same code as for Nurbs, to make sure UV coordinates
wrap around nicely.
BUT! I've noticed that Daniel's commit of august in this code actually
broke this UV correction... in his craze to cleanup old code, he missed
the actual functionality. Meaning that in 2.40 and 2.41, "UV orco" texture
coordinates wrap around ugly in Nurbs Surfaces, something that was fixed
in NaN days.
Got no time for tracker now... but I'm sure it's in there! :)
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!
- "Flush" is now split into two seperate Alignment modes "Flush" and
"Justify":
- Justify does exactly the same as a normal word processor's justify
function does, and in addition, it uses *whitespace* instead of
*character spacing* (kerning) to fill lines. Much more readable.
- Flush is pretty much the old Blender "Flush" mode - and as such it
uses character spacing to fill lines. Just as Justify, this only
works with at least one textframe.
- Underlining for text objects. Not a lot to explain. New button "U" in
the editbuttons, and CTRL-U as hotkey toggle underlining for newly
entered characters or for the selection, just like CTRL-B/CTRL-I do for
bold/italic.
Underline height (thickness) and Underline position (vertical) can be
set in the editbuttons.
Implemented as CU_POLY polygon curves.
- The B, U and i buttons (and the corresponding CTRL-B/U/I keystrokes)
have been fixed to only affect *one* attribute at a time. Formerly,
hitting CTRL-B when no other style was active, on a text portion with
italics text, for example, would kill the italics and just apply bold.
Now, these attributes always add or substract only, but do not
replace the style.
- In the past, there were bugs with material indices uninitialized, and
thus crashes in the renderer with illegal material indices.
Even though I assume they have been fixed, I've put in a check that
checks (hah) if the material index of a character is illegal (bigger
than ob->totcol), and then sets it to zero, and spits out a warning
on stderr.
If you see such warnings, please report and link to the .blend.
- Bugfix: All alignment modes only worked if there were at least *two*
lines of text in the text object. Fixed
There's now a regression test file for text objects, please add to the
corresponding repository:
http://blender.instinctive.de/downloads/release/demo/text-regression.blend.gz
- new feature, twiddled with lattice resizing to try to maintain
existing vertex changes... much nicer than just resetting the
lattice if you decide you need more detail in the lattice.
- modifiers work with lattices now. yes, that does mean you
can make a chain of lattices effecting each other 8 miles
long.
- some cleanup of softbody code, was rather splintered and call
path was twisted and confusing. reworked main object step
routine to do things in a more obvious and consistent manner
and without duplicate code
- added ob->softflag OB_SB_RESET instead of sbObjectReset
call
- modifier changes reset softbody now
- moved curve_getVertexCos/curve_applyVertexCos into curve.c
- update curve modifier eval to work with virtual modifiers
- update modifier apply to work with curves/surfs
- update make parent to also recalc object data
NOTE: Although you can turn SB on for curve/font objects at the
moment it doesn't really work because they call deform in
multiple steps and this confuses SB. Not sure how to deal with
atm.
