The main change is to caculate tangent directly from bezier curve, without going
through discretized polyline, avoiding pitfalls of discretization. A similar refacor
had been applied to Curve3D.
The test cases for Curve2D is updated, comparing floating point with is_equal_approxmiate()
instead of `==`, in order to avoid float precision problem.
The problem is caused by calling adaptive tessellation baking function by mistake, which produce too few points for straight lines. Calling the even length tessellation fix the problem.
The code for `get_closest_point()` and `get_closest_offset()` are also updated. They used to assume bake interval to be exact, which is no longer true.
The out dated document for `get_closest_point()` is also updated.
The main change is to caculate tangent directly from bezier curve, without going
through discretized polyline, avoiding pitfalls of discretization.
Other changes are:
1. Add an bezier_derivative() method for Vector3, Vector2, and Math;
2. Add an tesselate_even_length() method to Curve3D, which tesselate bezier curve to even length segments adaptively;
3. Cache the tangent vectors in baked_tangent_vector_cache;
This commit makes the following major changes
1. Add "sample_baked_with_rotation()" to Curve3D, making it usable independently. A similar change was made to Curve2D previously.
2. Refactor the _bake() method on Curve3D, using Parallel Transport Frame instead of Frenet Frame.
3. Refactor the sample_* methods, including:
i. Factor out common binary search code, following the DRY principe
ii. sample_up_vector() interpolated up vector as part of rotation frame(posture) for consistancy and accuracy.
This makes it easier to spot syntax errors when editing the
class reference. The schema is referenced locally so validation
can still work offline.
Each class XML's schema conformance is also checked on GitHub Actions.
For the time being we don't support writing a description for those, preferring
having all details in the method's description.
Using self-closing tags saves half the lines, and prevents contributors from
thinking that they should write the argument or return documentation there.
Based on the doc, I wasn't sure if get_closest_point would return the
closest baked point or the closest "source" point. It seems to use
baked:
8faecd6a47/scene/resources/curve.cpp (L809)
I verified this experimentally. I added a point at roughly (1,0,0), and
dragged a handle back to the origin. The result was:
```
get_point_position: (0.991079, 0, -0.000069)
get_point_in: (0.993409, 0, 0)
get_point_out: (-0.993409, 0, 0)
```
We already removed it from the online docs with #35132.
Currently it can only be "Built-In Types" (Variant types) or "Core"
(everything else), which is of limited use.
We might also want to consider dropping it from `ClassDB` altogether
in Godot 4.0.
- Document a few more properties and methods
- Add more information to many classes
- Fix lots of typos and gramar mistakes
- Use [code] tags for parameters consistently
- Use [b] and [i] tags consistently
- Put "Warning:" and "Note:" on their own line to be more visible,
and make them always bold
- Tweak formatting in code examples to be more readable
- Use double quotes consistently
- Add more links to third-party technologies
Rename user facing methods and variables as well as the corresponding
C++ methods according to the folloming changes:
* pos -> position
* rot -> rotation
* loc -> location
C++ variables are left as is.
