Font generator

well i finished the cocoa book, and as i said in the other thread, a font generator has been on my list for a while, so hot off the digital anvil i'm uploading "my first plug-in". now some sleep...

wierd. the night i made it, i was getting 60fps as expected, the only issues i'd had were caused by me learning to code. today i open the same composition, and get 4fps

if anybody runs this, let me know what you get: it should be silky smooth.

Thanks for the reminder! I need to try this out... as it happens, the project I'm doing will now be an app, so I could build in custom patches.

I'll give it a try shortly and see how it goes.

see http://web.mac.com/tobyspark/tobyzstuff/tobyzblog/Entries/2008/2/15_SPK-...

Your pluggin is very efficient ! Thanks for this...:) Day by day Qc become more powerfull with open source...

yanomano.

This looks like it opens the doors for effects like those found at http://chronotext.org/ (once I get the OpenCV 3d registration stuff worked out for some help :).

This could make for some amazing tricks :)

i assume the hillegass was usefull at the end... ;) Anyhow, this is a killer plug. Thxx Tob'

...i almost wish i'd never seen it. anyway, yes, there's a load of basic use i need, and then there's the dreams, and thems thats those kinds of dreams. hello infographic typographic augmented reality.

glad you liked it, nice to put something back, and nice to finally follow through on the first contact a year ago saying maybe i could hack the string with file patch...

Just had a quick play with it (well more a look at your example). I really like how you've squeezed some kerning out of it, that's excellent for this kind of stuff.

I didn't see any of the 'iterator draws letters before the font set is drawn' issues I've had with my built-ins font generator, which is also good (I'm guessing it's because the structure feeds the iterations value, and the structure will only contain completed letters).

Really, it's a totally different way of working with text from what I've done - this generates a structure containing the text and an image for each letter, whereas I build a complete font set, then use normal string handling and convert the text to images at the end.

I guess my method will be better when you use a lot of text, as the image processing only gets done once at the start rather than whenever the image changes, yours will be better when there's fixed text. You could build a complete font with your patch by giving it the ascii set as the string and using the 'by character' output, so it's flexible too.

The only thing I think it lacks is some image processing for the font. It's really handy to be able to add colour + shading, drop shadows etc. to the font, then just render it with sprites as you're doing now. There's no slowdown from the processing that way, at least once the font is loaded.

I'm not sure how that would work though... would it be a macro patch, similar to iterator, but with a 'string variable' patch to go in it? Or a 'Process image stucture' patch? (Actually, that sounds handy!) Or something else?

what you want is already in there, barring the image processing. - the 'by character' struct gives you the rendered image for every unique character - if you leave the input string blank, it defaults to an alphabet declared in the settings pane. - using the 'by index' struct is probably more efficient than the 'by character' struct as its the same image resource being referenced for the multiple occurences of the letter without the overhead in qc of selecting the character and pulling it out of the structure using qc patches.

Aye, I know that's all in there (well, except the default character set - there should be a note that mentions it, assuming I didn't miss the one that's already there, which is quite likely). I was just comparing your patch with my lump of built-in patches, and the different approaches. I do tend to ramble and get a bit ambiguous, so to summarise it a bit:

1. excellent patch, this
2. some processing would be a good thing

While we're on the subject of text though, what's your thinking on a good method of scrolling?

My current (quick + dirty) method is just to use a really long string, and moving it across the screen. Problem there is you're processing perhaps 10x more characters than you see. You could use a sub range of the string, but then the letters move one character across each time the range is updated and it jerks.

I'm thinking that if you use say a 20 character long string, and instead of shifting the whole string to add a new character you overwrite, it would no longer jerk. You'd then animate with an LFO set to sawtooth so the character moves across the screen then reappears offscreen at the other end with a new char. Any better ideas?

A big issue I've had is fading in characters btw. If you animate a string it runs fine, but if you add a char at a time and fade each new one in, it absolutely cripples performance. Be wary of that :)

• scrolling is a bitch. its impossible to get perfectly smooth scrolling in qc, 'cos its a realtime engine at the mercy of system interrupts: the framerate will glitch, and the eye seems to pick up on that pretty much just during smooth scrolls.

the long string approach is what i've done in the past. i assumed moving one sprite was better than 20 for qc, regardless of their size given the actual rendered size was the same. i could well be wrong, and that approach certainly fails on tiger when you hit the max image size for your graphics card.

a chunk of my livelihood has relied on animating text in qc, and i want that to grow, so i'd imagine some bespoke plugins down this avenue are pretty much guaranteed, and they should trickle down into more generic open source ones.

• fading in i've had problems with, but more in the line of erratic iterator behaviour when the system was under load. this is actually the use case of the plug-in, and the qc comp that preceeded it, was made for. i thought the bouncing up and down was a more obvious demo of the functionality, and left that mental leap to those with the fu =]

Ah, by "a really long string", what I meant was a really long string broken down and rendered per character.

It runs fine even with a long string as I said, and actually with an array of cubes in the background, but it's sure to be having some kind of effect on performance and should be improved.

"'cos its a realtime engine at the mercy of system interrupts: the framerate will glitch" did you try with a system time instead of a patch time , to drive your animations ?

I think toby's complaining about the subtle jitter in framerates making smooth animations slightly inconsistent (i.e. you drop a frame, so the next frame scrolls twice as much, and that jump is more apparent because it's half as smooth, etc).

What he (maybe?) wants is QC to pre-render a frame or more into the future, and thus it only needs to do a framebuffer swap to draw, independent of rendering load. Even this isn't framerate invariant, but it's a bit closer.

indeed... an ahead-of-time rendering engine feeding a core video display link is something i'm working towards in the background.

and, also yep, that reminds me: need to swap out those patch times to system times.

and... see you tomorrow franz, the eurostar awaits.

toby

cool, see you tomorrow..... !

I've done my own versions of these effects, using nothing but the built in tools. So far, I can wrap text around the cube + cylinder objects, with similar per-line scrolling and seamless wrapping. I'm experimenting with GLSL to get some more interesting surfaces, but as today was my first look at glsl it might be slow going.

I'll post up some examples when i've released the demo.