GL Look At Very Cool!!

toneburst's picture

I like the GL Look At macro patch a lot! I was thinking of making something like this myself, great too see you've beaten me to it....

Here's a nice little toy I was playing with today.

a|x

PreviewAttachmentSize
RandomWalkTest_01_01.png
RandomWalkTest_01_01.png145.39 KB
RandomWalkTest_01_02.png
RandomWalkTest_01_02.png263.82 KB
RandomWalkTest_01.qtz16.06 KB

gnomalab's picture
Re: GL Look At Very Cool!!

beautifull!!

cybero's picture
Re: GL Look At Very Cool!!

Brilliant, The JavaScript action is great. Lots of possibilities therein.

Interesting to note how increasing or decreasing iterations and step size doesn't seem to increase or decrease frame rate greatly at all.

I had been meaning to try out the Kineme Look patch. Lovely example.

toneburst's picture
Re: GL Look At Very Cool!!

cybero wrote:
Brilliant, The JavaScript action is great. Lots of possibilities therein.

Cheers!

Quote:
Interesting to note how increasing or decreasing iterations and step size doesn't seem to increase or decrease frame rate greatly at all.

Remember it's iterative, so on the first time around, the number of points starts off small.

It's fairly easy to rejig the JS so that it just keeps adding points indefinitely, using array.push. Framerates definitely keep going down when you do this, and I guess eventually would bring your computer grinding to a halt.

a|x http://machinesdontcare.wordpress.com

gtoledo3's picture
Re: GL Look At Very Cool!!

Cat's out of the bag now!

It's fun do set ups like this so that x/y feeds blur coordinates (with some scaling) as well.

That's cool how you decided to draw points via patch time!

What were/are you trying to do with the read pixels?

toneburst's picture
Re: GL Look At Very Cool!!

Incidentally, if you want a little homework ;) , why not try using a Queue patch instead of keeping track of the points structure in the JS patch, and see if that speeds things up any. I'll give it a go myself later, if I get a chance.

a|x

gtoledo3's picture
Re: GL Look At Very Cool!!

BTW, It may or may not be correct, but it's fun to mix the GL Look At patch in scenarios like this with the Field of View for quick zooms.

toneburst's picture
Re: GL Look At Very Cool!!

gtoledo3 wrote:
It's fun do set ups like this so that x/y feeds blur coordinates (with some scaling) as well.

You mean for Depth-of-field type effects?

Quote:
That's cool how you decided to draw points via patch time!

Only way of ensuring the patch keeps executing, even with no control changes.

Quote:
What were/are you trying to do with the read pixels?

Oh, just stuck it in there to see what the depth buffer looked like.

a|x

gtoledo3's picture
Re: GL Look At Very Cool!!

Yeah, exactly, for pseudo depth of field.

The field of view is suggested as a nice "cheat" (well, not really actually) for adding to the whole "pseudo" camera thing as well.

You can make a structure that gets it's values from the camera motion (openCV or optical flow)... but this is way cooler.

This is just wayyyy cool. This is one of the coolest qtz's of all time man! I'd been working on something similar with particle tools, and this just slays it.

cwright's picture
Re: GL Look At Very Cool!!

I have to admit, as soon as I fired it up (and figured out I had to fiddle with patch settings to get anything interesting... ;), it's had me mesmerized all day. tweaking settings etc etc. Too bad JS is so darn slow -- looks like 80% of the execution time is spent in the JS patch. Having it run super-smooth with thousands of segments would be so visually interesting...

Thanks a ton for posting this :)

(and, holy crap, you made use of GL Look At -- that's been in there forever, and no one's used it yet, at least, for posting stuff :)

gtoledo3's picture
Re: GL Look At Very Cool!!

Issa think what I'm going to have to look at is dropping the old points over time... I think it's that the structure gets so big that impacts performance.

It's fun to plug in openCV and use the structure to power something like this (as I have been messing with for the past bit). I have a setup that drops the structure every so often, which seems to be good on performance with this... but it doesn't look quite as cool as this because it makes everything disappear for a split second.

