 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/7/25 12:10, Bald Eagle wrote:
> According to the sor {} tutorial in the wiki:
> https://wiki.povray.org/content/
> Documentation:Tutorial_Section_3#Surface_of_Revolution_Object
> "First and last point from the list are used to determine slope at beginning and
> end of curve and can be defined for any height."
>
> However, I find that to not be the case.
> Swapping the first and last control points causes a
> "Parse Error: Incorrect point in surface of revolution"
> But if I only set the LAST control point y value to zero, technically making the
> spline double-back in the y-direction, everything works fine.
First, Are you using v3.8 beta 2 for all your testing?
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?
As to the point above, I don't see what you see. The following list
works for me where I have flipped / crossed the first and last control
points(*). See the attached image where the first is magenta and the
last is yellow.
<+1.5,+1.1> // C0
<+0.4,0.0> // C1
<+0.3,0.5> // C2
<+0.4,0.9> // C3
<+1.5,+0.1> // C4
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.
(*) 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.
Bill P.
Post a reply to this message
Attachments:
Download 'be_sor01.png' (12 KB)
Preview of image 'be_sor01.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/8/25 07:08, Bald Eagle wrote:
> "Bald Eagle" <cre### [at] netscape net> wrote:
>
>> As shown, when I use cutaway_textures, I DON'T see the expected
>> interior_texture, but the surface texture {}. And when I use sor {open}, I do
>> not see a hollow infinitely thin surface, I get a solid object sliced in half.
>
> Also, I'm curious as to why the cutaway_textures feature requires the use of an
> untextured object as a cutter to be able to function properly.
> One would reasonably expect that we should be able to use any object.
> If, as per wiki documentation, the cutaway_textures feature result is based on
> insidedness tests, then the texture of the cutter should be irrelevant.
>
> - BE
>
>
>
Answering without thinking much, I don't think the cutaway_textures
feature copies the inside texture(*), but maybe I'm not remembering
correctly.
A reminder the yuqk fork fixed a cutaway_textures bug which exists in
official POV-Ray releases. See:
https://news.povray.org/povray.bugreports/thread/%3C65806257%241%40news.povray.org%3E/
Bill P.
(*) - The inside_texture{}s feature has a few inconsistencies, besides,
with respect to how texture{}s are handled.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/8/25 10:04, William F Pokorny wrote:
> Answering without thinking much,
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 ?
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] anonymousorg> 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
|
|
| |
| |
|
|
|
|
| |
|
|
