@Reptorian That’s like, Lovecraft Level! 
I like shorter code too, and I don’t like to repeat lines of code with a few variations.
But i’m not an expert either (yes you already know that), so what works first usually wins 
until i come back later and fix things ( which may not happen 
)
l[^0] : Yes i knew about that one but for some reason i didn’t use it here… Strange.
Is that “backward” concatenation? Prefix? I suppose sel.=^ would append ^ to the content of $sel ?
step:=floor(u(1,20)) What is :=? I can’t find it in the reference. Is it to avoid using {}?
I quickly tested it and it was missing the final fi. Fixed that but now it’s missing a done command before return point. I’ll check that later and maybe do a mixture of both codes hihi.
It’s working now, thanks. Now i gotta chase all these var={stuff} to use :=
Yes.
Yes.
I also use that in case of when I want to treat string as a math parser code.
1 Like
I got you covered. You can search with \w+={.+?} after you enable regex searching.
20 matches using your file. Some false positives, but most work. You do have to be careful to set in vector arguments in some case, and in that case, might not be the best choice to fix it up.
To clarify:
A,B={$<*2},{$>/2}
The above code could be:
A,B:=[$<,$>]*[2,.5]
And this:
col={floor(u($colr-50,$colr+50))},{floor(u($colg-50,$colg+50))},{floor(u($colb-50,$colb+50))}
Could be:
col:=floor([u($colr-50,$colr+50),u($colg-50,$colg+50),u($colb-50,$colb+50)])
Alternative:
col:=v=[$colr,$colg,$colb];fill(v,chan,floor(u(chan-50,chan+50)););v;
In addition, this is unnecessary:
if {$colr+$cvar}<255&&{$colr+$cvar}>0 colr+=$cvar fi
You’re already using the math parser after the “if”. So, no {} is needed at all.
Could be rewritten as:
if inrange($colr+$cvar,0,255,0,0) colr+=$cvar fi
1 Like
Well, I’m afraid your “my file” is not up to date : i have 44 matches in mine 
And I have a separate dummy file for “unfinished & broken” business.
I’ll update once i fix those things. But each time i learn something here i have to re-check everything so the update may never happen at this rate x_x
Ah, Line Spam… I have to admit these values (formulas, whatever) are purely randomly chosen. It looked cool so why not? I tried all combinations i could think of, and removed the uglies.
I went in completely in the dark, as usual. Thanks for the advice, I will correct all this stuff. I still have to modify it for Spline Spam, after all. But i’ll have to find some nice values for the splines.
Really? ìf` calls the math parser? Didn’t know that… Some more stuff to check lol. Thanks, I hope I don’t use too much of your time. I could throw a billion questions…
( and i’m not the kind of guy to ask questions actually!)
@Reptorian is checking
prawnsushi.gmic
That is how Rep and I learned: by asking questions 
, often ones with obvious answers. 
Not to fret though, this is a friendly community we have here for the most part. 
Use this thread and threads such as G’MIC exercises for that purpose.
2 Likes
Also, this forum has a bookmark feature. Useful for going back.
1 Like
Although if you bookmark all the time it gets unwieldy. I do like the newer reminder feature that comes with bookmarking though.
In general, be consistent with your posting habits. Focus on one or two threads at a time. That way it is easier to find what you are looking for when you want to reference it in the future.
Operator :=
A quick word about the := operator. It belongs to the family of Arithmetic Assignment Operators available in G’MIC to assign or update variable values.
These arithmetic operators are:
-
+=,-=,*=,/=,%=,|=,&=,^=,<<=,>>=, and of course:=.
All these operators are supposed to work only with numbers, so they automatically try to evaluate the right-hand side of the expression. That’s why:
var:=30*cos(pi)
echo $var
is correct and wil display
-30
On the other hand, the classical variable assignment operator = works with strings, so:
var=30*cos(pi)
echo $var
is also correct, but it will display
30*cos(pi)
That’s why, you can also force the math evaluation of the right-hand side, enclosing it with {}:
var={30*cos(pi)}
echo $var
will display
-30
Conditionals
In the same spirit, all flow control commands that expect a boolean value (0 (false) or another value (true) ) as an argument, such as if, elif, check, repeat and while also try to evaluate their argument automatically.
2 Likes
Thanks everyone!
I still have a few questions :
1- Do you think there is a better way to write this?
Rstep,Gstep,Bstep:=sqrt(($13-$10)^2)/$div,sqrt(($14-$11)^2)/$div,sqrt(($15-$12)^2)/$div
A bit like this but looks more complicated :
[/quote]
2 - How can i shift an image with x,y coordinates for a given angle ?
Imagine light coming from an angle and shifting a drop shadow by a few pixels in the opposite direction ( See Testing > Prawnsushi > Paper Cuts ). I’m using rep_emboss_relief to “try” to bevel a little the contours (with alpha) and adjust the shadow accordingly.
I think i have noticed this somehow because I have used it a lot (otherwise i got errors anyway heh).
-
Probably
Rstep,Gstep,Bstep:=sqrt(([${13-15}]-[${10-12}])^2)/$div -
Command
shiftallows to shift an image with non-integer shifts (float-valued). Useamp*[cos(angle),sin(angle)]as a shift vector and it should be OK.
2 Likes
The highlight and shadow are always in the opposite direction, so applying 180° would do. The highlight is 90 to the right of angle, and shadow is 90 degree left.
This is angle 0:
If you’d like, I could definitely try to modify the command to have angle 0 be the direction of the light.
I’m not sure actually, will this give me 3 different values?
They are used here afterwards :
if $10>$13 Rs-=$Rstep else Rs+=$Rstep fi
if $11>$14 Gs-=$Gstep else Gs+=$Gstep fi
if $12>$15 Bs-=$Bstep else Bs+=$Bstep fi
thickline $sx,$sy,{[$ex+u($>*100),$ey+u($>*100)]},$ls,$o,$Rs,$Gs,$Bs
Thanks it gives me this :
shift.. {$sx*[cos($ang),sin($ang)]}
rep_emboss_relief 5,$ang,1,2,1,0,1
Looks a bit strange as the shadow seem to move in the wrong direction.
rep_emboss_relief 5,{$ang+180},1,2,1,0,1 seem to look better but I don’t know if the angle is the right one since it’s inverted (if I use 90° light is coming from above):
Well in the end it’s probably me not interpreting the angle correctly. I tend to think 0 is on the left (so light should come from the left), 90 top, etc…
Yes.
a=1
b=2
c=3
Is the same as:
a,b,c=1,2,3
Or:
a,b,c:=[1,2,3]
You can think of a operation applying to a vector as in applying operation to every index of a vector and return the output vector. This shortens code. Instead of doing a,b={$1/2},{$2/2}, it can be done with a,b:=[${1-2}]/2. They’re both result in the same thing.
The start is based on a mathematical assumption that right starts with 0. And highlight is the first thing that people usually look at because that’s where people find where’s the light is coming from.
However, the rotating direction is inverted.
Maybe try with +90? Or -90?
I’m ok up to that point, I changed a lot of lines in my code to this kind of stuff, but @David_Tschumperle 's example just puzzles me I’ll just try it and see what happens!
I prefer shadows. I used to draw with a pen/pencil or tablet, and to me light is just the white page. Everything else are shadows. But that was long ago haha.
I’ll check the rest later because it’s already tomorrow right now …!
1 Like
Alright, I understand it now! Amen.
The Sick Painter is coming.
Well, +180 seems to be working better, but some angles still look suspicious:
Above : 90° looks ok!
Below: 163° looks off, Light and Shadows are on the same side!?
1 Like
I think I know what’s going on. When you use relief mode, the output of embossing is blended in. So, you get those artifacts.
The answer is to use embossing on transparent cut in conjunction with drop_shadow command.
I think that’s pretty much what I’m doing, no? But without drop_shadow (didn’t know it existed).
# This could probably be done at once on all images but it just eats all my RAM
# That's also why shadows are merged with parent layer after each pass
repeat $np { # A bunch of images from split_color
+b[$<] $shb spread. {$shb/4} # duplication here
sh. 0,2 fc. 0,0,0 rm. # Not filling alpha channel
if $sho<1 sh. 3 *. $sho rm. fi
if $sx
# Shadows shift ($coeff is for downsampling, to reduce distance at low res):
shift. {$coeff*($sx*[cos($ang),sin($ang)])}
fi
shrink_xy[$<] {$<*$coeff} # just for fun
mv. $< # placing shadow below parent
blend[$<,{$<+1}] alpha # Merging to avoid fire & chaos later
}
# ... here, a bunch of other stuff, then :
rep_emboss_relief 5,$ang,1,2,1,0,1 # Tried {$ang+180} here
You should emboss into separate layers, use drop_shadow, and blend alpha after. That way, you can avoid the bug. Emboss/Relief has been specifically designed to account for alpha channel whenever it exists. Needless to say, I need to check if I can emboss in a mask to speed it up.
Well, I tried to do what you said, had to reorganise the code a bit, and the “bevel” outline disappeared, so I don’t know if the angle was right. I noticed before and after modifications that the shadows seem to turn around 100x faster than it should be.
Anyway, after a few other tests and reorganization the script broke, and also froze my pc in the process, hahaha. I think i’ll just move on.
1 Like