jersmi's picture
Re: GL Look At Very Cool!!

That is so f-in' nice...

and yes to incorporating this with opencv!

rinboku's picture
Re: GL Look At Very Cool!!

Hello! That's nice! I had made similar compositions with triangle too. http://www.vimeo.com/4277423 http://www.vimeo.com/4292197 http://www.vimeo.com/4322049

usefuldesign.au's picture
Re: GL Look At Very Cool!!

Nice work – smooth moving camera really sells it. Like the all best comps LOTS of possible configs.

A bit like a laser simulator I was working on last year but I couldn't get enough lines drawn per second with the javascript patch... ended up using Kineme LineFamiy patch but the geometry is very restrictive... I guess that's another thread which I'll start when I have time to follow through lol.

toneburst's picture
Re: GL Look At Very Cool!!

Cheers for all the positive comments guys!!

gtoledo3 wrote:
Issa think what I'm going to have to look at is dropping the old points over time... I think it's that the structure gets so big that impacts performance.

That's what it does in fact. It gets to whatever the Max Points is you set, then starts again from the beginning, rewriting over the old points.

a|x

toneburst's picture
Re: GL Look At Very Cool!!

rinboku wrote:
Hello! That's nice! I had made similar compositions with triangle too. http://www.vimeo.com/4277423 http://www.vimeo.com/4292197 http://www.vimeo.com/4322049

Very nice.

a|x

toneburst's picture
Re: GL Look At Very Cool!!

cwright wrote:
I have to admit, as soon as I fired it up (and figured out I had to fiddle with patch settings to get anything interesting... ;), it's had me mesmerized all day. tweaking settings etc etc.

Needs a nice shader, I think, or a convincing DoF effect, but the way it builds the points over time is quite cool, considering it's such a simple idea.

Quote:
Too bad JS is so darn slow -- looks like 80% of the execution time is spent in the JS patch. Having it run super-smooth with thousands of segments would be so visually interesting...

I know what you mean. It's funny that the JS should be so slow, really, since it's only doing relatively simple maths. It's not even doing anything to the array of points except writing to a single array index each iteration. Maybe it's just the size of the array that's slowing things down, or the fact that JS is having to deal with lots of Object()s (not a standard JS thing, I suspect), or maybe it's all the Math.random operations. I could try using a Queue to hold the array and a QC Random patch to generate the values, maybe....

I wonder how easy it would be to produce a QC plugin to generate the structure... You could probably do it with the standard API, in fact. Gotta get back to Cocoa/Obj-C...

Quote:
Thanks a ton for posting this :)

No problem! Glad you enjoyed it :)

Quote:
(and, holy crap, you made use of GL Look At -- that's been in there forever, and no one's used it yet, at least, for posting stuff :)

It just occurred to me really. I'd been thinking about doing something similar with the 3D Transform patch and (more) JavaScript for a while, then I saw the Look At patch and though 'aha, I could use that instead!'.

a|x

gtoledo3's picture
Re: GL Look At Very Cool!!

Ohhh, ok. I see that now.

Does yours go blank for a split second when it cycles back?

toneburst's picture
Re: GL Look At Very Cool!!

gtoledo3 wrote:
Ohhh, ok. I see that now.

Does yours go blank for a split second when it cycles back?

I think it does, actually. Probably just some stupid error in the JS.

UPDATE: I think it's to do with the order of the frame-counter being updated and the check that's it's less that MaxPoints. I've done an updated version that should fix the problem., which I'll upload in a minute.

a|x

toneburst's picture
Re: GL Look At Very Cool!!

Fixed 'reset flash'.

Screencap at http://vimeo.com/4607256 if you haven't seen it in action.

a|x

PreviewAttachmentSize
RandomWalkTest_01.5.qtz17.61 KB

gtoledo3's picture
Re: GL Look At Very Cool!!

Yeah, I actually get a debug right then, as well. "undefined value". I have run into this myself on something using javascript to create structure fed to a renderer, and clearing points... My scenario was a bit different and allowed me to split off from the structure, feed to a range patch, and then back... and still has me scratching my head.

