I wanted to make a patch type object that passed through all control points.
After doing some web research, I found that the schemes for which I could
actually find an algorithm were not optimal for this purpose. These
algorithms had all been designed for animation and concentrated on speed of
calculation.

None that I found would put points directly in the centers of all uv squares
even when the control points were laid out in a flat grid. This is because
the algorithms handle corners and sides by increasing the weight of points
near the edges to make up for calculation points which are not present. My
algorithm uses the available points to guess where "missing" control points
might be and assures a proper weight for all points.

The best algorithm I could find that went through all of the control points
worked with triangles only. I prefer to work with squares when possible,
because the selective division of squares suggested to me by Hugo allows for
a better looking surface with far fewer control points. Since this patch
passes through all control points, using squares instead of triangles also
decreases the degree to which the object's shape is forced.

I really wrote this to see if I could do it. I don't think that I will
pursue this much further, because I prefer to build meshes myself with EVERY
point used as a "control point."

What do y'all think of this?

 -Shay

Post a reply to this message

Attachments:
Download 'splitJPG.jpg' (35 KB)

Preview of image 'splitJPG.jpg'

Shay wrote:
> What do y'all think of this?

Looks like your going for subdivision surfaces. Is the original model in
quads or tris?

I'm not sure why you want the surface to go through all control points. This
will create hard edges and while it is sometimes wanted I think the point of
subdivision surfaces is to make the model more defined but also somewhat
smoother.

On a sidenote: After 3.5 is finalized I'm gonna start bugging people about
programming subdivision surfaces for POV (You are now on that list of people
;)
 ). I've already approached J. Vansickle about this matter.

-Jide

Post a reply to this message

Jide <jid### [at] kotisoonfi> wrote in message
news:3cc03cf7@news.povray.org...
>
> Looks like your going for subdivision surfaces. Is the original model in
> quads or tris?

The original model is in quads. They are made into tris for rendering by
choosing the optimal division for the curve. All of the calculations are
done with quads and the output is quads. I created the weight patterns
myself to be used this way.

>
> I'm not sure why you want the surface to go through all control points.
This
> will create hard edges and while it is sometimes wanted I think the point
of
> subdivision surfaces is to make the model more defined but also somewhat
> smoother.
>

Every process except building the mesh entirely by yourself makes the object
*less* defined.

Not going through all control points makes the object much less defined and
much smoother. Passing through all of the control points retains most of the
definition of the object and makes the object somewhat smoother. Ideally,
you should have both options available to you and of course more definition
can be retained in any object by using more control points.

If you are subdividing two objects which are just touching each other,
division through control points will keep them just touching each other
provided the control points are a the location where the objects are
touching.

The two processes are unique and produce a completely different results.
 -Shay

Post a reply to this message

Jide <jid### [at] kotisoonfi> wrote in message
news:3cc03cf7@news.povray.org...
>
> On a sidenote: After 3.5 is finalized I'm gonna start bugging people about
> programming subdivision surfaces for POV (You are now on that list of
people
> ;)
>  ). I've already approached J. Vansickle about this matter.
>

Someone has already done this. I can't remember who or where, however. The
file was called "Surface Subdivision Suite" and is probably still around. My
macro isn't true mesh subdivision, just surface subdivision. It could easily
be adapted to subdivide entire meshes, but I think most modelers work with
triangles and not quads. I am considering learning a computer language and
writing my own modeler which works mainly with scripting, but also supports
mouse point selection, dragging, etc.

 -Shay

Post a reply to this message

> What do y'all think of this?

I think this is cool! Very cool. More triangle / quad stuff in Povray is
good. But it's a challange to make macros that are easy and powerful. Well..
the more ideas, the more luck.. Does your macro need the control points to
be in a grid?  For example 3*4 meaning 4 rows with 3 columns each.. That's
typical for macros, but often annoying for me to model in this way.

Your experiments are however steps into an interesting direction.

Regards,
Hugo

Post a reply to this message

Hugo <hua### [at] post3teledk> wrote in message news:3cc07978@news.povray.org...
>
> I think this is cool! Very cool.

Thanks.

> Does your macro need the control points to
> be in a grid?  For example 3*4 meaning 4 rows with 3 columns each.. That's
> typical for macros, but often annoying for me to model in this way.
>

It does at the moment, but that can be easily changed. The problem with
making a macro which works on a group of points rather than a grid is that
more is required from the user. The macro in it's current state requires
only an array of points. The use of points not layed out in a pre defined
order requires that the user also input the edges, triangles, or some other
kind of direction specifying the order in which the points are to be used.

With subdivision like this, that need isn't much of an obstacle because so
few control points are used. I may try this over the weekend.

 -Shay

Post a reply to this message

> The problem with making a macro which works on a group of
> points rather than a grid is that more is required from the user.

Oh, I sort of hoped the opposite but maybe I haven't thought enough about
it. What about an intelligent system that connects those control points that
are closest to each other? This would lead to some mistakes, but I think I
can imagine a system where ... there's an integer after each control point,
so in case of mistake, the user modify this integer and the system tries
another connection, still with the closest points.. hmm.. No, it wouldn't
really work... :o/  Because with very few control points, sometimes they
aren't even close to each other.

Then perhaps a system that connects the points in the order, they are
specified by the user. That way, the user don't have to stick to a grid, or
even think too much about it.

I'm thinking loud here, but just in case it's an inspiration (ehm, perhaps
not... ;o)

Regards,
Hugo

Post a reply to this message

Connecting closest points will not work because PointB can be the closest
point to PointA, but PointA may not be the closest Point to PointB. Like
this:

PointA--------------PointB--PointC

Supplying an order in which the points are to be used would need two
arrangements for quads. As long as you have an even number of points, you
would be doing the exact same thing as the grid array.

I think I have an idea for averaging the points into a mesh when the corners
are specified that would be pretty straightforward to code, however. The
user would input the boundaries for a field into which any number of points
could be placed in any order. The macro would then reproduce the field. Is
this the kind of thing about which you were thinking?

 -Shay


Hugo <hua### [at] post3teledk> wrote in message
news:3cc084c0$1@news.povray.org...

Post a reply to this message

> I think I have an idea for averaging the points into a mesh when the
corners
> are specified that would be pretty straightforward to code, however. The
> user would input the boundaries for a field into which any number of
points
> could be placed in any order. The macro would then reproduce the field. Is
> this the kind of thing about which you were thinking?

Sort of ... boundaries acting like a skeleton, that gives away the basic
shape, and those control points that are within the boundary are then
connected...?  Or, I'm not sure I understood what you meant.. But this was
another idea.  ;o)  I don't know if it would work.

Regards,
Hugo

Post a reply to this message

Hugo <hua### [at] post3teledk> wrote in message
news:3cc08cf7$1@news.povray.org...
>
> Sort of ... boundaries acting like a skeleton, that gives away the basic
> shape, and those control points that are within the boundary are then
> connected...?  Or, I'm not sure I understood what you meant.. But this was
> another idea.  ;o)  I don't know if it would work.
>

That is exactly what I meant. In fact, the averaging could easily be used to
create a NxN mesh which could then be subdivided with the macro I have
already written. This would be like cheating. The user would only need to
put in a boundary and then some group of points. No edge or triangle
information would be required.

 -Shay

Post a reply to this message