We've had the cells pattern since at least v3.5. Underneath, it uses a 
hash function on cube locations to generate random-ish values. I've used 
it a lot as a pattern. I've used the core code from the approach in 
povr's f_repeat function.

Cells is great, but I've had on my list to add a more general inbuilt 
f_hash function to the povr branch. You can more or less duplicate the 
current cells functionality with it, but the idea is to enable much more.

First up, to be able to create cells with shapes other than cubes. This 
the idea explored in the attached image.

//---------
// The code. Uses not yet published povr branch as of Aug 14, 2021.
#declare Seed00 = int(7834.5540283051168444); // int of now
#declare Fn00 = function {
     f_hash(
         (
         f_hash(x,Seed00,0.1,0)+
         f_hash(y,Seed00*2,0.1,0)+
         f_hash(f_cylinder(x,z,y,0.2),Seed00*4,0.005,0)
         ),
     Seed00,0.00,0)
}
#declare Fn01 = Fn00
#declare Fn02 = function {
     f_hash(Fn01(x/1.002,y/1.002,z/1.002) - Fn00(x,y,z),0,0,0)
}
#declare POV_MediumGoldenrod = srgb <0.91765,0.91765,0.67843>;
#declare Pigm00 = pigment {
     function { Fn02(x,y,z) }
     color_map {
         [0.00 Black]
         [0.10 POV_MediumGoldenrod]
         [0.90 POV_MediumGoldenrod*0.3]
         [1.00 Black]
     }
}
//---------

At Fn02, with some quick math, and as clipped to the image, there are 
~5040 'cells.' Here, arcs in square regions; infinite in z. The output 
is used in the above pigment to color a z plane.

Bill P.

Post a reply to this message

Attachments:
Download 'f_hash_story.jpg' (199 KB)

Preview of image 'f_hash_story.jpg'

On 8/14/21 8:51 AM, William F Pokorny wrote:
> Cells is great, but I've had on my list to add a more general inbuilt 
> f_hash function to the povr branch. You can more or less duplicate the 
> current cells functionality with it, but the idea is to enable much more.
...

This second image shows a simpler f_hash of x; combined with a seven 
entry color_map and two warps.

Herein also playing with ideas for another run at a f_spiral() 
replacement function - given the existing one has some awkward 'quirks.'

Start with an increasing rotation moving toward the center. About a two 
thirds of the way into the rotation, blending in an increasing 
displacement directly toward the center. This gradually turns turns the 
rotation into a more traditional spiral. Thought is to do something 
similar for a 'f_spiral()' replacement. We'll see.

Bill P.

Post a reply to this message

Attachments:
Download 'f_hash_story2.jpg' (417 KB)

Preview of image 'f_hash_story2.jpg'

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 8/14/21 8:51 AM, William F Pokorny wrote:
> > Cells is great, but I've had on my list to add a more general inbuilt
> > f_hash function to the povr branch. You can more or less duplicate the
> > current cells functionality with it, but the idea is to enable much more.
> ...
>
> This second image shows a simpler f_hash of x; combined with a seven
> entry color_map and two warps.

love this "stirring paint" effect.


regards, jr.

Post a reply to this message

On 8/15/21 4:09 AM, jr wrote:
...
> 
> love this "stirring paint" effect.
> 
:-) Thanks.

I inherited an old leather bound book publish sometime in the mid to 
late 1800s; since given it to my daughter. In trying to learn more about 
the book, I corresponded for a time with a librarian at university which 
had a similar book. On the inside covers there were these wonderful 
color swirling patterns and I asked her how they were done.

They were made by laying down paint line in lines of differing colors 
floating atop water. A stick/or sticks would be inserted in the paint 
and spun. The blank paper would then be lowered onto the floating paint 
pattern and, presto, color swirls. Cool technique - sans computers - 
though the basics are much the same I suppose.

--- Also.
FWIW. I took a couple day run at your '-window id' feature idea and failed.

Learned quite a bit about X - enough to address two unix display issues 
Jerome uncovered some years back with all the preview displays. The 
approach tried, I borrowed from 'feh' which just added a window id 
feature. I think a more invasive method is likely necessary for POV-Ray, 
but, maybe I'm still clueless.

Also, in looking at the tcl/tk code supporting such 'adopted' windows, I 
wonder, still, about getting all the event masks and handling lined up 
so nothing is tangled that should not be - except, you know, what should be.

