FlowStone Art Club - and useful too...

[trogluddite]

Hi All,
Hope you have all had a satisfactory chrismas and that you saw the new year in well.

Graphics Classes 2_001.png (73.94 KiB) Viewed 34855 times

Pretty,ain't it?

Art made in FlowStone...

- and it looks even better when it's MOVING!...

DOWNLOAD:

GRAPHICS CLASSES 2_001.fsm

(29.67 KiB) Downloaded 1752 times

And there's more to it than just a pretty face, it's also set up to do a bit of analysis and stress testing of Ruby and the GDI graphics engine. And a couple of examples of new home made classes of objects that take all the sweat out of animating objects. And a few other little examples and gizmos and testers and stuff.

There's plenty more instructions and comments in the schematic and in the Ruby code.

Happy New Year

[trogluddite]

And after posting something beautiful - here's the BEAST!!!!

Shape Maker.jpg (74.38 KiB) Viewed 34854 times

GgRRRrrrr..... etc.... ..ahem....

Vector graphics for the GraphicsPath objects can look great, and scale nicely, and it's dead easy to change the colours and all that - but the sitting down with a bit of graph paper, and calculating a load of co-ordinates...BORING!

So here a very, very, early, early, proto-proto-prototype of a better way to do it - design your graphic using mousey pointy wddgets and a WYSIWYG, press a button, and it spits out the Ruby code to make the shape - which you can just cut and paste into your code (or even just 'eval' as a string.

DOWNLOAD:

Shape Maker.fsm

(7.27 KiB) Downloaded 1715 times

So far it supports shapes made of lines, wibbly-wobblly closed Curves, and shapes made up from a combination of lines and curves. You can add as many points as you want, and delete them too. Beziers should be possible too once I've got a couple of array formatting problems delat with.
As all the data is purely arrays of numbers, it will also be easy to make shape "templates" that will get safely stored in @ins and @outs without the editor connected, and saving the arrays to file is also simple.

Damn, and I have to go back to work on Monday - I was just getting into the swing of it...

[digitalwhitebyte]

you make me scared friend

[philton]

damn trog you´re my hero! just downloaded your *.fsm file and will have a look at it right now....
is it done with Ruby? your Shape maker is something i always wanted to have for SM....
Damn, i have to learn this ruby stuff

[tester]

Troggie troggie - could you make for me - editable timeline with adding/removing points?

Points can be moving only horizontally, and maybe instead of vertical placement - they shuld change their color (or a color of vertical line that is crossed by the time-point? one octave = colors from red to violet, then making 5 octaves - could require simple gamma correction per colors, i.e. darker, brighter; or - one octave in different gammas of one color? things like that).

[trogluddite]

Latest version of the GraphicsPath editor now available for tinkering with - nowhere near finished yet, so apologies for the crummy user interface; but a whole load more features...

Shape Maker 009.png (138.7 KiB) Viewed 34697 times

DOWNLOAD:

Shape Maker 009.fsm

(15.76 KiB) Downloaded 1737 times

NEW...
- Bezier curves, with handle linking for when you wany smooth curves
- Better curve optimisation to allow segments of any type in any order with selectable cusps and smooth joins.
- Grid with snap
- Open shapes (i.e. lines, arrows etc.)
- Pan and Zoom on the editor window
- Undo and redo
- Improved preview with brush, pen, arrowhead etc. selection.
- Shape store module for remembering and recalling shapes (and slide-shows!)
- Much better optimisation of the output code, redundant nodes removed, lines joined better for fewer sub-paths.
- Moving the shape's position supported in the code output.

Still plenty of other new stuff to come - but I'm pretty happy with the editor. I don't really want to take that too much further as there are pther packages, like InkScape, that are much more fully featured. I've been looking at the spec's for the SVG file format - there wouldn't be total compatibility as SVG only supports beziers for curves, but Ideally I'd like to use this more as a 'clean up and optimise' tool for imported SVG files, as there are just so many useful ones already out there, and even tools to convert text etc. to SVG. If I can't get that to work, then save/load for a custom format is easy enough to include.

P.S. If you click the "slide show" box on the "SHAPE STORE" module (bottom of the schematic), you will get a mini-slide show of a handful of shapes that I made.

@tester
Well, you might just get lucky - I will be converting some of my old stuff over to FS in the coming months, including my looping effects, which just so happen to have a timeline strip similar to what you describe. Might be a while though - i got started on about three new FS projects over the Xmas break, and now I'm back at work..

[MyCo]

lol... I see, you had the same idea like me with the "autohasher" for properties. Here is my version, it's more strict, so that it only uses variables that have a specific scheme:

Code: Select all

output Hash[
instance_variables.map { |n|
  %r{^@(?<q>.*)_p$} =~ n.to_s
  unless q.nil? or q.empty?
    [q,
    instance_variable_get(n)]
  end   
}
]

All inputs that go into the hash have a "_p" at the end, which gets removed.

BTW: why don't you use "isOutlineVisible" for hit testing?

[trogluddite]

Here is my version, it's more strict, so that it only uses variables that have a specific scheme:

That's a pretty good idea. I was trying to make mine a bit simpler to use, but if the default instance variables were to change, I could end up in a bit of a mess!

Mind you, it takes me a whole coding session to work out one regExp - slowly. I'm getting the hang of them, but strings of nonsense punctuation has never been my strong point!

BTW: why don't you use "isOutlineVisible" for hit testing?

Because it didn't actually help very much. Because of the need to link curves together properly, you can't make every individual segment a separate path - you'd only ever get straight lines which wouldn't lie on the true outline anyway.
Without a separate curve for each edge, you need to find a way to work out which is the closest segment mathematically - and although it might sound odd, I found that using isVisible as well as the maths wasn't very helpful.
With the lines being so thin, it kind of encourages you to be really accurate hovering over the line itself - but if that line is a bend in a curve that comes very close to some other line, you can still end up with the wrong thing selected.
But isVisible may yet return. I've been experimenting with some new ideas using a thicker 'invisible' line as the detection area, and that seems more user friendly . But I wanted to get a rough sketch of the whole thing together before I started getting too much into the details - the code is getting bloated, and is in need of a serious tidy up and some commenting before much else happens.
I guess you could say that not using the true "mouse over the line" helps by not raising too high expectations of my rubbish "find the segment" maths!