I was thinking that it is that there are "0" points, and that there needs to be at least one... but your comment about the order sounds reasonable. I am curious!

gtoledo3's picture
Re: GL Look At Very Cool!!

Coolness, no debug (except for the fog).

gtoledo3's picture
Re: GL Look At Very Cool!!

For a good daub of GL Look At, plus Field Of View, those two qtz renders I did that I titled "virtual installation" made use of that. However, I feed the values with interpolation, and do stuff where some of it is on loop, some is on mirrored loop... and that gives this feeling of "camera cuts".

I think the whole "camera smooth" is really ingenious on your setup, and a remake of the whole "spring/steady cam/crane" type of thing, and the way that it is setup for no sudden jerkiness... it seems like it could be cool to use mouse or space navigator or something like that with this.

toneburst's picture
Re: GL Look At Very Cool!!

gtoledo3 wrote:
Coolness, no debug (except for the fog).

??

echolab's picture
Re: GL Look At Very Cool!!

very nice, respect. is there a way to slow it down?

(sorry, don't know much about javascript)

grischa

usefuldesign.au's picture
Re: GL Look At Very Cool!!

I like it with just sticks and spheres. Here's a remix – dedicated to cybero for obvious reasons. set iterations to 5!

PreviewAttachmentSize
RandomWalkTest_01.5 (remix).qtz19.06 KB

usefuldesign.au's picture
Re: GL Look At Very Cool!!

The comp in the following post has a slowdown patch going into the dummy input of JS patch. (just floored values to stop the JS patch from continuous run). It's disabled just connect it instead of patch time.

echolab's picture
Re: GL Look At Very Cool!!

aahh! the round patch does the trick. thanks.

echolab's picture
Re: GL Look At Very Cool!!

looks cool when it walks to audio...

PreviewAttachmentSize
RandomWalkTest_01.5 (audio_remix).qtz20.08 KB

cybero's picture
Re: GL Look At Very Cool!!

Loved the remixes on these, so protocolised it to be a music visualizer, one that really kicks into life.

Maybe just me but the audio input works faster as a music visualizer.



Electric, Shady, Spooky & Sparky.

Gallons of possibilities for representation. I like the way the settings at time of saving become like great bunches of fruity grapes :-)

Some simple colour shifting and what was already cool lights up like neon.

Thanks .

By the way - just a postscript , but I did notice one odd thing - due to uploading a quartz composition whilst rendering live as a music visualizer, its file size grew and grew - 1.5 MB by the time it decided it had uploaded.

As you can see, a somewhat saner size has been achieved on this upload.

:-)

PostScript - once I'd dropped an Interpolated input onto the Speed setting and set the audio input on the audio remix to built in audio or isight at 0.0001 input scale, the item ran very well speed wise.

echolab's picture
Re: GL Look At Very Cool!!

has someone noticed that the the first iteration is always black? is there a way to avoid this?

cybero's picture
Re: GL Look At Very Cool!!

try changing the default colour on the gl line, point, triangle & quad structure, in deed change them all if you want to - just connect up some lfo or interpolated colour shifter and away you go.

the default colour seems to come from those patches colour settings.

toneburst's picture
Re: GL Look At Very Cool!!

New variation:

This one uses a Queue rather than a JavaScript array to accumulate the points, and a nifty little mechanism to ensure that each triangle appears fully-formed, every 3 frames, while lines and points are drawn every frame.

Also, I'm calculating normals for each triangle, so they can theoretically be lit. Haven't got around to writing a lighting shader yet though.

a|x

PreviewAttachmentSize
tb_RandomWalk_Triangle_13-05-09.qtz28.66 KB

leegrosbauer's picture
Re: GL Look At Very Cool!!

Man, it makes me feel like I'm there inside of it. These pieces are simply stunning.

cwright's picture
Party Pooper

So, this has been a wildly exciting and active thread. I hate to be the bearer of bad news...

but it must be done.

