* A new Randomization control for the Star tool lets you set the amount of random displacement of the star's tips and (for rounded stars) curve handles. A little randomization makes a star less regular, more humane and sometimes funny; strong randomization is a way to obtain a variety of crazily unpredictable objects. Unleash your imagination!
On Sat, 2004-08-14 at 15:24, bulia byak wrote:
- A new Randomization control for the Star tool lets you set the
amount of random displacement of the star's tips and (for rounded stars) curve handles. A little randomization makes a star less regular, more humane and sometimes funny; strong randomization is a way to obtain a variety of crazily unpredictable objects. Unleash your imagination!
How do you get repeatable results each time the document is rendered, and if you adjust the various star parameters, are the positions adjusted accordingly without being re-randomized?
-mental
How do you get repeatable results each time the document is rendered, and if you adjust the various star parameters, are the positions adjusted accordingly without being re-randomized?
Glad you asked :) That's the trick :)
Each point (x,y) gets its own unique 32-bit int (well, not truly unique of course, but unique enough for my purposes). This value is given as the seed to a pseudorandom number generator. The first step, random(seed), shifts the x coordinate; the second, random(random(seed)), shifts y; the third rotates the curve handles, the fourth scales them (thus curve points always remain smooth and the handles keep their proportion). So, the randomization of a star's tip is guaranteed to remain the same so long as the tip itself remains unmoved; only as you start to move it, it starts to "dance" erratically (try it, it's fun). However if you move or transform the entire star with selector, the tip coordinates used in the above calculations do not change, and therefore the star is not re-randomized. It is also not re-randomized when you change the roundedness value, because that does not affect the position of the tip. Finally, the control handles show the positions of the true points, not randomized.
Overall, I think it's pretty convenient and useful. If you don't like a particular shape, just move one of the handles a tiny bit until you get something you like.
Actually, the most difficult part was to think up the solution to the problem that you're asking about. Once I invented the above method, it was a matter of an hour to code it. Worked fine at the first run.
On Sat, 2004-08-14 at 16:34, bulia byak wrote:
How do you get repeatable results each time the document is rendered, and if you adjust the various star parameters, are the positions adjusted accordingly without being re-randomized?
Glad you asked :) That's the trick :)
Each point (x,y) gets its own unique 32-bit int (well, not truly unique of course, but unique enough for my purposes). This value is given as the seed to a pseudorandom number generator. The first step, random(seed), shifts the x coordinate; the second, random(random(seed)), shifts y; the third rotates the curve handles, the fourth scales them (thus curve points always remain smooth and the handles keep their proportion).
Overall, I think it's pretty convenient and useful. If you don't like a particular shape, just move one of the handles a tiny bit until you get something you like.
Actually, the most difficult part was to think up the solution to the problem that you're asking about. Once I invented the above method, it was a matter of an hour to code it. Worked fine at the first run.
Clever!
Is the random number generator portable across platforms (i.e. will you get the same results on Windows as on PPC Linux)?
-mental
Is the random number generator portable across platforms (i.e. will you get the same results on Windows as on PPC Linux)?
I'm not an expert on this, but I don't see why not. Here it is in its entirety:
/** Returns the next pseudorandom value using the Linear Congruential Generator algorithm (LCG) with the parameters (m = 2^32, a = 69069, b = 1). These parameters give a full-period generator, i.e. it is guaranteed to go through all integers < 2^32 (see http://random.mat.sbg.ac.at/~charly/server/server.html) */ guint32 lcg_next (guint32 prev) { return (guint32) (( 69069 * (guint64) prev + 1 ) % 4294967296ll); }
On Sat, 2004-08-14 at 22:07, bulia byak wrote:
Is the random number generator portable across platforms (i.e. will you get the same results on Windows as on PPC Linux)?
I'm not an expert on this, but I don't see why not. Here it is in its entirety:
/** Returns the next pseudorandom value using the Linear Congruential Generator algorithm (LCG) with the parameters (m = 2^32, a = 69069, b = 1). These parameters give a full-period generator, i.e. it is guaranteed to go through all integers < 2^32 (see http://random.mat.sbg.ac.at/~charly/server/server.html) */ guint32 lcg_next (guint32 prev) { return (guint32) (( 69069 * (guint64) prev + 1 ) % 4294967296ll); }
Ah, very good. I guess the only remaining potential gotchas are:
- some versions of gcc on some platforms have rather broken 64-bit arithmetic support; I don't know what the modern situation is though
- how is x,y converted to an RNG seed? you need to be careful about differences in precision across architectures
-mental
- some versions of gcc on some platforms have rather broken 64-bit arithmetic support; I don't know what the modern situation is though
The guint64 is "guaranteed" to be 64 bit if the platform supports it, so I think we'll get at least a compilation warning if there are any platform problems.
- how is x,y converted to an RNG seed? you need to be careful about differences in precision across architectures
The coords are rounded, i.e. the seed does not change if you move the point by less than 0.001 px. I think this will take care of the rounding errors.
On Sun, 2004-08-15 at 12:06, bulia byak wrote:
- some versions of gcc on some platforms have rather broken 64-bit arithmetic support; I don't know what the modern situation is though
The guint64 is "guaranteed" to be 64 bit if the platform supports it, so I think we'll get at least a compilation warning if there are any platform problems.
No, I mean due to compiler bugs, 64-bit arithmetic can yield incorrect results even where "long long" is supported. Google for 'gcc "long long" bug'...
I don't see many bugs lodged for gcc 3.3 and later, but it has been a problem in the past.
Also note that even now gcc generates extremely inefficient code for most arithmetic operations for long long on 32-bit register-poor platforms (i.e. x86). This is one reason why in the Linux kernel, operations on long long except addition, subtraction, and bit shifting are forbidden.
That is probably not an issue here, as the RNG is not used in a performance-critical place, but it is something else to be aware of.
-mental
Re: the whole precision/RNG thing: to sum up, the truth is that computers are astonishingly bad with precise math.
Anyway, I just wanted to share that I've found a use for randomized stars in my comic work -- they're very handy for quickly making "burst" baloons.
-mental
I think this is a good idea, thanks bulia!
I don't see that we need this custom RNG thing. Storing the generated random number with the star gives us portability and more.
For example, the seed can be controlled independently of tip position, allowing smoother variation of the output function and easier to get back to "that one half a second ago" without needing exceptional mouse stability: can use a "lower-geared" widget (less rapidly changing as a function of mouse position) or keyboard.
Much less importantly: I'd guess that there can be consistency problems with using tip position to seed the RNG, due to different floating point behaviour on different machines (and even with different compiler or compiler flags).
pjrm.
participants (3)
-
bulia byak -
MenTaLguY -
Peter Moulder