 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/8/25 09:52, William F Pokorny wrote:
> I'll try and look at some of the other issues you mention as I have
> time; Including temporarily removing the x>0.0 restriction on the first
> and last points to see what happens. Aside: we did remove a similar
> restriction for the lathe for v3.8 vs v3.7.
Well, the current code drops portions of the curve that get pulled into
x<0 territory by control points x<0. See attached image.
Might be fixable / map-able to x>=0 as you, I think, were suggesting
with the abs() comment. It might even acceptable as a final result, IF,
the inside tests, normal calculations and uv mapping code map in a sane
way to the result.
Thinking aloud, it might be possible to allow x<0 control points - ONLY
- where both on curve points and off curve control points are forced to
be always ascending (>= previous) in y. This, probably, would cover the
'useful' x<0 control point cases while preventing the curve from
crossing into -x? I'll try to play with this thought some more when I
again have time - need to run.
Bill P.
Post a reply to this message
Attachments:
Download 'be_sor02.png' (5 KB)
Preview of image 'be_sor02.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
William F Pokorny <ano### [at] anonymous org> wrote:
> First, Are you using v3.8 beta 2 for all your testing?
Probably. Will confirm when I get home.
> Second, Did you take care when you did the differences with the box to
> not have coincident surfaces with the caps (if there) or that y height
> when the caps are not there?
Yeah, I have an E value set that I routinely use to avoid CS.
I had the caps present when I skipped adding/subtracting that, and then when I
fixed it, the caps went away.
> (*) I tried inverting all the on curve points and this does NOT work as
> I incorrectly remembered for some recent sor{} post - that must be a
> lathe{} only thing.
Right, because sor is an implicit interpolation, and lathe is a parametric
interpolation.
Thanks for checking on these. Will compare notes when I get back later.
- BW
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
William F Pokorny <ano### [at] anonymousorg> wrote:
> Ah, and to quote Alain:
>
> "When using cutaway_texture, the object used to cut away part of the
> rest must NOT have any texture."
>
> Unsure your set up with respect to the particular post, but the overall
> images suggest both the box and sor might have textures ?
I initially did leave the textures attached to the objects when first doing the
differences, but my code is such that it was easy to leave them textureless for
use with cutaway_textures, so no, that doesn't appear to be the problem.
Will post the scene file when I get out of here in an hour.
With regard to c_t not using interior_texture, that seems to be a reasonably
expected behaviour, and one which I'd have to think hard about how to code a
workaround for.
I also had that recent scene where I was getting washed-out colors, and I really
don't believe that I have any overlapping objects, however I will have to make a
detailed check to be absolutely sure.
- BW
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
using
3.8.0-beta.2+gh7.msvc14.win64
scene file attached
Post a reply to this message
Attachments:
Download 'sor permutations.pov.txt' (6 KB)
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/8/25 11:10, William F Pokorny wrote:
> Thinking aloud, it might be possible to allow x<0 control points - ONLY
> - where both on curve points and off curve control points are forced to
> be always ascending (>= previous) in y. This, probably, would cover the
> 'useful' x<0 control point cases while preventing the curve from
> crossing into -x? I'll try to play with this thought some more when I
> again have time - need to run.
I spent some time on this idea and, on seeing some issues where entire
segments would just blink out of existence, I went back to trying more
parser legal point sets and found similar weirdness. :-(
There exists internal cylinder bounding of segments intended to reduce
the number of calls to the solvers. My guess is that code isn't
completely solid, but who knows.
Attached an image where the top row uses the currently legal point set of:
<+1.5,-0.01> // C0
<+0.4, 0.0> // P1
<+0.3, 0.5> // P2
<+0.4, 0.9> // P3
<+1.5,+0.91> // C4
and the shape breaks apart(a)(b). In the bottom row I changed that last
control point to:
<+1.5,+0.901> // C4
and the entire top segment drops out.
So yep...
Bill P.
(a) Curve going negative can already happen without negative control
points.
(b) In yuqk the parts of the sor there all look good. In v3.8 beta 2,
the results for top segment are noisy; Likely solver differences.
Post a reply to this message
Attachments:
Download 'sor_oddness.png' (22 KB)
Preview of image 'sor_oddness.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/8/25 14:06, Bald Eagle wrote:
>> (*) I tried inverting all the on curve points and this does NOT work as
>> I incorrectly remembered for some recent sor{} post - that must be a
>> lathe{} only thing.
...> Right, because sor is an implicit interpolation, and lathe is a
parametric
> interpolation.
Unsure. With the lathe the reason to flip the point set order is to flip
the normals (and perhaps too textures on parts of the resulting shape). Ref:
https://news.povray.org/povray.binaries.images/thread/%3C5745b756%241@news.povray.org%3E/
I see no reason this couldn't be true for the sor too - even if all that
happens internally is normalizing the decreasing point during parsing
and setting a flag to flip the normals.
That said. When I relaxed the parser's sanity checking so I could try
and render the reversed point set I got no sor result. Given other
discoveries this morning this might also be related to segments simply
dropping out due how the internal cylinder bounding is being done. I
don't know. I don't know. I don't know.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
William F Pokorny <ano### [at] anonymousorg> wrote:
> On 9/8/25 14:06, Bald Eagle wrote:
> >> (*) I tried inverting all the on curve points and this does NOT work as
> >> I incorrectly remembered for some recent sor{} post - that must be a
> >> lathe{} only thing.
> ...> Right, because sor is an implicit interpolation, and lathe is a
> parametric
> > interpolation.
>
> Unsure. With the lathe the reason to flip the point set order is to flip
> the normals (and perhaps too textures on parts of the resulting shape). Ref:
>
>
https://news.povray.org/povray.binaries.images/thread/%3C5745b756%241@news.povray.org%3E/
Yes, but this is not what I'm talking about.
I'm not trying to reverse the order of the entire point set, (which _ought_ to
be a valid point set for the sor - I think it's just "lazily" coded to check in
one direction - I think it could easily check for points going sequentially in
either direction) I'm just trying to use ANY value for either the first or last
control point to change the tangent direction at the endpoints.
> I see no reason this couldn't be true for the sor too - even if all that
> happens internally is normalizing the decreasing point during parsing
> and setting a flag to flip the normals.
Yes, but even if we still just had the current sor monotonically increasing in
y, we could just switch texture and interior_texture to achieve the same result.
But I agree that given your point, sor could really use a much more in-depth
investigation and possible/probable recoding.
With regard to the abs() implementation, that was only to be applied to the r
result of the sor, so that anything that crossed the rotation axis would be a
valid control point. I just didn't see why a mirror-image control point would
be invalid.
> That said. When I relaxed the parser's sanity checking so I could try
> and render the reversed point set I got no sor result. Given other
> discoveries this morning this might also be related to segments simply
> dropping out due how the internal cylinder bounding is being done.
I skimmed over the internal bounding part, but can try to devote some more time
to verifying what it does and how.
One thing that I noticed with going over the source code several different
objects is that we have a repetition of spline code - why don't we have all the
splines in one place and use them as the basis for all the various objects that
use them?
Simplifying things like that would make sure that the splines are consistent
between the various objects, and potentially open up the ability to use
user-defined spline interpolations for defining the outline of the objects.
- BW
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
William F Pokorny <ano### [at] anonymousorg> wrote:
> <+1.5,+0.91> // C4
>
> and the shape breaks apart(a)(b). In the bottom row I changed that last
> control point to:
>
> <+1.5,+0.901> // C4
>
> and the entire top segment drops out.
Looking at the code, I'd say that either it's the solver or the EPSILON value -
or both. That's definitely a weird result, and you have an excellent sense for
employing good incidental test cases.
I'd say that this is the kind of thing where more extensive diagramming of the
actual control points and cubic spline would be helpful, and maybe have a grid
of sor {} objects with varying control points.
I have a bit of trouble putting all of the pieces in sor.cpp together to see how
all of the data flows in order to make the actual sor on-screen. If you could
explain that briefly, that would be a huge help in my ongoing investigations and
debugging.
Do you see anywhere that the code would simply not render the surface? Any way
to indicate to the user that it does such a thing?
> (b) In yuqk the parts of the sor there all look good. In v3.8 beta 2,
> the results for top segment are noisy; Likely solver differences.
In the source:
Where is "Number" defined?
Where is EPSILON defined?
Some things I've noticed and am confused by:
In void Sor::Compute_Sor(Vector2d *P, RenderStatistics& stats) [Line 960]
starting at line 1003, we have:
for (i = 0; i < Number; i++)
{
if ((fabs(P[i+2][Y] - P[i][Y]) < EPSILON) ||
(fabs(P[i+3][Y] - P[i+1][Y]) < EPSILON))
{
throw POV_EXCEPTION_STRING("Incorrect point in surface of
revolution.");
}
which is the only check that throws that error, and because it uses fabs (),
that doesn't actually check for the control points doubling back on themselves,
it seems like that's a check to make sure the tangent doesn't have a slope of
zero.
Now, moving down to line 1078, we have:
while (n--)
{
if ((r[n] >= y[0]) && (r[n] <= y[1]))
{
x[n] = sqrt(r[n] * (r[n] * (r[n] * A + B) + C) + D);
}
}
and I'm confused as to why r is getting compared to the y value and not the x
value. It seems that the radius ought to be compared to the control point x
values - unless I'm missing something.
Also, as far as I'm aware, the Catmull-Rom spline doesn't have as well-defined a
control polygon as a Bezier spline does, and so I'm wondering if there needs to
be a better bounding estimate for the min and max values.
So something that's been bouncing around the ole' noggin but I haven't yet
articulated is:
If we interpolate a spline with entirely valid control points, but the
interpolated part winds up crossing the rotation axis - what happens?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
> Now, moving down to line 1078, we have:
> while (n--)
> {
> if ((r[n] >= y[0]) && (r[n] <= y[1]))
> {
> x[n] = sqrt(r[n] * (r[n] * (r[n] * A + B) + C) + D);
> }
> }
>
> and I'm confused as to why r is getting compared to the y value and not the x
> value. It seems that the radius ought to be compared to the control point x
> values - unless I'm missing something.
This is because good ole' Dieter likes to mix and match labels between the
comments and the code.
r here is the array of roots found by the polynomial solver, not the radius of
the sor at that height (which is x). So we're just checking to make sure we're
testing between the roots. Still need to see why the roots bracket a spline
segment . . .
- BW
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
William F Pokorny <ano### [at] anonymousorg> wrote:
.... how the internal cylinder bounding is being done. I
Check out Fig. 5, pg 11
https://www.cemyuksel.com/research/catmullrom_param/catmullrom_cad.pdf
We might have better luck if we changed how the bounding is done.
It also shows how I can create a set of control points where the curve
overshoots the control point polygon, and so I can use that to have the
interpolated curve cross over the rotation axis to see what happens.
I'll make a speculative prediction and say that the algorithm will try to take
the sqrt of that negative radius and fail - either throwing an error, or just
blanking out that portion of the curve - or the whole segment.
I'll probably have to convert most of the solver code to SDL and then use what I
get out of that to start to answer some other questions.
- BW
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