There's a bug with the look at patch. Instead of the camera actually being at the eye point, because of QC's default matrix it's actually at eye point - 1.5 on the z axis (or maybe it's +1.5? can't remember.) That's essentially why the lookat patch is private (that, and it uses glu, which requires a context switch, which is lame for performance).

In an upcoming beta, we're planning on fixing this offset, and doing the math manually, to save the context switch and produce a "real" camera (along with a yaw-pitch-roll camera). This won't break the composition that use this patch, but it will make them appear differently.

Just wanted to give that heads up, so people who use it will know what's coming down the road. If you have any questions, feel free to fire away :)

usefuldesign.au's picture
Re: GL Look At Very Cool!!

Shader would be awesome.

The down side of the alpha blending mode is the fringing around objects, in this case the points at sizes > about 5. I haven't found a way to eliminate this bright-light fringing in alpha blending mode but maybe I don't know what I'm working with :). It always seems to look like an antialiasing mask that is too big. I'm sure there's a good reason for it though :)

I guess the comp could be reworked to use over blending mode but a simple switch produces over lit points.

usefuldesign.au's picture
Re: GL Look At Very Cool!!

This runs beautifully in QC but as a visualiser in iTunes all I get is the Gradient Render (nice as it is). Any ideas? Dual G5, OS 10.5.6, iTunes 8.1.1

toneburst's picture
Re: Party Pooper

cwright wrote:
There's a bug with the look at patch. Instead of the camera actually being at the eye point, because of QC's default matrix it's actually at eye point - 1.5 on the z axis (or maybe it's +1.5? can't remember.)

Ah, yes, I remember that now.

Quote:
That's essentially why the lookat patch is private (that, and it uses glu, which requires a context switch, which is lame for performance).

Didn't realise that.

Quote:
In an upcoming beta, we're planning on fixing this offset, and doing the math manually, to save the context switch and produce a "real" camera (along with a yaw-pitch-roll camera). This won't break the composition that use this patch, but it will make them appear differently.

That's cool. Thanks for letting us know. A yaw-pitch-roll-zoom camera would definitely be easier to use. Looking forward to this one. Meanwhile the current Look At macro is still very cool, bugs or not...!

a|x

usefuldesign.au's picture
Re: GL Look At Very Cool!!

Excellent mods echolab and cybero. The Orb are happy playing with this!

toneburst's picture
Re: Party Pooper

cwright wrote:
...and doing the math manually...

Incidentally, do you happen to know of any good Objective-C vector/matrix maths libraries?

a|x

PS sorry for apparently swamping this forum with my inane chatter lately; I'm excited, and have too much time on my hands ;)

cwright's picture
Re: Party Pooper

toneburst wrote:
Incidentally, do you happen to know of any good Objective-C vector/matrix maths libraries?

Nope. and with any good sense, you'll never find one.

Objc is absolutely the best thing to hit compiled, object oriented code since the optimizing compiler. That said, it absolutely fails at solving certain sets of problems. A broad category of problems it utterly fails at (along with C++ and Java) is doing lots and lots of operations on tiny tiny objects. In this case, a vector (3 or 4 floats) as an objects (TBVector?) would be catastrophic. There's a possible case for matrices (16 floats), but even then there's no point in objc for it (as the method args would be off the charts).

Both of these problems are better served by a low-level C implementation. Then you can toss all the object overhead out the window.

The reason why it fails is somewhat subtle: arrays of NSObjects aren't contiguous in memory, so you lose all cache benefits in loops. Most vector ops are actually very very simple (a dozen instructions or so). objc_msgSend has a very light overhead, but in proportion to the number of instructions a vector op would have, you're essentially doubling the computational cost (or halving speed/theoretical maximum). Combined with thrashing cache performance, and you'll see 1/2-1/4 the speed of a plain-jane C implementation, and that's assuming you're not doing any alloc/init or retain/release/autorelease dances (those will drop you to 1/4-1/16 speed).

