Hello,

I think I understood how a prism with cubic_spline works: The first and last
point are controls points, and the second and second from last points needs to
be identical (P1 = P1), such as:

prism{cubic_spline 0, 1, 7, P0, P1, P2, P3, P4, P1, P5}

using the points P0 ... P5 I calculate in a loop using #declare ...
which, however, results in "Too few points in a prism"

If I substitute the point P1 as follows:

prism{cubic_spline 0, 1, 7, P0, <1,1>, P2, P3, P4, <1,1>, P5}

it works. has POV-Ray a problem with using predefined points instead of using
the
numerical value in the prism statement?

Thank you!

Post a reply to this message

Am 18.04.2016 um 17:37 schrieb Sereib:

> prism{cubic_spline 0, 1, 7, P0, P1, P2, P3, P4, P1, P5}
> 
> using the points P0 ... P5 I calculate in a loop using #declare ...
> which, however, results in "Too few points in a prism"

No error message here; and even if P1 is undefined or not a vector, the
error message I get is a different one.

Are you sure you're quoting the statement exactly as you used it?


If that's really what you're doing, then please post a self-contained
scene showing the error, and also let me know what version of POV-Ray
you are using.


> has POV-Ray a problem with using predefined points instead of using
> the numerical value in the prism statement?

No; that's entirely impossible, due to the way the parser is
implemented. In the parsing of the prism statement, the vectors are
parsed using the very same generic function to parse an arbitrary vector
expression that is used all over the place in the parser. Any problem
with that procedure would pop up everywhere, not just in the prism
statement.

Post a reply to this message

Le 18/04/2016 17:37, Sereib a écrit :
> Hello,
> 
> I think I understood how a prism with cubic_spline works: The first and last
> point are controls points, and the second and second from last points needs to
> be identical (P1 = P1), such as:
> 
> prism{cubic_spline 0, 1, 7, P0, P1, P2, P3, P4, P1, P5}
> 
> using the points P0 ... P5 I calculate in a loop using #declare ...
> which, however, results in "Too few points in a prism"
> 
> If I substitute the point P1 as follows:
> 
> prism{cubic_spline 0, 1, 7, P0, <1,1>, P2, P3, P4, <1,1>, P5}
> 
> it works. has POV-Ray a problem with using predefined points instead of using
> the
> numerical value in the prism statement?
> 
> Thank you!

Prism can have more than one loop/fold.

I can reproduce the issue with :

#declare P0=<0,0>;
#declare P1=<1,0>;
#declare P2=<2,1>;
#declare P3=P1;
#declare P4=<4,1>;
#declare P5=<5,0>;

prism{cubic_spline 0, 1, 7, P0, P1, P2, P3, P4, P1, P5}

Notice that the problem is between the keyboard and the chair: as P1 == P3, the first
line is closed and stop at P3,P4.
P1,P5 is another prism (control at P1, first point at P5) but we are lacking points.
A non flat cubic_spline prism should have at least about 6 coordinates: 1 first
control point, 1 start point, at least 2 non aligned other points (with start point),
and repeating start point, and finally a control point for the end.

Of course, you can nest another closed curve (to perform prism operation) in the
definition. As soon as the start point is duplicated, the curve is closed, the next
point is a control, the next-next is the control of the next curve and the third next
is the start of the
new curve which need to be closed too...

http://wiki.povray.org/content/Reference:Prism

Post a reply to this message

Am 18.04.2016 um 18:52 schrieb Le_Forgeron:

> Prism can have more than one loop/fold.
> 
> I can reproduce the issue with :
> 
> #declare P0=<0,0>;
> #declare P1=<1,0>;
> #declare P2=<2,1>;
> #declare P3=P1;
> #declare P4=<4,1>;
> #declare P5=<5,0>;
> 
> prism{cubic_spline 0, 1, 7, P0, P1, P2, P3, P4, P1, P5}
> 
> Notice that the problem is between the keyboard and the chair:

Hm... I don't think it's that easy. A reasonable case can be made for
single loops with coincident control points; think e.g. of an hourglass
shape in an animation, where the narrow portion is supposed to reach
zero in one frame. The case is even easier to make for Bezier splines.

So I think we should consider this a flaw in the prism syntax, and think
of how this could be remedied.

One possible solution would be to introduce an alternative syntax like so:

    prism {
      cubic_spline 0, 1
      loop { 7, P0, P1, P2, P3, P4, P1, P5 }
    }

