The bug fixes(a) and control point relaxations for the sor{} in the next 
yuqk release were discussed in the thread:

https://news.povray.org/povray.documentation.inbuilt/thread/%3Cweb.689b6c79e72c05b2bc0c1c5925979125%40news.povray.org%3E/

The next yuqk release is also adding two new keywords to the sor{}. One 
is 'caps' and the other is 'intervals'.

The caps changes align what was done for yuqk's text{} update:

https://news.povray.org/povray.pov4.discussion.general/thread/%3C67e41261%241%40news.povray.org%3E/

The intervals keyword is followed by a string of 0 and 1 values which 
allow particular sor{} curve segments to be kept or not.

The middle image row used:

     intervals "10101"

which, left to right, indicates only the first, third and fifth of the 
five total sor{} segments are to be used.

The idea with both 'caps' and 'intervals' is to add inbuilt ways for the 
sor{} to be broken apart and the pieces textured, used in CSG or for 
debug and modeling.

The second row rotates the sor by -10*x and the third row by -45*x to 
better see the sor segments and caps, respectively.

Bill P.

(a) - Except for adjusting an older yuqk update removing the 
too-generic, single value EPSILON use in the sor code. In recent testing 
I found cases - like in the attached image - with tight, segment turns 
where those A,B,C,D internal values needed to be zeroed at closer to the 
old official POV-Ray EPSILON of 1e-10. I settled specifically on 
4.4e-12, but things are being fudged here - so we'll see how the newer, 
new zeroing limit holds up.

Post a reply to this message

Attachments:
Download 'sor_v4_suggest.png' (41 KB)

Preview of image 'sor_v4_suggest.png'

On 9/15/25 19:49, William F Pokorny wrote:
> The bug fixes(a) and control point relaxations for the sor{}...

Attached another image. Here in the top row showing inverted in y, 
positive in x control points - which are already legal in POV-Ray today.

The middle row shows negative in x, not inverted / flipped, control 
points as Bill W suggested be supported for the sor{}.

The bottom row shows the difference in result.

Bill P.

Post a reply to this message

Attachments:
Download 'sor_v4_suggest_cntlneg.png.jpg' (13 KB)

Preview of image 'sor_v4_suggest_cntlneg.png.jpg'

On 9/15/25 19:49, William F Pokorny wrote:
> The idea with both 'caps' and 'intervals' is to add inbuilt ways for the 
> sor{} to be broken apart and the pieces textured, used in CSG or for 
> debug and modeling.

An additional change with the sor{} for R20 of yuqk is to allow sor 
references to existing sor identifiers - while permitting changes to the 
caps, open and intervals keyword settings(*). In other words, today, if 
you want two sor shapes where the only difference is the open setting, 
you have to create two complete sor{} blocks including the point list 
and the 'open' keyword or not.

It is the case today that using sor { Sor00 } is no different than 
object { Sor00 } in that both allow only differing object modifiers 
within the braces after the sor identifier.

There is also no type checking the identifier reference matches the type 
of the block wrapper itself. While the debug compile of yuqk has already 
implemented some type checking for text{} and ???, R20 of yuqk will 
always verify the ID type for the updated sor{}. It must to enable the 
keyword settings of a referenced sor ID to later be modified.

Attached an image and the scene file used to create the four sub images.

Bill P.

(*) - I thought I had the code for this in hand a week ago, but nope. I 
believe I've now got a clean implementation...

Post a reply to this message

Attachments:
Download 'parsingchanges01.pov.txt' (4 KB) Download 'parsingchanges.png' (71 KB)

Preview of image 'parsingchanges.png'

[Running v3.8 beta 2 in Windows 10]

[Off-topic:]

Out of curiosity, I ran your code example (while eliminating your yuqk-specific
additions), just to see what the results would be.

I noticed that you use the 'intervals' keyword in your SOR objects. In the
current official POV-ray syntax, that keyword is used only for media. In your
yuqk fork, have you eliminated that keyword usage in your SDL media code, so
that it only applies to an SOR shape now? Or has yuqk's media 'intervals' been
changed to some other word, perhaps?

Just curious. :-D

Post a reply to this message

On 9/21/25 10:35, Kenneth wrote:
> I noticed that you use the 'intervals' keyword in your SOR objects. In the
> current official POV-ray syntax, that keyword is used only for media. In your
> yuqk fork, have you eliminated that keyword usage in your SDL media code, so
> that it only applies to an SOR shape now? Or has yuqk's media 'intervals' been
> changed to some other word, perhaps?

The 'intervals' keyword is still there for media{} in yuqk and so it's 
added to the group of keywords with more than one meaning(*).

I was first going to add a new keyword called 'segments' for this new 
functionality, but with the sor{} it's defining interior sub-regions 
alongside the 'surface segments'(**).

I've got hooks in place to add this kind of functionality to the 
lathe{}. There it might make more sense to use 'segments'. Unlike the 
sor{}, the interior regions cannot be cleanly broken up. With the 
lathe{}, the spline can fold back on itself - the inside is set by the 
whole spline.

In any case, the keyword 'intervals', like the functionality it enables, 
is at this point a v4.0 suggestion; something to play with. :-)

Bill P.

(*) - I have mostly been de-layering keyword meanings in yuqk. 
Introducing ip_ and it_ prefixes for pattern/perturbation and turbulence 
related keywords, respectively. This work fixes a number of bugs caused 
by keyword context overlaps in our official POV-Ray code.

