I'm writing a graphical spline editor for POV's splines and I'm having 
some difficulties to get my splines behave like POV's (POV 3.5 to be 
specific):

The main problem is the fact that splines from spline-identifiers like

#local myspline = spline {
	quadratic_spline
	0, <2,3>
	...
}

behave totally different from the ones used in lathe/prism It's not only 
that the syntax is different: If you've got a quadratic spline lathe 
with 3 points, it will only evaluate between points 2 and 3. Quadratic 
splines from spline identifiers will, in contrast, evaluate between all 
three points. Whereas if you're using a cubic spline with 4 points both 
types behave the same way (which is they evaluate only between points 2 
and 3).

So: What is the idea behind this? Will the concept of splines be changed 
to a more uniform one in POV 4.0 (yes, I did read the output on the 
message window telling me that splines are a experimental feature :)?

And I got another 2 questions (which are unrelated to the questions above):
- Why isn't it possible to use bezier_spline in spline identifiers?
- How are the clock values for the splines of lathe/prism computed? I 
guess they are chosen proportional (?) to the distance of the points, is 
this right?

Thanks for any hints
Florian

Post a reply to this message

On Tue, 11 May 2004 21:10:13 +0200, Florian Brucker <tor### [at] torfboldcom> wrote:
> So: What is the idea behind this? Will the concept of splines be changed 
> to a more uniform one in POV 4.0 (yes, I did read the output on the 
> message window telling me that splines are a experimental feature :)?

The idea behind it is most probably... lack of idea :-(
IIRC splines{} are basically content of patch ported to 3.5. Original patch
wasn't integrated with lathe/prism, so after including it in 3.5 it isn't
integrated as well. It's not that simple to integrate internally (considering
that splines in lathe/prism are optimized for fiding clock for given ray while
splines{} are optimized for finding vector for given clock) and since writing
spline-based lathe/prism-like meshes is pretty simple, I do not think there is
any very serious need for it. But it would be interesting to have macro or
patch to perform conversion from old lathe/prism data to most accurate spline.

> And I got another 2 questions (which are unrelated to the questions above):
> - Why isn't it possible to use bezier_spline in spline identifiers?

Because nobody made it yet ?
I have in my TODO list to add as many spline types as possible in form of
patch to source code. It is very simple (from programmer point of view of
course :-) ). Up to now I have added akima_spline, tcb_spline, and a few
x_spline variants. If you are interested in visualisations, just follow link
in my posts in thread http://news.povray.org/povray.general/31113/ or google
for details.

> - How are the clock values for the splines of lathe/prism computed? I 
> guess they are chosen proportional (?) to the distance of the points, is 
> this right?

They are not chosen, they are computed. If they are in range 0-1 after
computation then intersection happens for single segment (IIRC). See source of
lathe/prism.cpp for details.

ABX

Post a reply to this message

ABX wrote:
> On Tue, 11 May 2004 21:10:13 +0200, Florian Brucker
> <tor### [at] torfboldcom> wrote:
>> So: What is the idea behind this? Will the concept
>> of splines be changed to a more uniform one in
>> POV 4.0 (yes, I did read the output on the message
>> window telling me that splines are a experimental
>> feature :)?
>
> The idea behind it is most probably... lack of idea :-(

That's my impression too.

I even think that at one point in the development of POV-Ray 3.5, the
spline type now known as natural_spline was planned to be implemented
under the name cubic_spline, despite the fact that it's a completely
different type of cubic_spline than the one used in prisms. Luckily
those plans were changed.

> IIRC splines{} are basically content of patch ported to 3.5.

No, they were very much rewritten from scratch I think.

>> And I got another 2 questions (which are unrelated to
>> the questions above): - Why isn't it possible to use
>> bezier_spline in spline identifiers?
>
> Because nobody made it yet ?

I'm curious how the clock values would work for bezier splines. For
cubic splines the clock values change not just the time dimension but
also the path of the spline, since it works by adjusting the tangent
control points (which the user can't control in a cubic spline).
However, with bezier splines the user controls the tangent control
points directly, so having the program adjust those to make them fit the
clock values might seem odd.

Rune
--
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com **updated Apr 27**
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message

follow-up set

On Tue, 11 May 2004 23:39:44 +0200, "Rune" <run### [at] runevisioncom> wrote:
> > IIRC splines{} are basically content of patch ported to 3.5.
>
> No, they were very much rewritten from scratch I think.

I'm not sure about that. I see similiarities between current splines.cpp and
splines.c of MegaPOV 0.7.

> > Because nobody made it yet ?
>
> I'm curious how the clock values would work for bezier splines. For
> cubic splines the clock values change not just the time dimension but
> also the path of the spline, since it works by adjusting the tangent
> control points (which the user can't control in a cubic spline).
> However, with bezier splines the user controls the tangent control
> points directly, so having the program adjust those to make them fit the
> clock values might seem odd.

For comparison tcb_spline addition I add new parameters as well.
The syntax for it is:

  spline{
    tcb_spline [ tension FLOAT ] [ continuity FLOAT ] [ bias FLOAT ]
    ENTRY
    ENTRY
    ENTRY
    ...
  }

where ENTRY is more

  ENTRY :
    FLOAT
      [ tension FLOAT ] [ continuity FLOAT ] [ bias FLOAT ]
      VECTOR
      [ tension FLOAT ] [ continuity FLOAT ] [ bias FLOAT ]

so you can define tcb (tension, continuity and bias) parameters
1) immediately after spline type which makes default parameters for all
control points,
2) between clock value and vector control point which affects end of segment
finished by this vertex
3) after vector value which affects begining of next segment started by this
vertex

BTW: I forgot to mention sor_spline which duplicates cross section of sor{}.
This patch is already available in MegaPOV 1.0 and described at
http://megapov.inetart.net/manual/expressions.html#sor_spline
http://abx.art.pl/pov/patches/sorspline.php

ABX

Post a reply to this message