"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:

> I assume that you are looking at my 'Bezier_Patches_Stitched' files.

Yes.   They were, in fact, the motivation for my original attempts at stitching
9 patches together.

> (The positions for these white corner points were specified "manually".)

Yes, that would make sense.

> The
> small vectors are also used to control the distances between these control
> points.

Mmmmmm... I'll have to think about that.

> AFAIK it is common to let the small vectors have the same direction as the large
> vectors and to let their lengths be 1/6 of the length of the large vectors.

That makes sense from what I've tried to do, and is consistent with your
diagrams / renders.

> But I think that one can choose other orientations and lengths for the small
> vectors (but I have not had time to experiment with this yet).

Yes, and I think that I may have tried to bite off more than I could chew at the
time.

How did you smoothly connect the corner points in
http://news.povray.org/web.5b7398619b869b61264be49d0%40news.povray.org ?
Is that a bezier spline sphere-sweep?
[Is it /beh-ZHEER/?]

I spent some time pondering the boundary conditions, and how to process 16
patches like the stitched renders.
What I've come up with is to
create an array of 25 corner points
create an array of 16 points, and "copy" the relevant corner points into the
appropriate places
calculate the linear vectors between the corners of each side
set the control points on those sides to 1/3 and 2/3 of the vector
Use those control points to interpolate the 4 inner control points in an
analogous manner

I hope to get a little bit more time tonight to try and implement that, and see
how it goes.

Then I can start to think about how to write a macro and set up a data structure
to instantiate arbitrarily selected patches, given the corner points.  It's the
lone corners and edges that might be tricky for me.


Now, having better grasped what you were doing here, I'd say that based on my
reading, this would give "G1 continuity".

I think that my first time approaching this, I was trying to use 3x3 patches to
give 4 control points and then do deCastejau to subdivide the super-pseudo
Bezier spline suggested by those 4 points so that I could interpolate the inner
control points of the edges in a "Bezier manner", if that makes sense.

Then having a series of X-alined splines, I could use all of those control
points to do the same with the z-aligned splines

But there may be an inherent error in trying to do it that way.

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:

> I spent some time pondering the boundary conditions, and how to process 16
> patches like the stitched renders.
> What I've come up with is to
> create an array of 25 corner points
> create an array of 16 points, and "copy" the relevant corner points into the
> appropriate places
> calculate the linear vectors between the corners of each side
> set the control points on those sides to 1/3 and 2/3 of the vector
> Use those control points to interpolate the 4 inner control points in an
> analogous manner

So, I tried a slight modification of the above, following your suggestion, and
what your diagrams/renders imply, and I got 16 connecting patches - but with
sharp seams.

I used 4 vectors describing the edges between the 4 corners, and divided them by
3.   I then used those vectors to describe the control points by adding them to
the corners, and adding 2 vectors to a corner to get the 4 inner control points.

It makes sense that it's not smooth, or curved, because everything is just on a
line, and the non-corner control points aren't really control points by this
method - they're just passively following along with the corners.

So I ignored the y part of the vectors and just made "level" sub-patches, and
that seemed to give me something resembling your stitched patch render.


I know I'm still probably a ways off from what you've got - and pretty far off
from what I originally envisioned, but that might possibly be overkill.

Post a reply to this message

Attachments:
Download '12_smooth_bicubic_patches.png' (604 KB)

Preview of image '12_smooth_bicubic_patches.png'

I just added some code to draw the Bezier splines across the patch, using Cousin
Ricky's spheresweep.inc v1.2 from the Object Collection.

The splines don't quite line up - but I suppose, more concerning is that the
splines don't intersect with the corner points.

Probably just some wee little bug in there somewhere.
I'm using the web interface, so I can't rename the message title.

MAYBE I might try to code up a quick Bezier spline macro, if the formula I found
here:
http://wiki.povray.org/content/HowTo:Use_Splines_and_Bezier_Curves
(with the bad math code)
is correct.

P(t) = A*pow((1-t),3) + 3*B*t*pow((1-t),2) + 3*C*pow(t,2)*(1-t) + D*pow(t,3)

which seems to jive with
http://idav.ucdavis.edu/education/CAGDNotes/Matrix-Cubic-Bezier-Curve/img1.gif

Post a reply to this message

Whoops.
Render attached.

Post a reply to this message

Attachments:
Download '12_smooth_bicubic_patches.png' (988 KB)

Preview of image '12_smooth_bicubic_patches.png'

So, I played with some parametric Bezier splines, and that went -- horribly.
:D

But it hinted at the source of the problem - the interpolated control points are
control points - NOT on the surface of the patch - so a spline based on those
doesn't touch the surface.

I got rid of the intermediate sweeps and all is well.

Ricky's off the hook.
Good job.

:)

Post a reply to this message