There is too already a smaller ii_ prefix set for input/internal image 
keywords. I'm still thinking about other keyword prefix groupings like 
is_ for internal shape keywords; il_ for internal light_source keywords; 
ic_ for internal camera keywords; im_ for internal media keywords. We'll 
see.

(**) Functionality which makes the sor{} more useful as a csg helper 
function / shape. Functionality which opens up the ability to use on 
curve points as effective control points in the middle of the sor{} 
spline. Functionality which better enables two or more sor{} shapes to 
create off y axis surfaces of revolution with well defined inside regions.

In short, I'm coming away from this look/update of the sor{} thinking 
the it might be more useful than I originally thought!

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
>
> The 'intervals' keyword is still there for media{} in yuqk and so it's
> added to the group of keywords with more than one meaning(*).
>
> [snip]
> In any case, the keyword 'intervals', like the functionality it enables,
> is at this point a v4.0 suggestion; something to play with. :-)
>

Oops, I *just* read your earlier thread which explains your 'intervals' use:

https://news.povray.org/povray.pov4.discussion.general/message/%3C68c8a619%241%40news.povray.org%3E/#%3C68c8a619%241%40
news.povray.org%3E

My apologies for not seeing that before I posted here :-/

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 9/21/25 10:35, Kenneth wrote:
> > I noticed that you use the 'intervals' keyword in your SOR objects. ...
>
> The 'intervals' keyword is still there for media{} in yuqk and so it's
> added to the group of keywords with more than one meaning(*).
> ...
> In any case, the keyword 'intervals', like the functionality it enables,
> is at this point a v4.0 suggestion; something to play with. :-)

v confusing.  intervals (media) is a numeric value, your sor{} ones are string
values.  how do those 5-char strings relate to the 8-element/point arrays ?

on topic "sor{}" - is it "hollow" or "solid" as suggested ?  (I have an email
thread "stalled" on this question :-))


regards, jr.

Post a reply to this message

On 9/21/25 13:44, jr wrote:
> v confusing.  intervals (media) is a numeric value, your sor{} ones are string
> values.  how do those 5-char strings relate to the 8-element/point arrays ?

Documentation needs to be created. :-) A quick answer is that the number 
of spline-segments for the sor{} is always 3 less than the number of 
points specified. The length of the boolean bit string for control over 
all spline-segments is therefore (8-3).

For the lathe, the bit string length will differ depending upon the 
spline type. The same would be true for the sphere_sweep should the 
'intervals' feature be implemented there.

> on topic "sor{}" - is it "hollow" or "solid" as suggested ?  (I have an email
> thread "stalled" on this question :-))
One of my all time favorite streaming series is a show called "Patriot" 
on Amazon's Prime Video service.

https://en.wikipedia.org/wiki/Patriot_(TV_series)

On seeing questions, I often hear Michael Dorman's character saying 
"It's never that simple."

Depends on stuff - and for the keyword 'hollow' there is a pile of stuff 
I know, I don't know. I've never done a deep dive on how the setting 
cascades throughout the code. There is some weirdness with how it works 
and, IIRC, Alain pointed out one of those in the last year or two for 
some situation where adding 'hollow' magically fixed things.

The keyword 'hollow' means something closer to "You can stick media in 
this object" - except where it doesn't.

For the concept of solid, it mostly means the shape has a defined inside 
test in POV-Ray. That inside test can be kinda, arbitrarily, there at 
times - as is  the case with disc{}s, for example. Further, solid(as 
defined inside), doesn't necessarily mean closed-solid or 
surface-bounded-volume, which is often the stricter requirement for 
features like media and interior fading to work correctly.

With respect to Bill W's suggestion that the sor acronym assignment 
/alignment be changed to "solid of revolution", it just hits me as 
wrong. Perhaps this only due what I was exposed to over time. To me, 
when someone says "solid of revolution", it is the 3D volume a 3D object 
(a more mechanical thingy) requires when fully rotated about one more 
axes(*).

(*) - It would be an interesting way to define shapes in POV-Ray, if we 
work out how to do it(**).

(**) - I've wondered occasionally about adding an f_reuleaux_prism() 
inbuilt function and/or shape. The rotation of the defining triangle's 
center around a circle produces a nice, beveled "solid of revolution."

Post a reply to this message

On 9/21/25 18:34, William F Pokorny wrote:
> when fully rotated about one more axes(*).

...when fully rotated about one OR more axes(*).

Bill P.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 9/21/25 13:44, jr wrote:
> > v confusing. ...
> Documentation needs to be created. :-) A quick answer is that the number
> of spline-segments for the sor{} is always 3 less than the number of
> points specified. The length of the boolean bit string for control over
> all spline-segments is therefore (8-3).

thanks.  I'd better wait for the next yuqk release, I don't think I'm ready for
an answer to "three less ?" </grin>


> ...
> Depends on stuff - and for the keyword 'hollow' there is a pile of stuff
> I know, I don't know. I've never done a deep dive on how the setting
> cascades throughout the code. There is some weirdness with how it works
> and, IIRC, Alain pointed out one of those in the last year or two for
> some situation where adding 'hollow' magically fixed things.
> The keyword 'hollow' means something closer to "You can stick media in
> this object" - except where it doesn't.

I like the "can fill with" definition, feels "intuitive".


> ...
> With respect to Bill W's suggestion that the sor acronym assignment
> /alignment be changed to "solid of revolution", it just hits me as
> wrong.

sorry, still "no good".  I'd hoped for something along the lines "reading the
code at ...", that is for some "evidence-based" words.

and agree that sweeping (whole) objects sounds like a cool/fun thing; does the
required "infrastructure" exist already (in part, at least) ?


regards, jr.

Post a reply to this message