Maybe I'll take a run at it again down the road. I have an interest in a 
simple generic interface for things like modeling splines on the fly 
using POV-Ray as for both modeling and display - as you know.

I played some with the xcb alternative to xlib too. Why? Well, I 
strongly suspect that threads xlib fix we came up with isn't going to 
fly with a -window id / -into feature.

Bill P.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 8/15/21 4:09 AM, jr wrote:
> ...
> > love this "stirring paint" effect.
> >
> :-) Thanks.
>
> I inherited an old leather bound book publish sometime in the mid to
> late 1800s; since given it to my daughter. In trying to learn more about
> the book, I corresponded for a time with a librarian at university which
> had a similar book. On the inside covers there were these wonderful
> color swirling patterns and I asked her how they were done.

I too remember (vaguely) seeing such a book once.  thanks for the (snipped)
explanation.  thinking that you might like the types of patterns designed by W
Morris, if you don't know (of) him already.
<https://en.wikipedia.org/wiki/William_Morris>


> FWIW. I took a couple day run at your '-window id' feature idea and failed.
>
> Learned quite a bit about X - enough to address two unix display issues
> Jerome uncovered some years back with all the preview displays. The
> approach tried, I borrowed from 'feh' which just added a window id
> feature. I think a more invasive method is likely necessary for POV-Ray,
> but, maybe I'm still clueless.
>
> Also, in looking at the tcl/tk code supporting such 'adopted' windows, I
> wonder, still, about getting all the event masks and handling lined up
> so nothing is tangled that should not be - except, you know, what should be.

I'm wondering whether you aren't .. over-complicating.  on the Tcl/Tk side - the
app provides a 'frame' created with '-container', frames have no (default)
bindings.  I envisage generating a temp scene (and perhaps ini), then 'exec'
povray and tell it to put the preview yonder.

re '-into'.  I had a v cursory look at xterm source ('xterm-325'), of interest
in only 'main.c' in that it processes options, and its call to a function
'misc.c:xtermEmbedWindow()', which wraps 'XReparentWindow()'; the rest of
'misc'c' will probably also provide insights.


> Maybe I'll take a run at it again down the road. I have an interest in a
> simple generic interface for things like modeling splines on the fly
> using POV-Ray as for both modeling and display - as you know.
>
> I played some with the xcb alternative to xlib too. Why? Well, I
> strongly suspect that threads xlib fix we came up with isn't going to
> fly with a -window id / -into feature.

??  the window would be the same, just a different owner.


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> > On 8/15/21 4:09 AM, jr wrote:
> > ...
> > FWIW. I took a couple day run at your '-window id' feature idea and failed.

sheesh.  I never even said thank you, sorry, do so now.


regards, jr.

Post a reply to this message

On 8/15/21 5:50 PM, jr wrote:
> I too remember (vaguely) seeing such a book once.  thanks for the (snipped)
> explanation.  thinking that you might like the types of patterns designed by W
> Morris, if you don't know (of) him already.
> <https://en.wikipedia.org/wiki/William_Morris>
> 

Thanks for the pointer.

> 
>> FWIW. I took a couple day run at your '-window id' feature idea and failed.
>>
...
> I'm wondering whether you aren't .. over-complicating.  on the Tcl/Tk side - the
> app provides a 'frame' created with '-container', frames have no (default)
> bindings.  I envisage generating a temp scene (and perhaps ini), then 'exec'
> povray and tell it to put the preview yonder.
> 

Very likely so... ;-) I should also say up front while I use Tcl daily, 
I've only, ever been, a light user of Tk on the programming side of 
things. My testing during my attempt used c code to create a frame 
window, not Tk.

Do you have a simpler tcl/tk script creating a frame window I could steal?

My view is certainly fuzzy, but are there not events which should always 
be handled - like someone closing the parent window into which POV-Ray 
displays(1). POV-Ray couldn't stop a user from doing this if the parent 
window permits it.

(1) Aside. Closing the preview window causes segfault with povr's x11 
display - while the sdl2.0 version won't permit the window to be closed 
except by the POV-Ray approved events. On my list to fix - someday.

There are things like window re-sizing which POV-Ray doesn't handle 
today, so if someone starts re-sizing the parent I don't know what 
happens upstream. Does X11 just handle having an child it cannot re-size 
or do unfortunate things happen?

