POV-Ray : Newsgroups : povray.pov4.discussion.general : Ideas. Playing with f_hash inbuilt function. (povr branch). Server Time18 Jun 2024 21:57:13 EDT (-0400)
 Ideas. Playing with f_hash inbuilt function. (povr branch). (Message 1 to 10 of 14)
 From: William F Pokorny Subject: Ideas. Playing with f_hash inbuilt function. (povr branch). Date: 14 Aug 2021 08:51:28 Message: <6117bc50\$1@news.povray.org>
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.

Attachments:

Preview of image 'f_hash_story.jpg'

 From: William F Pokorny Subject: Re: Ideas. Playing with f_hash inbuilt function. (povr branch). Date: 14 Aug 2021 09:12:01 Message: <6117c121\$1@news.povray.org>
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.'

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.

Attachments:

Preview of image 'f_hash_story2.jpg'

 From: jr Subject: Re: Ideas. Playing with f_hash inbuilt function. (povr branch). Date: 15 Aug 2021 04:10:00 Message:
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.
 From: William F Pokorny Subject: Re: Ideas. Playing with f_hash inbuilt function. (povr branch). Date: 15 Aug 2021 10:29:50 Message: <611924de\$1@news.povray.org>
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
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.
 From: jr Subject: Re: Ideas. Playing with f_hash inbuilt function. (povr branch). Date: 15 Aug 2021 17:55:00 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
> 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.
 From: jr Subject: Re: Ideas. Playing with f_hash inbuilt function. (povr branch). Date: 16 Aug 2021 03:35:00 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.
 From: William F Pokorny Subject: Re: Ideas. Playing with f_hash inbuilt function. (povr branch). Date: 16 Aug 2021 06:51:54 Message: <611a434a\$1@news.povray.org>
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.

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

is localized at the preview window and below? In other words, it doesn't
involve the frame window or any above it?

Bill P.
 From: jr Subject: Re: Ideas. Playing with f_hash inbuilt function. (povr branch). Date: 16 Aug 2021 08:10:00 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".

> 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.

Attachments:

 From: William F Pokorny Subject: Re: Ideas. Playing with f_hash inbuilt function. (povr branch). Date: 17 Aug 2021 06:11:01 Message: <611b8b35\$1@news.povray.org>
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.
 From: jr Subject: Re: Ideas. Playing with f_hash inbuilt function. (povr branch). Date: 17 Aug 2021 09:15:00 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.

Attachments: