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

In article <umg3a01aqlt22ht3o54sbntcmi8uh4h7bi@4ax.com>,
 ABX <abx### [at] abxartpl> wrote:

> > 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.

It wasn't rewritten from scratch, but a large amount of the code was 
rewritten and cleaned up. For example, the memory management was 
rewritten to allow indefinitely sized splines...before, you were limited 
to a certain number of points. (this patch may actually have made it 
into 0.7, I don't recall)

I also remember a lot of changes to the cubic spline before it finally 
became the natural cubic spline.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

> [...] 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.

Hm. Seems that I'll have to implement editing modes for all those 
different "equal" splines :/

Are the different approaches of the two spline systems (finding 
intersections vs. finding vectors) really that much different that it is 
not possible (or not desirable) to create a global spline system which 
does both jobs?

 > 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 :-) )
Good news :)

 >> How are the clock values for the splines of lathe/prism computed?
 > See source of lathe/prism.cpp for details.
Just took a quick look on the source. Right on top I find:

* Linear interpolation is used by default. In this case all n Points
* are used. In the quadratic case the first point is used to determine
* the derivates at the starting point P[1]. In the cubic case
* the first and last points are used to determine the derivatives at
* the starting point P[1] and ending point P[n-2].

This seems to differ again from the way the "other spline system" works 
(where the first point in a quadratic spline is not used for the 
derivate, but as another point on the curve). Didn't have to time go 
into that much further, though.
I also couldn't find the clock computations I was searching, but I'll 
dig into it later.

I *did* find something - Catmull-Rom-Splines. There is an interpolation 
function for them in splines.cpp. Are they broken or did someone forget 
to mention that they are available? ;)

Florian

Post a reply to this message

In article <40a25ac3$1@news.povray.org>,
 Florian Brucker <tor### [at] torfboldcom> wrote:

> Are the different approaches of the two spline systems (finding 
> intersections vs. finding vectors) really that much different that it is 
> not possible (or not desirable) to create a global spline system which 
> does both jobs?

The two applications are extremely different. Lathes and sors use the 
spline data to generate polynomial objects for each segment, 
intersection is tested against these polynomials. Splines just use the 
time value and interpolate the data to find a point. The data structures 
and algorithms used are quite different.
It would most likely be possible to generate lathes, sors, etc from the 
spline data, but doing so would take a fair amount of work. Using the 
splines to generate meshes would be quite easy, though.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

> The two applications are extremely different.
OK. But it would be possible to at least

1) make them use the same syntax
2) make them behave the same way

wouldn't it?

I'm talking about the end-user point of view here (not developper's 
one). I think it would be nice if you could, for example, use spline 
identifiers in lathes & prisms.

Perhaps it would be even possible to merge the two applications 
internally, and combine them in some class, which offers both 
calculations (intersection search and value search) while offering the 
possibility to use the class everywhere one needs a spline. I mean, 
those algorithms are already available in the source, so it is perhaps 
worth giving it a try (Although I admit that I don't know enough of POV 
internals to do it myself, so this is of course just a suggestion ^^). 
In that case, adding new spline types would be easier, too, because you 
would have to add them in one place, and not in two places with 
different data structures.

Florian

Post a reply to this message

On Fri, 14 May 2004 13:44:59 +0200, Florian Brucker <tor### [at] torfboldcom> wrote:
> > The two applications are extremely different.
> OK. But it would be possible to at least
>
> 1) make them use the same syntax
> 2) make them behave the same way
>
> wouldn't it?

Which summarizes to:

make them to represent the same "shape" for the same control points with the
same spline type.

> Perhaps it would be even possible to merge the two applications 
> internally, and combine them in some class, which offers both 
> calculations (intersection search and value search) while offering the 
> possibility to use the class everywhere one needs a spline.

Of course it is what everyone of us want. The problem is that it is not
possible in universal way from developer point of view. Spline doesn't have to
be mathematically defined in the meaning of n-order equation. I can imagine
spline type which takes two points for ends and creates
http://www.arrakis.es/~sysifus/img/ckoch.gif between them. Working on
intersection routine for it would be hard. Imo all we really need is
synchronized behaviour of the splines for types already implemented, and allow
new types only in spline{}. As mentioned, you still can create lathe-like mesh
from spline.