While POV-Ray is running with a preview window, for it's own event loop 
to work to pause or exit, say, that preview window must have the overall 
window manager's focus. What happens in the larger containing app's 
window as focus moves around to sub windows? That's something likely to 
happen if the preview window is wrapped in a larger set of windows.

Further, in my attempt, I tried to bypass the icon set up and handling 
because it didn't seem like there should be an icon if the preview 
window wasn't owned by the root window. Without an icon though, it's 
harder to get the focus back on the POV-Ray preview window.

Lastly, in my simpler modeler scenario I'd want some events passed to 
the parent window's event handler loop from the one POV-Ray is running 
for it's own purposes. I'm not clear on how all that would work.

I'm fuzzy/lost as to how much of this works/should work. If I could get 
something basic going, I could start working through the questions - but 
I didn't get that far. :-(

> re '-into'.  I had a v cursory look at xterm source ('xterm-325'), of interest
> in only 'main.c' in that it processes options, and its call to a function
> 'misc.c:xtermEmbedWindow()', which wraps 'XReparentWindow()'; the rest of
> 'misc'c' will probably also provide insights.
> 

Yes, I should look at that code ahead of another attempt.

> 
...
>> I played some with the xcb alternative to xlib too. Why? Well, I
>> strongly suspect that threads xlib fix we came up with isn't going to
>> fly with a -window id / -into feature.
> ??  the window would be the same, just a different owner.

My understanding is the issue with multiple xlib threads addressed by 
XInitThreads() in part protects 'global' variables in X. My thinking is 
this requires something of the x server being used - at least to the 
window level taking up parentage - which is probably OK when I have the 
access to change the parent's behavior. What happens when I don't?

I'll guess from your question, perhaps XInitThreads() 'access ordering' 
is localized at the preview window and below? In other words, it doesn't 
involve the frame window or any above it?

Bill P.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> Very likely so... ;-) I should also say up front while I use Tcl daily,
> I've only, ever been, a light user of Tk on the programming side of
> things. My testing during my attempt used c code to create a frame
> window, not Tk.
>
> Do you have a simpler tcl/tk script creating a frame window I could steal?

the attached is slightly different in that it drives 'gnuplot's stdin, also, it
was "a bit of fun" only, so the code is not .. tidy.  (also,as I write this, I
think I may have posted this before)


> My view is certainly fuzzy, but are there not events which should always
> be handled - like someone closing the parent window into which POV-Ray
> displays(1). POV-Ray couldn't stop a user from doing this if the parent
> window permits it.

cannot really tell what might happen, but when a Tk application's windows get
destroyed, it's all done via 'WM_DELETE_WINDOW', see 'wm(n)'.  assume POV-Ray
will simply get notified to close its window.


> (1) Aside. Closing the preview window causes segfault with povr's x11
> display - while the sdl2.0 version won't permit the window to be closed
> except by the POV-Ray approved events. On my list to fix - someday.

SDL would not do anyway, never found a way to get an (X) window id.


> There are things like window re-sizing which POV-Ray doesn't handle
> today, so if someone starts re-sizing the parent I don't know what
> happens upstream. Does X11 just handle having an child it cannot re-size
> or do unfortunate things happen?

the frame, within the app, can be created not to resize, so the scenario can not
happen (famous last words :-)).


> While POV-Ray is running with a preview window, for it's own event loop
> to work to pause or exit, say, that preview window must have the overall
> window manager's focus. What happens in the larger containing app's
> window as focus moves around to sub windows? That's something likely to
> happen if the preview window is wrapped in a larger set of windows.

I use the 'focus-follows-mouse' setting on my machines, so, from experience, I
think it unlikely to be a problem.


> Further, in my attempt, I tried to bypass the icon set up and handling
> because it didn't seem like there should be an icon if the preview
> window wasn't owned by the root window. Without an icon though, it's
> harder to get the focus back on the POV-Ray preview window.

from POV-Ray's perspective, there's no difference whether the windows manager,
or an application, provides the "toplevel".


> Lastly, in my simpler modeler scenario I'd want some events passed to
> the parent window's event handler loop from the one POV-Ray is running
> for it's own purposes. I'm not clear on how all that would work.

phew..  I'm not sure what event POV-Ray would want to pass to the application,
could you .. flesh this out a little, please?  but there'd be other mechanisms,
pipes, dbus?