Attachments:
Download '12_smooth_bicubic_patches.png' (963 KB)

Preview of image '12_smooth_bicubic_patches.png'

On 18-8-2018 23:14, Bald Eagle wrote:
> So, I played with some parametric Bezier splines, and that went -- horribly.
> :D
> 
> But it hinted at the source of the problem - the interpolated control points are
> control points - NOT on the surface of the patch - so a spline based on those
> doesn't touch the surface.
> 
> I got rid of the intermediate sweeps and all is well.
> 
> Ricky's off the hook.
> Good job.
> 
> :)
> 

Well done, sir! Well done!

Last night, I dreamed about Klein Bottles. That would be a hellish job 
to model I guess. ;-)

-- 
Thomas

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:


> Last night, I dreamed about Klein Bottles. That would be a hellish job
> to model I guess. ;-)

Probably pour a hell of a cocktail too   :)

I was actually inspecting TOK's tori more closely to to try and understand where
my first attempt (this round) went off the rails.  I think it's because I kept
all my data isolated to the patch instead of "looking over" to see if there was
another patch adjacent to that edge.

And that got me thinking about how he automates the patching of a torus - and
the kind of data structure and algorithms that are needed.

I think I get it.   I also think I might need to write some macros to do things
with arrays that we don't have yet, or that can only be done "the long way" - so
macros it is.

Thanks for the kind words.   It's been slow going.

It seems like there are a few projects hovering around some common things, and
it would be great if there were some breakthroughs and they could coalesce.

Very interested in JimT's work on the triangular patch, and BGimeno's excellent
patterned tori.  I think the triangular patch would open up some new
possibilities, or at least make them easier to implement.

Post a reply to this message

Thinking about this a little more - and thinking back, it was a combination of
TOK's work and the question about the vibrating plate that combined to start me
investigating how to control a bicubic patch - or a network of them - such that
the surface could be made to intersect specifically designated points.

Going in the opposite direction:

(ignoring trace(), and approaching this a priori / ab initio)

Given that a Bezier patch can be interpreted as a Bezier spline in one dimension
whose control points slide along Bezier splines oriented in the other dimension,
and that this can be expressed as a parametiric equation, then

It ought to be possible to define a parametric {} object in POV-Ray based on a
set of control points and the basis functions of the Bezier splines.

Then, given a point <m, n> (or <u, v>) on the surface, one could place things ON
the surface of the patch.

This should also allow the generation of _any_ spline between the ordinate /
cardinal splines defined by the corners.  In theory one should be able to
simulate a patch by juxtaposing a series of splines from one side to the other
in either dimension.

I think that it also might be possible to define an isosurface {} in the same
way, and since there's a method for creating offset surfaces with isosurfaces,
then I'd be interested in seeing what's possible with a 3D rectangular mesh
skinned in Bezier patches and making a thickened hollow shell by that method.

Just some thoughts.



I also have a question that I have not answered for myself yet - is there a type
of spline that is coincident with a Bezier spline, but that contains / is
coincident with its own control points?

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> I just added some code to draw the Bezier splines across the patch, using Cousin
> Ricky's spheresweep.inc v1.2 from the Object Collection.
>
> The splines don't quite line up - but I suppose, more concerning is that the
> splines don't intersect with the corner points.
>
> Probably just some wee little bug in there somewhere.
> I'm using the web interface, so I can't rename the message title.
>
> MAYBE I might try to code up a quick Bezier spline macro, if the formula I found
> here:
> http://wiki.povray.org/content/HowTo:Use_Splines_and_Bezier_Curves
> (with the bad math code)
> is correct.
>
> P(t) = A*pow((1-t),3) + 3*B*t*pow((1-t),2) + 3*C*pow(t,2)*(1-t) + D*pow(t,3)
>
> which seems to jive with
> http://idav.ucdavis.edu/education/CAGDNotes/Matrix-Cubic-Bezier-Curve/img1.gif

I explain why I did it the way I did in p.o-c:

On 2015-09-11 08:21 PM (-4), Cousin Ricky wrote:
>
> 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.

Rewriting the code to match the reduced formula might give people peace of mind
that my SDL is correct, but as long as the current version works, there's no
urgency to mess with it.

Post a reply to this message

"Cousin Ricky" <rickysttATyahooDOTcom> wrote:

> I explain why I did it the way I did in p.o-c:

Yes, I read that part - no complaints here.
I'm very happy with what you were able to achieve - I read through the code, and
it's pretty impressive.
You still have 1000x times the drive and attention span of most people.

> Rewriting the code to match the reduced formula might give people peace of mind
> that my SDL is correct, but as long as the current version works, there's no
> urgency to mess with it.

"Never worry about theory as long as the machinery does what it's supposed to
do." - Robert A. Heinlein

Again, excellent work - it does exactly what I need it to do.  :)

Post a reply to this message