 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Same renderings, but of sor {open}
Post a reply to this message
Attachments:
Download 'sor open permutations.png' (133 KB)
Preview of image 'sor open permutations.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] netscapenet> 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'
|
|
| |
| |
|
|
|
|
| |
|
|
