Palette issues with the 3.1 Beta
Moderators: BTT, andy55, b.dwall, juxtiphi
- JayPro
- Posts: 738
- Joined: Sat May 01, 2004 10:51 pm
- Location: Huntington Station, Long Island, New York
Palette issues with the 3.1 Beta
Maybe it's a repeat of an issue I had before; but I'm having problems with this beta producing colormaps that have the following formula types:
Stonewashed:
H="sin(.628*(i^3.14+(cos (1.57*i))^1.246) + tan(.0628*i))" S="cos(sin(cos(.314+.157* i)))"
V="rnd(sqwv(1.256-i^.628))"
Marine On The Moon:
H=".75 - ( .50 * i ^2.5 )"
S="cos(sin( i * 12.5 )) + .625"
V="rnd(i)*theta"
(NOTE: even though theta is shown here, the map displayed fine notwithstanding until 3.1B.)
Any ideas? Thx.
Stonewashed:
H="sin(.628*(i^3.14+(cos (1.57*i))^1.246) + tan(.0628*i))" S="cos(sin(cos(.314+.157* i)))"
V="rnd(sqwv(1.256-i^.628))"
Marine On The Moon:
H=".75 - ( .50 * i ^2.5 )"
S="cos(sin( i * 12.5 )) + .625"
V="rnd(i)*theta"
(NOTE: even though theta is shown here, the map displayed fine notwithstanding until 3.1B.)
Any ideas? Thx.
"God is syntax."
You got me with them! G-Force and WinAmp both immediately disappeared from the screen
So I thought "VERS" and typed it in but I wasn't thinking "case sensitive".
Vers=300
Anyway.....
I don't know how your Marine on the Moon worked at 1st. How can you use Theta in a colormap? L'invincible and I were just talking about that, http://forums.soundspectrum.com/viewtop ... =3314#3314
Once your flow is calculated it is done. A wave is recalculated many times a second and colors too but even then they don't share values like i or s or mag etc. So I think you were multiplying i with 0. And rnd of 0 gives what?
BTW, speaking of the Moon, did you ever play "Moon Dust" on the Commodore C64? It looked a little like G-Force!
But I think the problem looks like the rnd function. When my colormaps bombed under the previous beta, Andy mention something about the rnd function. My problem also involved using the vars as incremental numbers which don't work either. Let me check my email.....
Okay, I don't think Andy will mind if I share this:
So I thought "VERS" and typed it in but I wasn't thinking "case sensitive".
Vers=300
Anyway.....
I don't know how your Marine on the Moon worked at 1st. How can you use Theta in a colormap? L'invincible and I were just talking about that, http://forums.soundspectrum.com/viewtop ... =3314#3314
Once your flow is calculated it is done. A wave is recalculated many times a second and colors too but even then they don't share values like i or s or mag etc. So I think you were multiplying i with 0. And rnd of 0 gives what?
BTW, speaking of the Moon, did you ever play "Moon Dust" on the Commodore C64? It looked a little like G-Force!
But I think the problem looks like the rnd function. When my colormaps bombed under the previous beta, Andy mention something about the rnd function. My problem also involved using the vars as incremental numbers which don't work either. Let me check my email.....
Okay, I don't think Andy will mind if I share this:
Well d5 is out so it should work. Now the question is: Do you know what he is talking about? It should fix the rnd number but will it fix my incremental number problem? Guess I'll try it....Unfortunately, under the new vector engine, iterative techniques won't behave like they used to when the var is a vector (such as a C var).
However, there are workarounds that will work for the next build I post.
Something that was
C0="wrap(c0+rnd(.03))"
Would now look like:
C0="wrap( c0 + ( rnd( .01 ) + rnd( .01 ) ) * vector( (int) 256, 1, 256 ) )"
First off, when rnd( .01 ) is used in a vector var (ex, C var), it's implicitly of size Nx1, where each element is a random number from 0 to .01.
Next, vector( inN, inLeft, inRight ) make a Nx1 vector that goes from inLeft to inRight. So, if you look at the above, it's roughly equivalent to what you had before with the exception that what you had before would compound rnd(.03) such that the standard deviation would be vary same as the elements became larger (whereas the new expr has a uniform deviation for each element). I've offset this by adding multiple rnd() statements of smaller value (you could continue to add add'l rnd() expressions to collapse the std deviation).
Note that the above stuff won't work until I post a new build--there's an issue in 3.1d3 that will cause the above vector() call to not work properly.
On the 2nd one (Moon)
V="i" works.
V="rnd(i)" does not.
V="rnd(i)* vector( (int) 256, 1, 256 )" doesn't work.
V="theta" no go.
V="wrap(theta*1000)" Nope, theta has got to be zero in a colormap.
C0="rnd(i)* vector( (int) 256, 1, 256 )"
V="C0"
doesn't seem to work either.
But this bring it back to life:
C0="rnd(1)* vector( (int) 256, 1, 256 )"
V="C0"
Let's try rnd(1)*i....
V="rnd(1)*i" Yeah, good. Must not like the i in the rnd. Maybe i * the vector...
V="rnd(i* vector( (int) 256, 1, 256 ))" Nope, blank screen.
V="rnd(.5)+rnd(.5)" Good. I guess you don't need the vector thing to use the rnd number.!?!?!?
On the 1st one (Stonewashed):
V="rnd(sqwv(1.256-i^.628))" Gives a black screen.
taking out the rnd
V="sqwv(1.256-i^.628)" and the sqwv gives one bright color the whole map...
change it to wrap
V="wrap(1.256-i^.628)" and it looks pretty decent.
Now bringing the rnd back into it,
V="rnd(wrap(1.256-i^.628))", kills it.
V="rnd(wrap(1.256-i^.628))* vector( (int) 256, 1, 256 ) " Surprisingly, the vector brings it back to life, but it doesn't look too good.
putting the sqwv back in
V="rnd(sqwv(1.256-i^.628))* vector( (int) 256, 1, 256 ) " kills it.
Okay for V:
V="i*clip(rnd(wrap(1.256-i^.628))* vector( (int) 256, 1, 256 )) " looks pretty cool. I don't know what the 3.01 looked like originally. Was it supposed to be bright the whole colormap? That's why I thru in the clip.
I was going to try changing the tan to an atan2 in your H line but I don't think I'll go there......
V="i" works.
V="rnd(i)" does not.
V="rnd(i)* vector( (int) 256, 1, 256 )" doesn't work.
V="theta" no go.
V="wrap(theta*1000)" Nope, theta has got to be zero in a colormap.
C0="rnd(i)* vector( (int) 256, 1, 256 )"
V="C0"
doesn't seem to work either.
But this bring it back to life:
C0="rnd(1)* vector( (int) 256, 1, 256 )"
V="C0"
Let's try rnd(1)*i....
V="rnd(1)*i" Yeah, good. Must not like the i in the rnd. Maybe i * the vector...
V="rnd(i* vector( (int) 256, 1, 256 ))" Nope, blank screen.
V="rnd(.5)+rnd(.5)" Good. I guess you don't need the vector thing to use the rnd number.!?!?!?
On the 1st one (Stonewashed):
V="rnd(sqwv(1.256-i^.628))" Gives a black screen.
taking out the rnd
V="sqwv(1.256-i^.628)" and the sqwv gives one bright color the whole map...
change it to wrap
V="wrap(1.256-i^.628)" and it looks pretty decent.
Now bringing the rnd back into it,
V="rnd(wrap(1.256-i^.628))", kills it.
V="rnd(wrap(1.256-i^.628))* vector( (int) 256, 1, 256 ) " Surprisingly, the vector brings it back to life, but it doesn't look too good.
putting the sqwv back in
V="rnd(sqwv(1.256-i^.628))* vector( (int) 256, 1, 256 ) " kills it.
Okay for V:
V="i*clip(rnd(wrap(1.256-i^.628))* vector( (int) 256, 1, 256 )) " looks pretty cool. I don't know what the 3.01 looked like originally. Was it supposed to be bright the whole colormap? That's why I thru in the clip.
I was going to try changing the tan to an atan2 in your H line but I don't think I'll go there......
- JayPro
- Posts: 738
- Joined: Sat May 01, 2004 10:51 pm
- Location: Huntington Station, Long Island, New York
FYI:
Both maps are supposed to have black backgrounds; but if it turns out that Stonewashed has ablue background, I can accept that.
I do, though, wanna try and keep the back for Marine on the Moon...if that's possible.
EDIT: So just as I suspected, the trouble lies in the Value statement?
I'm gonna try DL'ing 3.1 later and implement your results. From there, I'll do a bit of testing of my own.
Both maps are supposed to have black backgrounds; but if it turns out that Stonewashed has ablue background, I can accept that.
I do, though, wanna try and keep the back for Marine on the Moon...if that's possible.
EDIT: So just as I suspected, the trouble lies in the Value statement?
I'm gonna try DL'ing 3.1 later and implement your results. From there, I'll do a bit of testing of my own.
"God is syntax."
- JayPro
- Posts: 738
- Joined: Sat May 01, 2004 10:51 pm
- Location: Huntington Station, Long Island, New York
I just ytested Stonewashed in 3.1 and the color scheme is where it should be. I didn't expect the black bands to move as rapidly as they did; but I think I like it enough to edit the colormap thataway.
Then Again:
V="i*flip(rnd(wrap(1.256-i^.628))*vector((int)256,1,256))"
Sweet Resurrection!!!!
PS: re: Marine: rnd(1)*i brought it back to life perfectly.
Then Again:
V="i*flip(rnd(wrap(1.256-i^.628))*vector((int)256,1,256))"
Sweet Resurrection!!!!
PS: re: Marine: rnd(1)*i brought it back to life perfectly.
Last edited by JayPro on Wed Oct 19, 2005 2:07 pm, edited 1 time in total.
"God is syntax."
I don't know for sure but if you are calling the same variable within itself them the functionality with the new GF 3.1 has changed. From your email from Andy that is what i understood.
"iterative techniques won't behave like they used to when the var is a vector (such as a C var). "
Maybe I got it wrong as some of the rest I don't understand what he is talking about.
I think ANdy really needs to post here. :poke:
Are you having problems other than with these iterative methods? (The C0 = C0+stuff)
JP,
Marine On The Moon:
H=".75 - ( .50 * i ^2.5 )"
S="cos(sin( i * 12.5 )) + .625"
V="rnd(i)*theta"
Like has been said it uses theta does not make sense. IMHO this should be removed from from GF distro.
"iterative techniques won't behave like they used to when the var is a vector (such as a C var). "
Maybe I got it wrong as some of the rest I don't understand what he is talking about.
I think ANdy really needs to post here. :poke:
Are you having problems other than with these iterative methods? (The C0 = C0+stuff)
JP,
Marine On The Moon:
H=".75 - ( .50 * i ^2.5 )"
S="cos(sin( i * 12.5 )) + .625"
V="rnd(i)*theta"
Like has been said it uses theta does not make sense. IMHO this should be removed from from GF distro.
I know adding a var to itself doesn't work anymore. The 1st example that I gave Andy had the rnd number in it. I thought that was the problem he was addressing in his reply. Then I asked him about using a number like C0="C0+.004". I haven't heard anything since then. That has been over a month and I have tried to follow up several times. He seeems to be avoiding the issue.
I'll give it another try today. I'd like to get those colormaps working again, if possible. But I'm not sure if it is possible. Can always go back to 3.01 to watch them but I'll lose the speed increase of 3.1.
I thought it might be possible to work around the problem, i.e. using i * a multiplier to give the same value but that hasn't worked out so far.
Here is one of the colormaps if anyone wants to take a crack at it:
chk_Five46.txt:
CCal="3+rnd(3)"
//B0="rnd(.04)"
B0=".01" // to take the rnd number out for simplicity till the C0+ is working.
C0="WRAP(C0+B0+.002)"
C1="WRAP(C1+B0+.001)"
C2="WRAP(C2+B0)"
R="c0*clip(i*256)"
G="c1*clip(i*256)"
B="C2*clip(i*256)"
Vers=300
I'll give it another try today. I'd like to get those colormaps working again, if possible. But I'm not sure if it is possible. Can always go back to 3.01 to watch them but I'll lose the speed increase of 3.1.
I thought it might be possible to work around the problem, i.e. using i * a multiplier to give the same value but that hasn't worked out so far.
Here is one of the colormaps if anyone wants to take a crack at it:
chk_Five46.txt:
CCal="3+rnd(3)"
//B0="rnd(.04)"
B0=".01" // to take the rnd number out for simplicity till the C0+ is working.
C0="WRAP(C0+B0+.002)"
C1="WRAP(C1+B0+.001)"
C2="WRAP(C2+B0)"
R="c0*clip(i*256)"
G="c1*clip(i*256)"
B="C2*clip(i*256)"
Vers=300
- JayPro
- Posts: 738
- Joined: Sat May 01, 2004 10:51 pm
- Location: Huntington Station, Long Island, New York
Rovastar wrote:I don't know for sure but if you are calling the same variable within itself them the functionality with the new GF 3.1 has changed. From your email from Andy that is what i understood.
"iterative techniques won't behave like they used to when the var is a vector (such as a C var). "
Maybe I got it wrong as some of the rest I don't understand what he is talking about.
I think ANdy really needs to post here. :poke:
Are you having problems other than with these iterative methods? (The C0 = C0+stuff)
JP,
Marine On The Moon:
H=".75 - ( .50 * i ^2.5 )"
S="cos(sin( i * 12.5 )) + .625"
V="rnd(i)*theta"
Like has been said it uses theta does not make sense. IMHO this should be removed from from GF distro.
Jon;
I wrote that map ***Way*** back when during those hazy rookie config-making days when I didn't realize that theta wasn't for maps.
As I'm still on v3.0.1 (I'm discovering that *alot* of my colormaps arent working with ß3.1), I'm using the following for V:
"rnd(.5*clip(i*256))+rnd(.5*clip(i*256))"
This makes it work as it ought to.
"God is syntax."