 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In SphereSweep 1.2, the Bézier spline is implemented for all the object
macros except SphereSweep_Native().
http://lib.povray.org/searchcollection/index2.php?objectName=SphereSweep&contributorTag=Cousin%20Ricky
In light of recent interest in Bézier sphere sweeps, here are some notes
on the implementation in spheresweep.inc.
The new include file is nearly twice the size of the previous version.
The actual Bézier calculation is done in macro SSwp__Bezier_calc(), and
is remarkably simple. But, as I have mentioned before, integrating this
calculation into functional objects was not straightforward. The bulk
of the new code is for managing the different segments. Unlike the
curve sections of all the other spline types, Bézier segments are not
logically tied to each other. This necessitated handling Bézier objects
separately from all the others, as well as writing new macros dedicated
to negotiating the splicing of curve segments when and only when the
segments are physically contiguous.
My calculation uses brute force rather than the single reduced formula
with all the pow() calls. This was because my ability to concentrate is
so bad nowadays that I just gave up on trying to figure it out. I
figured that the internal math of the reduced formula would be more
complicated anyway. Had I known how simple the final formula was, and
recalled Clipka's observation that the complexity of the SDL always
trumps the math, I would have taken that route. However, the parse time
is so short, there would be little difference either way.
If you examine the SDL code, you will notice that all of the local
variables are prefixed with sswp_. This would seem redundant with the
#local directives, and makes the code rather hard to follow. The reason
for this policy is to circumvent an unfortunate POV-Ray namespace scope
leakage; it is a requirement for Object Collection compliance level 3.
(Not all "compliant" modules follow this rule, because it wasn't
instituted until the scope leakage was discovered, which was well after
the creation of the Object Collection.)
I've recently discovered that the PointArrays module has Bézier sphere
sweep capability. Previously, I had only noticed the lathe and prism
features. With all the talk about sphere sweeps lately, I'm surprised
that Matthew (a.k.a. Blue Herring) never chimed in. (Are you still
around, Matthew?) There is considerable overlap between the two
modules, including variable radius capability. Matthew seems to have
approached the problems similarly to the way I did, although we use
different user interfaces. (And, you can check out the SDL for both
modules, to see how straightforward it was to accommodate varying
radii.) I have focused more on sphere sweeps, and have provided more
options for these than PointArrays does. PointArrays, for its part, has
more array manipulation capability.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Cousin Ricky <ric### [at] yahoo com> wrote:
> In SphereSweep 1.2, the Bézier spline is implemented for all the object
> macros except SphereSweep_Native().
>
>
http://lib.povray.org/searchcollection/index2.php?objectName=SphereSweep&contributorTag=Cousin%20Ricky
>
In the Blender it is possible to scale only control points.
At you
#declare Arm_def = array[4][3]
#declare Arm_rs = array[12]
Unclear, as to control it.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"LanuHum" <Lan### [at] yandexru> wrote:
> In the Blender it is possible to scale only control points.
> At you
> #declare Arm_def = array[4][3]
> #declare Arm_rs = array[12]
> Unclear, as to control it.
Arm_def is not used as-is by Bezier algorithms. It describes Bezier curves in a
format that I find easier to control. The format is described in the user
manual.
The macro SSwp_Bezier() converts Arm_def to Arm_pts. Arm_pts is the
one-dimensional array of control points that is in the form expected by Bezier
algorithms. If you look at the message window from a spheresweep_cockpit.pov
render, you will see the Arm_pts array in its final form.
Arm_rs is the array of the radii that correspond to the control points.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 12.09.2015 um 02:21 schrieb Cousin Ricky:
> Unlike the
> curve sections of all the other spline types, Bézier segments are not
> logically tied to each other. This necessitated handling Bézier objects
> separately from all the others, as well as writing new macros dedicated
> to negotiating the splicing of curve segments when and only when the
> segments are physically contiguous.
Why not just require that the end point of one Bézier segment is equal
to the starting point of the next one?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Cousin Ricky" <rickysttATyahooDOTcom> wrote:
> "LanuHum" <Lan### [at] yandexru> wrote:
> > In the Blender it is possible to scale only control points.
> > At you
> > #declare Arm_def = array[4][3]
> > #declare Arm_rs = array[12]
> > Unclear, as to control it.
>
> Arm_def is not used as-is by Bezier algorithms. It describes Bezier curves in a
> format that I find easier to control. The format is described in the user
> manual.
>
> The macro SSwp_Bezier() converts Arm_def to Arm_pts. Arm_pts is the
> one-dimensional array of control points that is in the form expected by Bezier
> algorithms. If you look at the message window from a spheresweep_cockpit.pov
> render, you will see the Arm_pts array in its final form.
>
> Arm_rs is the array of the radii that correspond to the control points.
In vector graphics all curve bezier are provided as sequence of bezier-splines
(cairo, inkscape, blender).
One spline:
move_to (x, y) - control point 0
curve_to (x0, y0, x1, y1, x2, y2)
Where
x0, y0 - right handle control point 0
x1, y1 - left handle control point 1
x2, y2 - control point 1
That the user could transfer data from the editor to your macro, it is necessary
to follow the standard.
If the end of a spline 0 is the beginning of a spline 1
move_to (x, y)
curve_to (x0, y0, x1, y1, x2, y2)
curve_to (x3, y3, x4, y4, x5, y5)
curve_to (x6, y6, x7, y7, x8, y8)
curve_to (x9, y9, x10, y10, x11, y11)
If splines are broken off,
move_to (x, y)
curve_to (x0, y0, x1, y1, x2, y2)
move_to (x3, y3)
curve_to (x4, y4, x5, y5, x6, y6)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> Why not just require that the end point of one Bézier segment is equal
> to the starting point of the next one?
The criteria were obvious enough. Loop control was another matter, and worse,
the solution differed depending on whether I was constructing the object out of
cones and spheres, blob components, or linear_spline sphere_sweeps.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Cousin Ricky <ric### [at] yahoocom> wrote:
> In SphereSweep 1.2, the Bézier spline is implemented for all the object
> macros except SphereSweep_Native().
>
>
http://lib.povray.org/searchcollection/index2.php?objectName=SphereSweep&contributorTag=Cousin%20Ricky
>
congratulations.!
>
> I've recently discovered that the PointArrays module has Bézier sphere
> sweep capability. Previously, I had only noticed the lathe and prism
> features. With all the talk about sphere sweeps lately, I'm surprised
> that Matthew (a.k.a. Blue Herring) never chimed in. (Are you still
> around, Matthew?) There is considerable overlap between the two
> modules, including variable radius capability. Matthew seems to have
> approached the problems similarly to the way I did, although we use
> different user interfaces. (And, you can check out the SDL for both
> modules, to see how straightforward it was to accommodate varying
> radii.) I have focused more on sphere sweeps, and have provided more
> options for these than PointArrays does. PointArrays, for its part, has
> more array manipulation capability.
Well, it is a good module indeed. Thanks.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 09/12/2015 09:38 AM, clipka wrote:
> Am 12.09.2015 um 02:21 schrieb Cousin Ricky:
>
>> Unlike the
>> curve sections of all the other spline types, Bézier segments are not
>> logically tied to each other. This necessitated handling Bézier objects
>> separately from all the others, as well as writing new macros dedicated
>> to negotiating the splicing of curve segments when and only when the
>> segments are physically contiguous.
>
> Why not just require that the end point of one Bézier segment is equal
> to the starting point of the next one?
It just occurred to me that I may have misinterpreted your question. If
it's why I don't disallow discontinuous segments, I just made a decision
to allow maximum flexibility.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
