
EasyToUse Dynamic Color Gradiant Generator 
miran
Member #2,407
June 2002

Yes, probably.  
Dennis
Member #1,090
July 2003

Good(i hope i didn't cause too much trouble).:)  0xDB  @dennisbusch_de  
miran
Member #2,407
June 2002

Not at all. In fact version 1.05 is already up Btw, you can now move attractors with the mouse too. Right mouse button changes range  
Neil Walker
Member #210
April 2000

How do you achieve smoother gradients? The only way I could achieve it was adding more of the same in the same place, but this has the effect of turning it towards white. Neil. Neil. wii:0356138466872022, kart:330848066002. XBOX:chucklepie 
miran
Member #2,407
June 2002

Smoother? I always get very smooth gradients. Make sure you're running the program at 32bpp. This can be set in allegro.cfg... EDIT: And one more (small) update. Version 1.06 is now uploaded  
Dennis
Member #1,090
July 2003

miran said: Not at all. In fact version 1.05 is already up
Wow that was quick, maybe even a little too quick...Where did my p and exp go?:' (I wanted to play around with them, preferably in a way that they are also text input fields that take floats.(The formula "eff_mod=p*dist^exp" could be shown next to that fields to give the user a hint what they do.) How easy is your MASkinG to learn? Maybe i should look into it, so i could make the GUI myself. (You'd still be credited for GUI, of course.:)) Neil said: How do you achieve smoother gradients? I'm afraid that question can't be answered easily but it greatly helps if you understand how the RGB scheme works, because then it is possible to actually plan the result and place colors in a way that they will mix as you expect them to. [edit]  0xDB  @dennisbusch_de  
miran
Member #2,407
June 2002

Quote: Where did my p and exp go? As I said, exp is in fact linearity. And p, I didn't think it was very useful. Or maybe I'm missing something? I'll do some more experiments Quote: Could you not just have used my version2? I don't think that it is that much a speed loss with it compared to lookup tables and also version1 is included so that loading of previously generated files would not be broken. Well, calling the pow() function in a tight loop is always going to be very slow. Quote: How easy is your MASkinG to learn? Hmm, it comes with full documentation, about 20 examples and a short tutorial. Whether it's easy or not depends on what you're used to, but I'd say it's not too difficult. Maybe it just requires a bit of time to get started, but then it's very easy...  
Dennis
Member #1,090
July 2003

miran said: And p, I didn't think it was very useful. I thought having a coefficient could be a nice thing to experiment with and i still want it. miran said: Well, calling the pow() function in a tight loop is always going to be very slow.
This might be true, but in fact i did not notice any hit in performance in my example. What i wanted to achieve with this:
I will start looking into your MASkinG, though it would be very helpful if you'd still be working on the GUI, because you're probably much faster on it than i could ever be.;)  0xDB  @dennisbusch_de  
miran
Member #2,407
June 2002

There's still full downwards compatibility. The last version still loads and properly renders all files that were saved with v1.00 and all other versions after that. Besides, there's virtually no difference between your v2 code my modified v1 code, except that mine is optimized with LUT (and I did notice a MAJOR performance hit; as in your code is like 20 times slower!) and I don't have p. I'll put that in too so you can play with it, it's not difficult. But as I said, it's not very useful either, at least from what I've seen... EDIT: There, v1.07 has p in. It's called multiplier. I'll give you an award if you can do anything useful with it though. Btw in render_col_grad_to_bitmap() you can comment out the lines where d is calculated and uncomment the lines that call your code (that does exactly the same). If you can compile that, you'll see the difference in speed. My version is slow, but yours is painful...  
Dennis
Member #1,090
July 2003

miran said: There's still full downwards compatibility. That's good, i did not recognize it, because i wrote my post before examining your latest version.:P miran said: Besides, there's virtually no difference between your v2 code my modified v1 code, except that mine is optimized with LUT (and I did notice a MAJOR performance hit; as in your code is like 20 times slower!) and I don't have p.
Ok you're right about the speed then(i was just judging from one example without actually comparing any timings) but i still would like my effect_modifier in, because it allows for greater flexibility and experimenting, being able to enter just any float value for p and exp(even negative ones!). Your linearity allows only ranges from 0 to 2.0 as i see it. I want to also experiment with negative exp and p and values greater than 2. miran said: I'll put that in too so you can play with it, it's not difficult.
Great, i'm looking forward to the next version.:) [edit] miran said: It's called multiplier. I'll give you an award if you can do anything useful with it though. I can already think of something: It can be used to quickly change the intensity value of a color, without the need to go into the color editor and sliding the intensity down(and that's not the same as changing your linearity). For my award i choose that you incorporate what i suggested above in this post;D.  0xDB  @dennisbusch_de  
miran
Member #2,407
June 2002

OK, I tested a bit now and for some reason the speed difference is hardly noticable. I swear it was much more before! And you do have a point about that modifier function. It makes things more flexible. I think I'll do that in the next version. And I'll change those sliders into text boxes so you can type in anything you want  
da_flo
Member #1,907
February 2002