(In Kineme3D, for example, there's a fairly simple vector library in there that I tailored myself. It's all C-struct driven, and can deal with [65,000 vertex, 250,000 normal] objects at >60 fps on my machine without any problems. Particle Tools, on the other hand, uses a C++ object per-particle (not even per-vector), and can't maintain 60fps with a mere 5000 particles)

gtoledo3's picture
Re: Party Pooper

Hahah, lop off a zero.... 60 fps with 500 particles can be a chore (with certain renderers/forces).

That's an amazing breakdown of how's/why's.

So, I think this is semi-related... what is going on under the hood why you use a Vertex Shader GLSL (how does it "keep track of" vertexes/normals)? It seems like that is one thing that I can consistently crash QC with, but there's never any telling why/how. It will always be at some random point... but usually with some extreme deformations happening. Whereas... Kineme3D can handle similar deformations and just blaze along.

cwright's picture
Re: Party Pooper

gtoledo3 wrote:
what is going on under the hood why you use a Vertex Shader GLSL (how does it "keep track of" vertexes/normals)? It seems like that is one thing that I can consistently crash QC with, but there's never any telling why/how. It will always be at some random point... but usually with some extreme deformations happening. Whereas... Kineme3D can handle similar deformations and just blaze along.

GLSL uses gpu-assisted (usually) deformation on the graphics card -- this means it can be really fast, and can reuse stuff living on the graphics card (you can upload a mesh, and then deform it just with glsl, and it can reuse the first upload, saving subsequent upload stuff). When it crashes, it's almost always a driver problem (when dealing with lots of data, I've found that the intel drivers can start to barf, especially spread out over time, as data becomes less and less contiguous in memory).

Kineme3D uses software-only deformation (CPU-driven) -- this means that it's stable (no memory trickery), doesn't have to deal with driver quirks, but is also embarrassingly slow (on an Intel GPU, vertex deformation takes place on the CPU anyway because the GPUs lame, so you don't notice a performance difference, but on a real GPU there's a fantastic performance benefit to not using cpu deformation).

GLSL "keeps track" of vertex/normal data because it's all provided to the vertex shader (whether you're rendering with or without GLSL, you submit the vertex/normal data to the card anyway)

toneburst's picture
Re: Party Pooper

Another variation: http://www.vimeo.com/4636184

a|x

gtoledo3's picture
Re: Party Pooper

Ha! I have no idea how you are doing your DOF, but I was just about to log on to chime in that the FreeFrame spiral blur was fun for that.

That looks good. Mmm.

toneburst's picture
Re: Party Pooper

No blurs involved, as it happens, just a sprinkling of shader magic (and a technique that only works for point-sprites, unfortunately).

a|x

toneburst's picture
Re: Party Pooper

Thanks as ever for the explanation, cwright.

I guess the downside of using C is that it isn't objective, which I imagine makes dealing with thousands of identical points more difficult.

Incidentally, with something like Particle Tools, to implement the forces stuff, does every particle have to take into account the properties of every other?

I was reading somewhere about using textures to store particle data. Don't know what the advantages/disadvantages are of that approach.

Is there still mileage in the idea you mooted a while back of a C Struct data type for QC? Obviously, you'd need some tools for creating the structs in the first place, and manipulating the data in various ways, and maybe converting to standard QCStructures.

a|x

vade's picture
Re: Party Pooper

Looks nice!

vade's picture
Re: Party Pooper

GPGPU techniques generally use the idea that texture = array, and that can be used, combined with feedback effects for particle systems for dynamic simulations (physics, etc). So you have some arrays of data, say stored in a float32 texture that really isnt an image per se, but describes other properties, and the feedback system does work per frame calculating the effect of particles on one another, say rgb = xyz position of a particular particle, alpha the weight/mass of the particle, the total xy dimensions the particle count, and uniform variable inputs the forces applied to the particles.

You then apply that texture to a shader, sample the particular texcoord that applies for that particular particle, and do some math and set its position accordingly. These sorts of things generally require texture fetching in the vertex shader, but thats possible now on some cards with 10.5.7.

I havent written anything like this, but ive read about it, and its pretty awesome, but has some GPU requirements that make rolling these sorts of things out difficult.

cwright's picture
Re: Party Pooper

toneburst wrote:
I guess the downside of using C is that it isn't objective, which I imagine makes dealing with thousands of identical points more difficult.

