 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
lathe { bezier_spline 8,
<0,1><0.25,0.75><-0.07594,0.5><0.1875,0.1875>
<0.1875,0.1875><0.3929,-0.05616><0,-0.5><0,-1>
}
File '/tmp/Empty.pov' line 17: Parse Error: Incorrect point in lathe.
Fatal error in parser: Cannot parse input.
Render failed
I can't appropriate to control point the negative value...
Why?????
To set the necessary form, I need a negative value!
At the same time the curve doesn't cross null value...
Look attachment:
Post a reply to this message
Attachments:
Download 'lathe.jpg' (27 KB)
Preview of image 'lathe.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 02.05.2016 um 13:56 schrieb LanuHum:
> lathe { bezier_spline 8,
> <0,1><0.25,0.75><-0.07594,0.5><0.1875,0.1875>
> <0.1875,0.1875><0.3929,-0.05616><0,-0.5><0,-1>
> }
>
> File '/tmp/Empty.pov' line 17: Parse Error: Incorrect point in lathe.
> Fatal error in parser: Cannot parse input.
> Render failed
Please do me a favor and file a bug report on
https://github.com/POV-Ray/povray/issues -- this is probably not the
right behaviour for Bezier splines, and while I currently don't have the
time to address this, I don't want it to get lost in time.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 05/02/2016 07:56 AM, LanuHum wrote:
> lathe { bezier_spline 8,
> <0,1><0.25,0.75><-0.07594,0.5><0.1875,0.1875>
> <0.1875,0.1875><0.3929,-0.05616><0,-0.5><0,-1>
> }
>
> File '/tmp/Empty.pov' line 17: Parse Error: Incorrect point in lathe.
> Fatal error in parser: Cannot parse input.
> Render failed
>
>
> I can't appropriate to control point the negative value...
> Why?????
> To set the necessary form, I need a negative value!
> At the same time the curve doesn't cross null value...
>
> Look attachment:
>
The issue looks to be this code in the parser for the lathe object :
for (i = 0; i < Object->Number; i++)
{
Parse_Comma();
Parse_UV_Vect(Points[i]);
if ((i > 0) && (i < Object->Number - 1) &&
(Points[i][X] < 0.0))
{
Error("Incorrect point in lathe.");
}
}
which is written in a way which does not allow the bezier control points
to swing to minus x while making some allowance for other curve's
control points.
In other words I think it is testing the control points and not the
fixed end points in each of the bezier curve segments.
Probably simple enough I could attempt a fix... Needs a conditional
based on whether we have bezier curve I think. If someone else is going
after a fix please speak up, otherwise I'll step up and try for one.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 02.05.2016 um 14:57 schrieb William F Pokorny:
> The issue looks to be this code in the parser for the lathe object :
That is indeed the location in the code that rejects the negative value.
> Probably simple enough I could attempt a fix... Needs a conditional
> based on whether we have bezier curve I think. If someone else is going
> after a fix please speak up, otherwise I'll step up and try for one.
I would want more to be done than just address the symptoms (in this
case a negative control point value being rejected): First thing to be
done should be some thorough testing...
- whether the bezier-type lathe can actually deal with negative
off-curve control points (I expect it can, but that's not necessarily a
given);
- whether the bezier-type lathe can live with negative on-curve control
points (I wouldn't be too surprised if it actually can); and
- whether any of the other types of lathe can live with negative control
points (I would expect them to react the same as the bezier type does
with on-curve points, but that's not a given either).
Once that's established, the parser code should be adapted accordingly.
Also, if it turns out that the bezier-type lathe is fine with negative
off-curve control points but not on-curve control points, some thought
and possibly effort should be put into the case that some off-curve
points are so far in the negative regime that the resulting curve gets
pulled across the axis of revolution.
That's the reason why I'm not tackling this issue straight away myself.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 05/02/2016 09:58 AM, clipka wrote:
> Am 02.05.2016 um 14:57 schrieb William F Pokorny:
>
>> The issue looks to be this code in the parser for the lathe object :
>
> That is indeed the location in the code that rejects the negative value.
>
>> Probably simple enough I could attempt a fix... Needs a conditional
>> based on whether we have bezier curve I think. If someone else is going
>> after a fix please speak up, otherwise I'll step up and try for one.
>
> I would want more to be done than just address the symptoms
Understand. I too recognize more that just the testing of on curve
points for the bezier curve was wrong in what we have today.
Namely it is wrong/incomplete for other curve types too. My initial code
update is this for on curve point test :
switch (Object->Spline_Type)
{
case LINEAR_SPLINE :
if (Points[i][X] < 0.0)
{
Error("Lathe with linear spline
has a point with an x value < 0.0.");
}
break;
case QUADRATIC_SPLINE :
if ((i > 0) && (Points[i][X] < 0.0))
{
Error("Lathe with quadratic
spline has a point with an x value < 0.0.");
}
break;
case CUBIC_SPLINE :
if ((i > 0) && (i < Object->Number - 1)
&& (Points[i][X] < 0.0))
{
Error("Lathe with cubic spline
has a point with an x value < 0.0.");
}
break;
case BEZIER_SPLINE :
if (((i%4 == 0) || (i%4 == 3)) &&
(Points[i][X] < 0.0))
{
Error("Lathe with Bezier spline
has a point with an x value < 0.0.");
}
break;
}
Which seems to be doing the right sort of testing depending on curve
type in forcing on curve points to be >=0 in x.
Thanks for the testing ideas below. Some I'd thought of or believe I've
done in the past, some not.
Rambling I suspect too, both negative control and on curve points will
run - though us users might well be confused by any result if really true.
If the developers want to allow this, I suppose deleting the current
check is the way to go instead.
In any case for the moment, let me test the cases below with all parser
checking off for the different curve types & I will report the results
here.
> (in this
> case a negative control point value being rejected): First thing to be
> done should be some thorough testing...
>
> - whether the bezier-type lathe can actually deal with negative
> off-curve control points (I expect it can, but that's not necessarily a
> given);
>
> - whether the bezier-type lathe can live with negative on-curve control
> points (I wouldn't be too surprised if it actually can); and
>
> - whether any of the other types of lathe can live with negative control
> points (I would expect them to react the same as the bezier type does
> with on-curve points, but that's not a given either).
>
> Once that's established, the parser code should be adapted accordingly.
>
> Also, if it turns out that the bezier-type lathe is fine with negative
> off-curve control points but not on-curve control points, some thought
> and possibly effort should be put into the case that some off-curve
> points are so far in the negative regime that the resulting curve gets
> pulled across the axis of revolution.
>
If we get into this kind of pre-evaluation of the curves, I'll probably
bail. :-)
>
> That's the reason why I'm not tackling this issue straight away myself.
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 02.05.2016 um 16:37 schrieb William F Pokorny:
> Rambling I suspect too, both negative control and on curve points will
> run - though us users might well be confused by any result if really true.
>
> If the developers want to allow this, I suppose deleting the current
> check is the way to go instead.
How about retaining your work, and simply issuing a warning instead of
an error? (presuming the downstream code is ok with the values of
course, otherwise an error is the right thing)
> In any case for the moment, let me test the cases below with all parser
> checking off for the different curve types & I will report the results
> here.
You're more than welcome.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymous org> wrote:
> Am 02.05.2016 um 13:56 schrieb LanuHum:
> > lathe { bezier_spline 8,
> > <0,1><0.25,0.75><-0.07594,0.5><0.1875,0.1875>
> > <0.1875,0.1875><0.3929,-0.05616><0,-0.5><0,-1>
> > }
> >
> > File '/tmp/Empty.pov' line 17: Parse Error: Incorrect point in lathe.
> > Fatal error in parser: Cannot parse input.
> > Render failed
>
> Please do me a favor and file a bug report on
> https://github.com/POV-Ray/povray/issues -- this is probably not the
> right behaviour for Bezier splines, and while I currently don't have the
> time to address this, I don't want it to get lost in time.
I left you a reminder:
https://github.com/POV-Ray/povray/issues
:)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I have always wondered what the big deal about negative values was, since once
it gets revolved 180 degrees, it's the positive value.
Can the on-curve points simply be redefined to be positive?
on_curve[n] = abs(original_curve[n]) ?
I could of course, be way off base with this.
The pre-evaluation of the on-curve points for things like Bezier curves would be
an extra subroutine and parser hog, but probably shouldn't be too bad unless
there were a lot of such objects to evaluate.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> Can the on-curve points simply be redefined to be positive?
> on_curve[n] = abs(original_curve[n]) ?
No,no.
In bezier only 4 control points (P0,P1,P2,P3)
P0,P3 belong a curve, P1 of P2 don't belong a curve.
If P1 = (-2,2), they won't be replaced by a point (2,2).
Other curve will turn out absolutely.
In order that all points of a curve were in positive coordinates, not
necessarily that P1 and P2 also were in positive coordinates.
In the case provided by me the ideal surface of revolution shall turn out.
Restriction from povray is unjustified.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 05/02/2016 11:02 AM, clipka wrote:
> Am 02.05.2016 um 16:37 schrieb William F Pokorny:
>
>> Rambling I suspect too, both negative control and on curve points will
>> run - though us users might well be confused by any result if really true.
>>
>> If the developers want to allow this, I suppose deleting the current
>> check is the way to go instead.
>
> How about retaining your work, and simply issuing a warning instead of
> an error? (presuming the downstream code is ok with the values of
> course, otherwise an error is the right thing)
Yes, this looking like it might be an option.
>
>> In any case for the moment, let me test the cases below with all parser
>> checking off for the different curve types & I will report the results
>> here.
>
> You're more than welcome.
>
OK some test results from negative lathe spline values with the current
parse checking off. All splines used have 4 points.
The four rows, top to bottom, are linear, quadratic, cubic and bezier
splines respectively.
The columns 1-7 are:
0 - All X coordinates are positive.
1 - All X coordinates are negative.
2 - All X coordinates are 0.
3 - First point's X coordinate is negative.
4 - Second point's X coordinate is negative.
5 - First and second point's X coordinates negative.
6 - Second and third point's X coordinates negative.
7 - Third and fourth point's X coordinates negative.
I think I covered all the cases somewhat, but if not let me know.
To my eyes we get what one might expect(1) with negative coordinates, so
running with better warnings or no checking at all of the points in the
spline is probably OK.
Bill P.
(1)- except perhaps that quadratic is a bit noisy, but probably it is
not much used.
Post a reply to this message
Attachments:
Download 'orthographic.jpg' (85 KB)
Download 'perspective.jpg' (80 KB)
Preview of image 'orthographic.jpg'
Preview of image 'perspective.jpg'
|
|
| |
| |
|
|
|
|
| |
|
|