Quote: Maybe your suggestions would be the same as having individual intensity(distance) functions for each attractor? I'm a little puzzled.
Quote: (Maybe that's what da_flo was talkin about. I'm not good at this advanced maths stuff.) Your linearity modifiers are nice. Using custom interpolation functions like this instead of linear interpolation is nice. I haven't thought about it (When I wrote my post, I was really tired, since I spent the whole previous night with friends, and was really stoned when I wrote it...) But in fact that's not quite the same as what I was talking about. N(lambda*u) = lambda*N(u) In fact, a good way to visualize the differences between norms is to see the shape of a circle for those norms (a circle being of course defined as the set of points at a given distance of the center, according to the norm choosen). I've attached a picture of circles with a radius of 1, for N_1, N_2 and Ninfinity. For N_p, with p>2, you get a round square, which becomes sharper as p gets bigger. (in fact one can show that lim(p>infinity) N_p(u) = N_infinity(u). It doesn't matter if you don't get this though ). So, I think I should try it, to see what kind of gradients we get with those new distances, because I can't say it without trying. And custom distances and linearity modifiers can be combined together, giving even more possibility However, since I still don't know how to compute the distance from a point to a line with noneuclidian distances, it can't be added to the program right now. I hope you get it now. It was only a remark, I don't know if that's really useable. 
Dennis
Member #1,090
July 2003

miran said: OK, I tested a bit now and for some reason the speed difference is hardly noticable. I swear it was much more before! Oh well, if that is the case then you might as well completely forget about the look up tables.(will also save a lot of memory;)) You're doing a great job on the GUI, just wanted to say that again as it can't be stressed enough!:D [edit] da_flo said:
However, since I still don't know how to compute the distance from a point to a line with noneuclidian distances, it can't be added to the program right now. All remarks and suggestions are highly welcome. Nothing beats several brains thinking in different directions. Maybe the problem with your thinking about the distance lies in the fact that there is no such thing as a "point" or a "line" in 'noneuclidean'space?!(just a thought...) If it's not defined you'd have to invent that space yourself and write a function that transforms from there to cartesian coordinates...(no i don't really know what i'm talking about;D)  0xDB  @dennisbusch_de  
miran
Member #2,407
June 2002

OK, changed sliders to textboxes so you can type in any value you want and I switched to Dennis' code. Version 1.08 already uploaded da_flo: I almost understand what you're talking about and I vaguely remember that from some math class I had some 3 or 4 years ago. But the memory is all blured EDIT: About the speed issue. I figured it out. The speed of the pow() function depends on the parameters. If the exponent is a whole number, it's very fast, but if it's a fraction, it's very slow  
Dennis
Member #1,090
July 2003

Is that that thing with generic"topologies" in arbitrary "vector"algebras(<can be anything, not necessarily analytical geometry vectors)?(my terms may be incorrect as i only know the german terms: "Allgemeine Vektorraumtheorie", "Topologien in allgemeinen VektorrĂ¤umen") Will check Version 1.08 now...:)  0xDB  @dennisbusch_de  
da_flo
Member #1,907
February 2002

Quote: Maybe the problem with your thinking about the distance lies in the fact that there is no such thing as a "point" or a "line" in 'noneuclidean'space?!(just a thought...) If it's not defined you'd have to invent that space yourself and write a function that transforms from there to cartesian coordinates...(no i don't really know what i'm talking about Be aware that I'm not really talking about noneuclidian geometry, such as hyperbolic geometry or other fancy stuff, where lines have an odd behaviour and all. Here I am still talking about basic space, with cartesian coordinates, but I'm trying to use some other kinds of distance. That's no geometry, only basic topology. The norms I've described (except N2) are called noneuclidian because they are not defined from a dot product. Well, I'm getting a bit offtopic... Ahem. I will try to do some coding as soon as I get motivated enough. 
Dennis
Member #1,090
July 2003

miran said: About the speed issue. I figured it out. The speed of the pow() function depends on the parameters. If the exponent is a whole number, it's very fast, but if it's a fraction, it's very slow
Ok, fractions should only be used with great care then;) and the default values(i guess it's already that way) should always be 1.0.:) da_flo:  0xDB  @dennisbusch_de  
da_flo
Member #1,907
February 2002

Now that I think about it, if you look at the image I have attached (2 posts ago), you will notice that for hbar and vbar the distance is the same, whether we use the usual euclidian distance or a distance obtained from any N_p. Thus those norms can easily be implemented, and we can get gradients shaped differently that way. It only becomes tricky if we use bars which are neither horizontal nor vertical. 
Dennis
Member #1,090
July 2003

da_flo: miran:  0xDB  @dennisbusch_de  
Richard Phipps
Member #1,632
November 2001

There is too much math in this thread. My head hurts! 
da_flo
Member #1,907
February 2002

Dennis, forget what I just said. I was still in the maths stuff, so I was assuming lines were infinite lines. With bars, which have 2 extremities, this becomes a bit more complicated. It might actually be quite simple, but I need to take a piece of paper and work on it. [EDIT] 
Dennis
Member #1,090
July 2003

These lines actually don't have two extremities... they are just either an x(vertical bar) or an y(horizontal bar) offset, so can they not already be treated as infinite ones?  0xDB  @dennisbusch_de  
da_flo
Member #1,907
February 2002

Oh okay Dennis. Then it works, no problem. I'll dig into the maths issues anyway, for fun and to see if this can be used with fancier attractors/absorbers. 
Dennis
Member #1,090
July 2003

Would be cool to have polynomial attractors/absorbers with an arbitray unit(given in pixels):X or circular ones where range will be seen as range from every point on the circle:X However, i'll be experimenting with miran's v1.08 now... see y'all tomorrow.:)  0xDB  @dennisbusch_de  
miran
Member #2,407
June 2002

I've been experimenting with different distance functions. Attached is a picture of the default point with Norm p: Np(x,y) = (x^p + y^p)^(1/p) with p=0.3. Looks nice but is awefully slow without lookup tables Norm infinity looks similar but a bit more square. Norm 1 isn't much different either, except that it's rotated by 45 degrees, so it makes diamonds instead of squares...  