> ...
> My understanding is the issue with multiple xlib threads addressed by
> XInitThreads() in part protects 'global' variables in X. My thinking is
> this requires something of the x server being used - at least to the
> window level taking up parentage - which is probably OK when I have the
> access to change the parent's behavior. What happens when I don't?

yes, but the server does "get told" (XReparentWindow), so not sure "higher
levels of abstraction" libs have additional "needs".


> I'll guess from your question, perhaps XInitThreads() 'access ordering'
> is localized at the preview window and below? In other words, it doesn't
> involve the frame window or any above it?

if I understand correctly, and aiui, the (preview) window knows nothing about
who "owns" the top-level (ie WM or app).  when created the event mask will allow
for it to receive select events, whoever sends them.


regards, jr.

Post a reply to this message

Attachments:
Download 'wfp_tk.tar.xz.dat' (2 KB)

On 8/16/21 8:08 AM, jr wrote:
> phew..  I'm not sure what event POV-Ray would want to pass to the application,
> could you .. flesh this out a little, please?  but there'd be other mechanisms,
> pipes, dbus?

First, thanks for the detailed response. I'll add it to my notes for the 
next attempt. And on seeing your posted example, it does ring a bell... 
Sorry if I did miss it - or forget I saw it posted.

---
Re: dbus, pipes. Your guessing my aims correctly.

There are crude ways to call povray in a loop today - adjusting say 
spline control points. Such an approach which would be made much cleaner 
with some sort of window id / into functionality as you've suggested. 
Such an approach if, working with Tk frame widows, opens up Python and 
Tcl as the scripting mechanism for "modeling/simple POV-Ray created 
widget windows."

However, I'd like something a step beyond this coupled with rtr - which 
in my minds eye at the moment - requires a couple of os level tasks be 
talking to each other(1) continuously - or to, perhaps, be aware of X11 
events in a shared way.

I'm ignorant of too much at the moment to know what I really want.

There are all the widget packages too - Qt, etc. With povr, I'm aiming 
at more of a small utility niche with little or no overhead - something 
'easy'. Pipe dream I expect, but a push here and a push there and maybe 
some path to such a thing opens up....

(1) - POV-Ray has Thorsten's povms which has some facilities for such 
communication. While I've learned tiny bit about that code of late, I'm 
a long, long way from being able to swing that code around as a useful 
hammer inside POV-Ray - let alone extend it.

Bill P.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 8/16/21 8:08 AM, jr wrote:
> > ...
> Re: dbus, pipes. Your guessing my aims correctly.
>
> There are crude ways to call povray in a loop today - adjusting say
> spline control points. Such an approach which would be made much cleaner
> with some sort of window id / into functionality as you've suggested.
> Such an approach if, working with Tk frame widows, opens up Python and
> Tcl as the scripting mechanism for "modeling/simple POV-Ray created
> widget windows."

XReparentWindow()'s documentation says "...if the specified window was
originally mapped, the X server automatically performs a MapWindow request on
it."

so,wondering whether you'll indulge me and run a test (somewhere under the 'jr
causing trouble' directory. :-)) with a new command-line option.

I looked at xterm code.  the '-into' arg is converted (strtol()) and cast to
Window type.  it is passed to 'misc.c:xtermEmbedWindow', where it's used as
third arg in XReparentWindow.  I also looked at your 'disp_x11.cpp', the
XMapWindow call in line 429.  so, why not try and place a call to
XReparentWindow in line 430?  I've attached a simple Tk UI which provides a
800x600 frame[*] and outputs its window id to stderr.  if you can get that into
povr?!

[*] can easily be changed in line 12.

of course it's a hack, and probably will "flicker" once as it would be unmapped
immediately after line 429, but hey..


> However, I'd like something a step beyond this coupled with rtr - which
> in my minds eye at the moment - requires a couple of os level tasks be
> talking to each other(1) continuously - or to, perhaps, be aware of X11
> events in a shared way.
>
> I'm ignorant of too much at the moment to know what I really want.

didn't the Sex Pistols sing "I don't know what I want, but I know how to get
it"?  :-)


> ... Pipe dream I expect, but a push here and a push there and maybe
> some path to such a thing opens up....

another lyric ;-) -- "little by little, and stone by stone (rich man's mountain
comes crumbling down)" (UB40)


regards,jr.

Post a reply to this message

Attachments:
Download 'frm.tk.txt' (1 KB)