Looks like i fixed the lighting of the trees with a simple shift trick to move them in their final position. The numbers are X,Y% coordinates of the light source.
Something tells me that this thing will be hard to tame in the GUI, to get the same image as the preview…
And sometimes trees are really bizarre, like Z shaped bizarre… Don’t know which parameter(s) cause(s) this.
That is a marked improvement. On the small screen of my mobile phone, the issues are not apparent. In fact, it is almost indistinguishable from magic. 
Keep up the good work. I still feel that it is more than a silly question (not a question anymore), deserving its own thread. My offer stands: I can make that happen — just let me know.
Maybe. Maybe not. Unless you’re doing dynamic GUI and using _persistent variable, then difficulty just ramped up 10x.
Agree. This is more like “Fun with prawnsushi.”
Fantastic work. Rim lighting is an exceptional improvement.
So what if the details are somewhat like what you get at a pot luck dinner? Bit like AI generators: your prompt will only tie down so much. Randomness beyond that is part of the fun.
Keep at it!
Strangely enough, when i put my script into GUI, inside a foreach block, preview complained about me creating a 50 channels image 
Found out it was the params ( 2 points for coordinates, defaulting at x 50, y 50) passed that would make preview output a 50x50x50x50 image.
Script works fine without the foreach. Any idea why it would behave this way?
Oh, and here’s a case of Z shaped tree (left):
Well, put aside the fact that i generate these images every 15sec, you can trust me when i say the lighting is wrong xD. This is not a raytracer, no global illumination thing, light doesn’t bounce back from underneath the branches when the light is located above them.
If you want to create this thread, ok, but i know it will just drown in the forum swamp faster once i stop posting about it…
mmm Nah, i’ll pass. That would be difficulty x inf+NaN for me.
Well, as you can see i want to use the point GUI … thingy … to select the rays’ starting location, but if everything is random you cannot anticipate where there will be trees, or not. In some cases, the light can get completely stuck behind trees. In that case, it looks somewhat weird.
No one is expecting raytracing. RIP my laptop if it is so. BTW, have you seen:
Yes, but it looked a bit more complicated to use with all the extra settings. So i rolled back to light_relief. Will give it another try later.
Time to share full code. I think I’ll be likely to figure it out.
Wholly a guess, since I haven’t looked at your code, but this is one of my favorite boo-boos:
I create an image just to hold plotting parameters, say one like 1,2,1,<n> for n xy plots, so that the image grows along the spectral (channel) axis as I add plots:
…
-input (50;32^234;213^ … x<sub>k</sub>;y<sub>k</sub> … ^ … x<sub>n–1</sub>_;y<sub>n–1</sub>)
-name. xyplots
-foreach { _<do stuff with every image on the list, each one in turn>_ }
…
If I do not provide a selection decorator on the foreach command, it will happily process every image on the list, including my data container image, xyplots. That does not, in itself, raise an error in a command line environment — G’MIC can deal with any number of channels — but when the script operates in the context of some host paint program, like Gimp, then that host will probably reactly badly to an image with anything more than four channels (RGBA, CMYK,…).
But, in general, foreach is like any other G’MIC command; it can take a selection decorator, so that:
-foreach[^xyplots] { _<do stuff with every image on the list, each one in turn, except xyplots>_ }
Ah. Have to look at what you’ve built tonight, sometime during the evening hours on the western side of the Atlantic seaboard…
Are you sure you want me to dump 3500 lines of code here?
Mmm now wait, maybe it’s just 35. Or is it 3.5?
Anyway, there’s more commented lines than anything else in there… Will post later.
EDIT: @Reptorian , @grosgood here it is. Laugh at will, it’s good for your health 
Actually it works now that i have modified it a little bit. But this is the original script state when i first moved it to GUI. Just added rm at the beginning to make it work in gmic_qt. But then, got this 50 channel image error. Looks like it interpreted the params “50,50,50,50” as an input.
#@gui Underwoods : pr_underwoods, pr_underwoods_preview(1)
#@gui : sep = separator()
#@gui : note = note("<span color="#EE5500"><small><b>Light:</b></small></span>")
#@gui : Light = point(50,50,0,0,255,0,0,255,10)
#@gui : Light Rays Location = point(50,50,0,0,255,255,0,255,10)
#@gui : sep = separator()
#@gui : note = note("<small>Author: <i><a href="http://prawnsushi.free.fr">Prawnsushi</i></a>.\
# Latest Update: <i>2024/04/04</i>.</small>")
pr_underwoods:
foreach {
rm
tic
(100;40;40;20;0\
^0;30;20;10;0\
^0;0;0;0;0)
# sp
=> BG
r 1500,700,100%,100%,3
pr_deform 200,0,2,0,1,3
b 50
+plasma , #spread. 10
blend value,.15
# equalize.
c. 0,255
R:=w
.
X:=u(-100,200)
Y:=u(-100,0)
repeat $R {
T=$>
if $>==0||$>%100==1||$>==$R-1
repeat 2 {
fx_tree \
{v(8,12)},0,{u(-.1,.1)},{u(.3)},9.7,150,0,2.15,.8,-10,10,56,75,0,70,20,10,2,0,255,100,0,10,0,255,50,.4,.4
}
=>[0] Tree$T
=>[1] Tree1$T
l[Tree$T,Tree1$T] {
ap "pr_deform 2,0,4,2,1,3"
shift[Tree$T] {$T*u(0.5,1.5)},0,0,0,2
shift[Tree1$T] {-$T*u(0.5,1.5)},0,0,0,2
_X,_Y=$X,$Y
ap "light_relief {u(.5,.8)},.5,.5,{u(.04,.08)},.3,$_X%,$_Y%,.001,1.5,0,0"
}
ja. [Tree$T],0,1~,0,0,1
ja. [Tree1$T],0,1~,0,0,1
rm[Tree$T,Tree1$T]
if $>%50==1||$>==$R-1
[BG] shift. $>,0,0,0,3
blend[-1,-2] screen,.2
fi
if $>%200==1||$>==$R-1
+lightrays. 5,{$X+u(1,2)}%,{$Y+u(1,2)}%,1,255
repeat 5000 {
point. {u(100)}%,{u(100)}%,0,{u(.6,.9)},{u(100,255)}
}
dilate. 3
spread. 3 blur. 1
to_rgba. s. c rm. . a[-4--1] c
.,.,1,3,[120,60,20] blend[-1,-2] overlay,1
blend[-2,-1] screen,{u(.2,.5)}
fi
fi
}
keep.
# X,Y:=floor($X),floor($Y)
# to $X" "$Y
n 0,255
toc
d0
}
pr_underwoods_preview:
pr_underwoods $*
3500 lines? You’re crazy!
3500 lines of code? That’s fine. You can also use github gist.
It occurred to me that with all this shifting around the output it almost tileable.
At least the trees are tileable, but not the lighting.
Here it tried shifting the light rays as well but it didn’t work, some seams are visible.
I wonder if there is a way to make the rays seamless?
Could be an entry way to parallax scrolling if i keep the layers…
Hypothetically, the rays could continue after it exceed boundary. That is up to David himself.
Just uploaded Gimp Layer modes & Underwoods (Early version).
Shoud be available soon under Testing > Prawnsushi
You fixed the 50 channels error or did you hide it?
Nice work, I will eventually get to play with it.
It just went away by itself. But if you want to investigate, the old code is above.
Awesome! Could you please move it to Rendering / ?
Thanks, moved it.
I still have some sliders to add, and check work to do though, but it works.
mmm, now that i think of it, i don’t remember seeing this filter crash, even when i started it : preloading 100 trees would just be ok. Still, i didn’t want to take the risk of keeping it that way, who knows what’ll happen on high res images. Let’s wait for the days when 32gb of ram will be the standard.
