I was wondering why splines, within POV, are not all interchangeable and
applicable everywhere. Are not all splines the same basic thing? Lemme
see if I recall the different types in existance. There are Linear,
Quadratic, Cubic, Bezier, Catmull-Rom, B, NURB, Hermite, etc., etc.
Could all these different types be added to POV in such a way that they
could be used everywhere? For example, that I could use a bezier spline
in a sphere_sweep, or a catmull-rom spline in a prism? And the spline
keyword in the SuperPatch, couldn't it be made to accept all splines?
Thanks in advance.

[Note: POV designates official and superpatch versions]

--
Anthony L. Bennett
http://welcome.to/TonyB

Post a reply to this message

I have an interest in this as I am currently working on a
postscript-2-spline converter. It is indeed pretty odd that there would be
so many spline types when one can do everything. The bezier_spline is the
closest to the graphics industry standard and even this one is implemented
oddly with the control coordinates backward from industry standards.

I have made a very brief cursory scan of the POV source code and have
formed no opinion at all from what I've seen. It would be most enlightening
to hear from the programmers that implemented this feature and get their
thinking on why things were done the way they are.

Perhaps the POV development team would be willing to look at the
possibility of implementing an industry-wide standard spline type to make
POV-Ray more compatible with the larger world of computer graphics.

steve

TonyB wrote:

> I was wondering why splines, within POV, are not all interchangeable and
> applicable everywhere. Are not all splines the same basic thing? Lemme
> see if I recall the different types in existance. There are Linear,
> Quadratic, Cubic, Bezier, Catmull-Rom, B, NURB, Hermite, etc., etc.
> Could all these different types be added to POV in such a way that they
> could be used everywhere? For example, that I could use a bezier spline
> in a sphere_sweep, or a catmull-rom spline in a prism? And the spline
> keyword in the SuperPatch, couldn't it be made to accept all splines?
> Thanks in advance.
>
> [Note: POV designates official and superpatch versions]
>
> --
> Anthony L. Bennett
> http://welcome.to/TonyB

Post a reply to this message

Only one reply!!!? I though more people would jump in to discuss this,
especially Ron Parker. Please, somebody write. Thanks in advance.


--
Anthony L. Bennett
http://welcome.to/TonyB

As I was walking to St. Ives,
I met a man with 7 wives.
Each wife had 7 sacks.
Each sack had 7 cats.
Each cat had 7 kits.
How many were going to St. Ives?

Post a reply to this message

TonyB wrote:
> 
> I was wondering why splines, within POV, are not all interchangeable and
> applicable everywhere.  Are not all splines the same basic thing?

  They certainly are not all the same thing. Each spline type performs
a different type of function and each will influence the curvature
of a spline constructed surface in it's own unique way. Some more so
than others and some with little of no merit for 3D surface modelling.

> Could all these different types be added to POV in such a way that they
> could be used everywhere? For example, that I could use a bezier spline
> in a sphere_sweep, or a catmull-rom spline in a prism?

  I see no reason that with your basic everyday knowledge of writing
math intensive algorithms, for a complex raytracing system like Pov,
that it would an overly difficult task to add in sometime before lunch
tommorrow (humour intended).

  Seriously though as you pointed out thre are a wide variety of spline
types that have been been developed into a standard recognized format.
Each offers it's own unique function and there are applied with varying
degrees of difficulty in their implementation and the complexity of their
use by the end user. The reason I see your suggestion as impractical is
because the spline types currently available offer a good average of the
many types of splines commonly used used in these types of applications.

  There are other considerations besides just the existence of the
splines too. When you are using splines to create a surface for a 3D
object it must have mathematical compatibility with the software that
will be appying it. Some of these spline types are extremely math
intensive in the way their functions are evaluated. This makes them
difficult to use use and/or they are so time intensive from a raytracing
point of view it would not be worth the sacrifices needed to implement
them.

  The simple linear spline type in Pov for example requires a quadratic
polynomial equation to be solved in order to perform correctly. The cubic
and bezier splines each require a 6th order polynomial to be solved.
These types of high precision splines have a lot of processing overhead
and not all of the splines you mentioned are necessarily optimized or
can be optimized for use in this environment and for these type of
surface modelling applications.

  There is also the issue of whether or not you would gain very much by
providing support for every type in existence just because it exists.
There are places that you would end up with too much redundancy from
offering so many that I think you would find that in most case the
splines already provided can and will accomplish the same task for the
operation they are associated with.

  Please remember that I am speaking from an experienced Pov users point
of view and I have absolutely no clue as to what actually goes on inside
the program nor do I really have any programming or math skills to speak
of. I speak with the advantage of common sense and a few years of practical
experience using splines in Cad and Drafting software plus the experience
gained from using them in this program. There may be some glaring errors
in my reply but I tried not to exaggerate my opinions in this regard.
Take them for what they are worth and do not consider me the harbinger of
doom for your suggestions.



  Please also remember that when you post a question on a news group
no one is obligated to reply to you. A simple answer to your questions
this time was not possible and my reply has taken more time than I
really cared to devote to it.  I hate to answer with short unhelpful
replies and answering questions like these, make it a choice of
weather or not I want to spend the amount of time it takes to respond
to them in the thorough manner they deserve of just ignore it and move
on. Sometimes I just don't feel like it and there are other times I
simply do not have the time to do so.

  There is also the issue that most of the people around here who
answer to replies are not associated with the Pov team in any way
and are not able to dictate to them what can and or cannot be added
to their software. It gets a little tiring to wish too much about
things you are not even sure are reaching the right ears. If you
think your idea has enough merit send Chris Young a proposal or
feature request and let him decide if it's worth the effort.

  Others who frequently respond to peoples questions here have similar
restrictions and you just are not going to get a large response to
every question you can think of to post. Try to keep this in mind when
your questions seem to go unnoticed or only receive a single reply.
It is not that they are poor questions but more likely are poorly
timed as to when they are posted. Catch me on a good day and I will
write the whole pov manual into a reply for you. Catch me on a bad
day and you will hear not a word from me.

Regards,

-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

On Tue, 18 May 1999 06:22:22 -0400, TonyB wrote:
>Only one reply!!!? I though more people would jump in to discuss this,
>especially Ron Parker. Please, somebody write. Thanks in advance.

Believe it or not, I didn't jump in because I've never paid much attention
to how they do all those splines.  I imagine the actual ray-object intersection
test is quite different for a cubic-spline sphere sweep than for a cubic-spline 
sor, though, so it's probably not as easy to generalize as you may think.
Though there's no reason the "spline" keyword couldn't support all different
types of splines.  Keep in mind, though, that just because I maintain this 
behemoth doesn't mean I understand it all completely.

Post a reply to this message

On Tue, 18 May 1999 06:22:22 -0400, TonyB
<ben### [at] panamaphoenixnet> wrote:

It isn't quite that simple.  Many spline types are pretty
interchangeable to create - just drop in a different basis matrix.
Cardinal splines, simple b splines, etc.  Others, like Hermite
splines, involve a relatively minor change in how and in what order
you use the points.  Rational splines involve using four instead of
three coordinates (rational Beziers are in the Superpatch).  This is a
bit more work.  Nonuniform splines such as NURBS really need a whole
different setup.  None of this addresses the problems of intersecting
a given type of spline or patch.  If you want to play with some of
them, it is trivial to write macros to provide points for Cardinal,
Tau, B-splines and a few others that you can use as a sort of poor
man's sphere sweep.  Incidentally, it is possible, if a bit of a PITA,
to produce a set of Bezier patches/splines to emulate the results of
using say, a NURB if you want to go to enough effort.  Another thing
to consider is that you would really need a modeller flexible enough
to support them before most people could reap much benefit.

Jerry Anning
clem "at" dhol "dot" com

Post a reply to this message