| Age | Commit message (Collapse) | Author |
|---|
|
Black dots appearing in mirroring 3d beveled curves, when using orco
texture coords. Appeared there was memory read just outside of the
allocation.
|
|
- the number of segments was always 1 too many on cyclic curves.
- [#17739] - normals were not being calculated when rendering curves.
Replaced macro DL_SURFINDEX with a function. it that assumes variable names and could break from the loop that called it.
|
|
radius was not being calculated on curves that had a bevel object
|
|
|
|
recommit
|
|
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.
|
|
over the whole surface.
This is what 2D do alredy and makes resolution settings more like subsurf level.
- This makes it impossible to have a lower resolution output then the nurbs cage, however this dosnt seem a very useful feature.
- Using the do-versions from recent curve interpolation fix.
Tested with these files.
http://digilander.libero.it/pafurijaz/Files/Blender/Libellula.zip
http://digilander.libero.it/pafurijaz/Files/Blender/Martello.zip
http://digilander.libero.it/pafurijaz/Files/Blender/Punta.zip
http://digilander.libero.it/pafurijaz/Files/Blender/Phones.zip
http://digilander.libero.it/pafurijaz/Files/Blender/Tubo.zip
http://digilander.libero.it/pafurijaz/Files/Blender/Pipe.zip
http://digilander.libero.it/pafurijaz/Files/Blender/Tire.zip
http://digilander.libero.it/pafurijaz/Files/Blender/Cotton.zip
|
|
|
|
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.
|
|
stored in bezt->f1,2,3
|
|
nurbs but after, cyclic nurbs would be incorrect if the bezier or endpoint u/v was set.
also replaced some numbers with constants.
|
|
order wasnt 3 or 4. add a function that checks nurbs can produce a valid line. check_valid_nurb_u/v
* 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.
|
|
crash blender or make odd display lists.
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.
|
|
blocks that were previously missed; and b) greatly increase my
ohloh stats!
|
|
|
|
Though I could not reproduce the crash, the example file would always reference an invalid pointer.
|
|
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...
|
|
broken for vector handles
|
|
|
|
point's before a curve. now allow the bevel list to have zero point BevList's to keep in sync with curve->nurb as was expected in a few places.
|
|
replaced some magic numbers
|
|
(Similar to how Metaballs can be selected) for easier access then H,Shift H, V keys
|
|
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.
|
|
* colour -> color
* centre -> center
* normalise -> normalize
* modelling -> modeling
|
|
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
|
|
previously only some datatypes adding functions accepted a name.
also updated the Bpy.py epydocs
|
|
view: Just made the initial curve resolution consistent between curve parts'
resolution and curve object's resolution.
|
|
EditMode text objects: using different text Width didn't draw anything.
|
|
(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.
|
|
Bugfix #5075: make curve.update() recalculate bezier curve handles. This
would/should be called after changing the handles of a BezTriple.
|
|
renamed the dutch variable hoek to angle globally arithb.c changes done by Matt Plough
|
|
would be
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! :)
|
|
as a full circle instead of 2 halves.
|
|
located under the 'def resolu' button. If not zero, it assigns this
resolution to a curve on render.
Also copies with ctrl+c menu.
|
|
when edit mode was entered.
|
|
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!
|
|
ensure the handles never result in a curve that goes beyond the neighbour
control points.
http://www.blender.org/cms/Animation_Curve_Handle.717.0.html
|
|
Sir yes sir!
|