ABX

Post a reply to this message

ABX wrote:
> As mentioned, you still can create lathe-like
> mesh from spline.

Is there some macro for this purpose? The sides of the prism are trivial
of course, but the caps not quite as trivial...

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

On Sat, 15 May 2004 14:39:21 +0200, "Rune" <run### [at] runevisioncom> wrote:
> ABX wrote:
> > As mentioned, you still can create lathe-like
> > mesh from spline.
>
> Is there some macro for this purpose?

http://members.home.nl/seedseven/#lathe

> The sides of the prism are trivial
> of course, but the caps not quite as trivial...

It is even less trivial for all splines when written in C++

ABX

Post a reply to this message

ABX wrote:
> Rune wrote:
>> ABX wrote:
>>> As mentioned, you still can create lathe-like
>>> mesh from spline.
>>
>> Is there some macro for this purpose?
>
> http://members.home.nl/seedseven/#lathe
>
>> The sides of the prism are trivial
>> of course, but the caps not quite as trivial...
>
> It is even less trivial for all splines when
> written in C++

I think I must have been tired. In this whole thread only lathes and
sors have been mentioned, but in my head I was thinking prisms (which
are also based on splines). It is prisms that I think are non-trivial to
generate with a macro due to the end caps...

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

Sorry, generating meshes from splines is not trivial, especially when you
have a parametric surface with u = "clock value" and v going around the
spline.  The issue comes from finding a consistent "normal" vector to the
spline to start the mesh circle.  I tried using the standard normal to the
spline (2nd derivative) for this and the results were at best inconsistent,
often leading to a serious case of the "twisties" where the actual radius is
much less than planned.

What I ended up doing was taking an arbitrary normal vector to start with,
then projecting the unit normal point onto the normal plane at the next
point:

<code>
#macro pnt(i, j, p, q, spl)
 #if (j=vMin) // Calculate only at start of circle
  #declare _st = spl(i); // New start point
  #declare _dr = vnormalize(spl(i+1e-4)-spl(i-1e-4)); // New direction
vector
  #if (i=uMin) // Initialization, arbitrary start normal
   #local nrm = vcross(_dr,z);
   #if (vlength(nrm)<.1) #local nrm = vcross(_dr,x); #end // Insurance
against degenerate cross product
   #declare _norm = vnormalize(nrm);
  #else
   #local bas = _ost+_onrm; // get normal offset at old point
   #local prj = (bas+_dr*(vdot(_dr,_st)-vdot(_dr,bas))); // project onto
plane at new point, normal as new direction
   #declare _norm = vnormalize(prj-_st); // new normal traces from new point
to projected point
  #end
  #declare _onrm = _norm; // save old normal vector
  #declare _ost = _st; // save old point
  #declare _ortho = vcross(_dr,_norm); // orthonormal vector
 #end

 #local mrad = rad1*i+rad0*(uMax-i);
 #local irad = 0.85 + 0.10*sin(j*5) + q*.05;
 #local mdir = _norm*cos(j)+_ortho*sin(j);
 _st+mdir*mrad*irad
#end
</code>

For the end caps (i = uMin || i = uMax) just set the radius to 0.  If you
want flat rather than conical ends then set the endpoints just outside the
spline's range and push the endpoints back.

"Rune" <run### [at] runevisioncom> wrote in message
news:40a87c8b$1@news.povray.org...
> ABX wrote:
> > Rune wrote:
> >> ABX wrote:
> >>> As mentioned, you still can create lathe-like
> >>> mesh from spline.
> >>
> >> Is there some macro for this purpose?
> >
> > http://members.home.nl/seedseven/#lathe
> >
> >> The sides of the prism are trivial
> >> of course, but the caps not quite as trivial...
> >
> > It is even less trivial for all splines when
> > written in C++
>
> I think I must have been tired. In this whole thread only lathes and
> sors have been mentioned, but in my head I was thinking prisms (which
> are also based on splines). It is prisms that I think are non-trivial to
> generate with a macro due to the end caps...
>
> 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