This would make it clear that a single loop is desired, even if control
points match. Obviously, multiple loops would be specified using
multiple "loop" blocks.

Lathe should get the same extended syntax of course.

Post a reply to this message

Le 19/04/2016 15:58, clipka a écrit :
> Am 18.04.2016 um 18:52 schrieb Le_Forgeron:
> 
>> Prism can have more than one loop/fold.
>>
>> I can reproduce the issue with :
>>
>> #declare P0=<0,0>;
>> #declare P1=<1,0>;
>> #declare P2=<2,1>;
>> #declare P3=P1;
>> #declare P4=<4,1>;
>> #declare P5=<5,0>;
>>
>> prism{cubic_spline 0, 1, 7, P0, P1, P2, P3, P4, P1, P5}
>>
>> Notice that the problem is between the keyboard and the chair:
> 
> Hm... I don't think it's that easy. A reasonable case can be made for
> single loops with coincident control points; think e.g. of an hourglass
> shape in an animation, where the narrow portion is supposed to reach
> zero in one frame. The case is even easier to make for Bezier splines.
> 
> So I think we should consider this a flaw in the prism syntax, and think
> of how this could be remedied.

It's only the first point of the curve which is special.

If you expect the prism to have a concentration of points, do not choose that region
for the first point.

Post a reply to this message

Am 19.04.2016 um 19:47 schrieb Le_Forgeron:
> Le 19/04/2016 15:58, clipka a écrit :
>> Am 18.04.2016 um 18:52 schrieb Le_Forgeron:
>>
>>> Prism can have more than one loop/fold.
>>>
>>> I can reproduce the issue with :
>>>
>>> #declare P0=<0,0>;
>>> #declare P1=<1,0>;
>>> #declare P2=<2,1>;
>>> #declare P3=P1;
>>> #declare P4=<4,1>;
>>> #declare P5=<5,0>;
>>>
>>> prism{cubic_spline 0, 1, 7, P0, P1, P2, P3, P4, P1, P5}
>>>
>>> Notice that the problem is between the keyboard and the chair:
>>
>> Hm... I don't think it's that easy. A reasonable case can be made for
>> single loops with coincident control points; think e.g. of an hourglass
>> shape in an animation, where the narrow portion is supposed to reach
>> zero in one frame. The case is even easier to make for Bezier splines.
>>
>> So I think we should consider this a flaw in the prism syntax, and think
>> of how this could be remedied.
> 
> It's only the first point of the curve which is special.
> 
> If you expect the prism to have a concentration of points, do not choose that region
for the first point.

What if it isn't known beforehand what points will coincide?
What if there's some external tool generating the points, and the user
of that tool isn't aware of this limitation?

I'm sure we /can/ make the syntax safer in this respect, with reasonable
effort, so I think we /should/ do that.

Post a reply to this message

Le 16-04-19 16:00, clipka a écrit :

> What if it isn't known beforehand what points will coincide?
> What if there's some external tool generating the points, and the user
> of that tool isn't aware of this limitation?
>
> I'm sure we /can/ make the syntax safer in this respect, with reasonable
> effort, so I think we /should/ do that.
>

I agree that a syntax change that make things more predictable, safer or 
clearer is a thing to do.
I like your loop structure proposal. Simple and intuitive.


Alain

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 19.04.2016 um 19:47 schrieb Le_Forgeron:

> >
> > It's only the first point of the curve which is special.
> >
> > If you expect the prism to have a concentration of points, do not choose that
region for the first point.
>
> What if it isn't known beforehand what points will coincide?
> What if there's some external tool generating the points, and the user
> of that tool isn't aware of this limitation?
>
> I'm sure we /can/ make the syntax safer in this respect, with reasonable
> effort, so I think we /should/ do that.

Really, in case of animation any point can repeat randomly.
The user can't foresee or count (to calculate).
And, it will give an error message.
Loop - a good solution.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

> Hm... I don't think it's that easy. A reasonable case can be made for
> single loops with coincident control points; think e.g. of an hourglass
> shape in an animation, where the narrow portion is supposed to reach
> zero in one frame. The case is even easier to make for Bezier splines.

It's been too long since I've used a prism, and I'm too tired to follow what you
mean.  In lieu of crayons and sock-puppets, a simple scene or picture will do.

By loops, I assume you mean a way to explicitly split out discrete "parts" of
the prism that may be nested or overlapping.

Post a reply to this message