Not so --

typedef struct {float x, y, z} vector;
vector points[1000];
for(i=0;i<1000;++i)
   points[i].x ++;

There, 1000 particles just moved 1 unit on the x axis, and it took about 2000-4000ns. doing that in objc would take orders of magnitude longer.

toneburst wrote:
Incidentally, with something like Particle Tools, to implement the forces stuff, does every particle have to take into account the properties of every other?

It doesn't have to, but some forces actually do. (boids, in particular, needs the properties of surrounding particles to do the right thing).

toneburst wrote:
I was reading somewhere about using textures to store particle data. Don't know what the advantages/disadvantages are of that approach.

The advantage is that the GPU can operate on hundreds of particles at the exact same time, whereas a CPU can work on 2 (if you have dual core) to 8 (with octo-core). significantly faster (as in, dramatic speedup, million-particle systems without a framerate drop, if the gpu's up to the task).

Also, you then have the particles already in vram, so there's up vertex upload step to take time.

toneburst wrote:
Is there still mileage in the idea you mooted a while back of a C Struct data type for QC? Obviously, you'd need some tools for creating the structs in the first place, and manipulating the data in various ways, and maybe converting to standard QCStructures.

There's mileage, but it's limited to Leopard's lifetime -- we're waiting to see a finished version of what Apple has up their sleeve for Snow Leopard. (hint: we stopped spending time on this around June of last year, so you can perhaps infer what we saw ;)

psonice's picture
Re: Party Pooper

Would it be breaking (or at least denting uncomfortably) any NDAs to mention what was mentioned by apple on the QC mailing list, when a ball somewhere was dropped and bounced conveniently out into public view? :)

psonice's picture
Re: Party Pooper

If you want to try stuff like this, grab my Image to GenericRGB plugin here: http://kineme.net/Applications/Compositions/psonicescompositionsandstuff...

Without that plugin, you can't sample textures in the vertex shader without crashing QC. If you use it, make sure you follow how it's done in the example file, as the texture must be prepared a bit first.

Oh, you mentioned that it's possible now with 10.5.7 - has this bug been fixed at last??

As to the technique you mentioned - yes, it would work pretty well for some situations, like applying global forces to all particles. It wouldn't work for things like particle interaction though, because you wouldn't know which particles are near to other particles. There are techniques to handle this, but they're a bit complex for my brain :)

toneburst's picture
Re: Party Pooper

Inference taken, there. I thought you hadn't mentioned that (the C-Structs thing) for a while....

Quote:

typedef struct {float x, y, z} vector;
vector points[1000];
for(i=0;i<1000;++i)
    points[i].x ++;

That's the kind of programming I know. Gotta try and get my head round object-orientated code sometime. I'm so used to using functions and for loops for everything though, which is why JavaScript keeps distracting me from my Hillegass book :(

a|x

send_two's picture
Where is GL Look at?

Hey,

Great patch Alex, really cool and thanks for sharing. You're post on the blog is great, nice way to see how Javascript can be implemented well in QC.

I guess it doesn't matter seeing as I can copy and paste from your patch - but where abouts am I to find GL Look at - I have the GL Tools but as far as I can see its not in the 1.1 release.

cwright's picture
Re: Where is GL Look at?

It's a private patch (yes, kineme makes private patches too -- they're generally special-case stuff, or things that don't have correct behaviour yet, or whose interface will change in the future, or who may just disappear entirely someday), so you'll need to enable private patches (either via the defaults write trick, the option-preferences trick, or KinemeCore's preferences panel)

send_two's picture
Re: Where is GL Look at?

Ah Interesting,

I haven't actually installed Kineme core yet. Are you able to elaborate on the  defaults write - trick, or option-preferences trick you mention, or point me in the right direction.

I opened up the GL Tools package, and saw the GLLootAt patch in the list of other patches, but didn't see any editable preference file. Having said that I don't really know what I'm looking for - so any help is appreciated!

Cheers

gtoledo3's picture
Re: Where is GL Look at?

Ah, this is how I found out about Kineme! I saw this stuff first...

http://fdiv.net/2006/09/19/61-hidden-patches/

The defaults trick is up above...

However, I really advise installing the kinemecore patch (especially checking out latest betas), and then if you don't like having it enabled, all you have to do is quit QC, and move the kinemecore to the trash bin. It's more likely that you will find it indispensable.

send_two's picture
Re: Where is GL Look at?

Thanks for that, perfect!

toneburst's picture
Re: GL Look At Very Cool!!

I've just made yet another variation on the Random Walk example. This creates point by random-walking, then draws bezier curves between them.

I've applied a bloom effect as a post-process.

Requires Kineme GL Tools and vade's v002 blur plugin.

a|x http://machinesdontcare.wordpress.com

PreviewAttachmentSize
tb_Random-Walk Bezier_040609.qtz35.08 KB

psonice's picture
Re: GL Look At Very Cool!!

ribbons with glow! \o/

toneburst's picture
Re: GL Look At Very Cool!!

Glowing ribbons Very Cool! I'm wondering how long it will be before someone steals my code and makes a screensaver out of it. It's a prime candidate.

a|x

toneburst's picture
Re: GL Look At Very Cool!!

Updated QTZ. More options (than strictly necessary, probably).

a|x

PreviewAttachmentSize
tb_Random-Walk Bezier_050609.qtz53.94 KB

cybero's picture
Re: GL Look At Very Cool!!

The peripatetic bezier curve just keeps on getting better and better.

I am really beginning to feel a growing sense of anticipation now of what this type of composition might render like, especially speed wise, when the Leopard that doesn't roar gets released.

:-)

I shall be looking a little later on into the matter of incorporating this and a couple of other spline based compositions into an audio reactive composition.

toneburst's picture
Re: GL Look At Very Cool!!

Hiya!

I'm guessing it's not going to render significantly faster in Snow Leopard.

I'm intrigued to know what other spline-based things you've got lined up!

a\x

cybero's picture
Re: GL Look At Very Cool!!

The rumour mill suggests Snow Leopard shall be faster JS wise, would be nice if that translated into QC's JS, which it should after some fashion if it is a system wide performance improvement for JS.

Splines wise I am seeking to pin down a really good 30 channel spline, y positions from each indexed spectrum band, via an as yet to be satisfactory form of modulation.

However, I'm actually snowed under with shed loads to do right now, so such things shall have to wait their turn with me I'm sorry to say.

Should be somewhat clearer on that front after Monday.

cybero's picture
Re: GL Look At Very Cool!!

The rumour mill suggests Snow Leopard shall be faster JS wise, would be nice if that translated into QC's JS, which it should after some fashion if it is a system wide performance improvement for JS.

Splines wise I am seeking to pin down a really good 30 channel spline, y positions from each indexed spectrum band, via an as yet to be satisfactory form of modulation.

However, I'm actually snowed under with shed loads to do right now, so such things shall have to wait their turn with me I'm sorry to say.

Should be somewhat clearer on that front after Monday.

toneburst's picture
Re: GL Look At Very Cool!!

Ah. OK (on the JS front). Actually, I don't think the JS is the limiting factor, framerate-wise with the Random-Walk QTZs, at least with my later experiments. Using Queues to store values means the JS isn't dealing with large arrays of data, so it's the Queues themselves, and the number of vertices being rendered that's the limiting factor.

Having said that, the maths I'm doing in the JS patch is pretty simple at the moment. Adding complexity is obviously going to slow things down, too.

cwright pointed out the other day that QC uses the WebKit JavaScript engine, so it's hopefully going to speed up with future updates to that framework. In fact, it looks, from what he was saying about a little JS bug (or maybe it's a 'feature') I discovered the other day, that the new Safari Beta (and associated WebKit improvements, presumably) has brought changes to the way JS is run in QC, so lets hope as WebKit is updated, QC will continue to benefit.

a|x

photonal's picture
Re: GL Look At Very Cool!!

Can't believe I missed your fantastic Random Walk, only just discovered it - really great! thanks for sharing this.