what makes this slow...

bAjA's picture

So i'm not really up to date with what they broke when they released QC4, but i have heard rumors that the iterator is not what it used to be. I have experienced issues with slow frame rates from swapping images using a multiplex in an iterator, but i manged to work round that.

But just now i set out to make a basic composition involving a grid circles pulsating, i decided to use a queue object to pass the circle sizes to the iterator as i figured this would make it easier to play with the pulsating lfo later on.

Very quickly my composition ground to a halt, I will set out to achieve the same result with another method, but i was curious if anyone could shed some light on what the cause of this poor performance is? Also whether i'm imagining that I did simular things before in QC3 without this issue?

cheers - bAjA

PreviewAttachmentSize
spotDrop.qtz23.7 KB

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

photonal's picture
Re: what makes this slow...

I get an additional 15fps by turning off the 'Show Shadow' and 'Show Highlight' option in 'Circle'.

jersmi's picture
Re: what makes this slow...

photonal wrote:
I got an additional 5fps by turning off the 'Show Shadow' option in 'Circle'.
Sucks that it comes to this... I can relate to feeling QC is a slow beast these days. Seems I can't do much anymore without running into fps woes.

dust's picture
Re: what makes this slow...

so this isn't exactly the same effect. i took down your queue fill and dropped the iterations to 10x10 which gives you basically one row. then put that all in a render in image and feed that into an another iterator and stack the file. your going to want to offset the second iteration so it looks like you want.

this patch is running 30 to 60fps with shadows etc...

PreviewAttachmentSize
spotDrop2.qtz27.72 KB

cybero's picture
Re: what makes this slow...

Circle is slower than cube or cylinder and other primitive renderers.

Have a look at this workaround.

Hope that helps - points you in productive direction.

Post Script

LOL - hadn't realised that dust had posted up that licketyspit smart redraft of his [whilst I was mulling over how to improve the originally posted example:-).

That one works really well [better than mine].

PreviewAttachmentSize
spotDropreDraft.qtz23.28 KB

bAjA's picture
Re: what makes this slow...

Thanks for the feedback everyone. I didn't suspect for a moment that the circle patch would be so heavy. I have opted for a sprite with a circle image and ditched the queue idea. Instead I'm playing with the phase of LFOs in the iterator to achieve the pulsating. This makes for more interesting patterns, for sure...

Here is my reDraft...

PreviewAttachmentSize
spotDrop3.qtz19.32 KB

dust's picture
Re: what makes this slow...

i think yours is better than mine @cybero.

@bAjA this third iteration is really smooth and sparkly. i have no idea whats going on your patch... i haven't slept good in a few days and your rounding the aspect ratio to size your grid then running it through an lfo. i'm going to take a nap and study this as i find it very beautiful even though its just circles.

jersmi's picture
Re: what makes this slow...

bAjA: i, too, really like this patch.

The thought of giving up the shadows and gradient fill with the circle patch made me sad. :( So here's another one using your latest with cwright's CIArc patch and vade's v002 gaussian blur. Significant speed increase, plus the cool features of chris' CIArc patch. :)

Also, I still need help centering the gradient on the circle for viewer resizing.

PreviewAttachmentSize
spotDrop4.qtz34.5 KB

bAjA's picture
Re: what makes this slow...

Glad you both like it, it does have a nice sparkly quality... @dust- i hope in the sober light of day you can see it for its simple self.

@jersmi- you where right it had lost something not having highlights and shadows, I like what you did increasing the size variation, once they overlap you get whole new aesthetic. I start seeing scales...

I have fixed some of the numbers to line up the gradients and shadows... I guess it would be most efficient to prepare the highlighted circle and the blurred shadow in photoshop. To cut down operations in the iterator, but I do enjoy this quartz solution...

Great to bounce a composition around like this and see how it evolves.

cheers - bAjA

PreviewAttachmentSize
spotDrop5.qtz21.4 KB

dust's picture
Re: what makes this slow...

yes i finally got some sleep finals are done. woot... woot...

so yes bouncing around comps is fun to see what others do. now that i have some time i can look at this in depth more...

so is it safe to say that the orginal composition was slowed down because of the queue and amount of iterations as the latest version seems to run fine in a smaller grid.

another thought might be to fill up the queue then trigger the iterator or at least with the first example.

cybero's picture
Re: what makes this slow...

That's really nice.

I've tried this construction [#5] with a static mesh and a dynamic mesh - find attached the static mesh - uses the frameworks sphere.dae, so should run straight away [10.6.x only though]. Uses Feedback and Super Sampling too. [30 fps on my 9400]

PreviewAttachmentSize
spotDropMesh.qtz36.93 KB

gtoledo3's picture
Re: what makes this slow...

I haven't looked at it in awhile, but off the top of my head, a couple of these I downloaded remind me a lot of the 3D noise example, as well as the nested iterator example... two favs!

I wonder what the technical reason for the circle patch running so slow is? It seems like the way that it is providing an image, then that shadow, and the blur, all in the renderer might be less efficient than if it was a provider image that fed a sprite...

cybero's picture
Re: what makes this slow...

I think it's all down to pipelining and workspace, how much QC can shoulder.

See the attached RunSpotRun - really flies :-) .

I've also attached here the dynamic mesh draft I was referring to earlier - uses Audio Tools in this construct & I've bundled in an .mp3 bounce of a MIDI woodwind track that I use to generate the meshes.

Hope y'all dig it.

I think they both are 10.6 only, although the Core Image based construct might degrade gracefully; I think that it is 10.6 specific only in regards of its 3d transform [now with scaling :-)].

PreviewAttachmentSize
RunSpotRun.qtz22.96 KB
DynamicMesh.zip1.56 MB

jersmi's picture
Re: what makes this slow...

cybero, i like the meshes with the feedback. and that sphere mesh is remarkably speedy for me.

bAjA, I have some issues sending psd or png with alpha to the v002 blur -- i get image size rectangle haloing i don't know how to fix. besides that, cwright's CIArc patch is plenty of a speed improvement for me. Attached is a qtz with size issue sorted out and takes advantage of the CIArc.

PreviewAttachmentSize
arcDrop.qtz81.22 KB

gtoledo3's picture
Re: what makes this slow...

I think it's the fact that the actual image provider isn't getting iterated X times that makes the composition attached above work better (and any that have the image outside the iterator).

I bet that because of the way that Circle patch works that whatever part that sets up the Circle image needlessly evaluates a ton of times, because it is stuck inside the Iterator, instead of being setup as an image provider that goes to a sprite. I bet the drop shadow feature doesn't do it any favors inside the iterator either!

jersmi's picture
Re: what makes this slow...

gt -- in the arcDrop.qtz I put the image outside the iterator wondering about this but did not see a notable improvement in fps...

gtoledo3's picture
Re: what makes this slow...

I would definitely be curious what optimizations QC does/doesn't have per patch, or when certain things are connected together, in this kind scenario. It could be that traditional image->sprite is iterator aware/optimized, but maybe the circle wasn't coded in a way where someone was thinking about that aspect of use. Never know. Definitely speculation on my part.

It's interesting that if you put the patch in a polygon mode environment, how you can see that there is no front/back side - it's rendered on what is equivalent to a back face. It's also interesting that it doesn't breakdown to a polygon, but that you actually only see a line. I guess it makes sense... but it seems odd that it doesn't respond to a trackball environment either.

jersmi's picture
Re: what makes this slow...

Re: trackball -- you are still referring to the ArcDrop.qtz, right? If so, is that because of how the shape is generated in CI?

gtoledo3's picture
Re: what makes this slow...

I'm just referring to the Circle patch, when placed in a trackball, not any of the particular qtz's posted (so many, I kinda lost track, didn't look at them all...). It's odd that it doesn't respond to a trackball environment, but I guess a Billboard doesn't either.

It's kind of an irritation how many things in QC SL could have worked in an interesting manner in 3 dimensions, but they were only implemented in 2. The intertia bouncy interaction stuff is a key example of that to me. There is no decent way to control it to make it work in Z.

Sorry for the digression off of the main topic...

jersmi's picture
Re: what makes this slow...

Opinion appreciated.

gtoledo3's picture
Re: what makes this slow...

Actually, it's even worse than I thought...

Checkout what the Circle renderer actually is... up to 3 Billboards, Radial Gradients, Gaussian Gradient, ALONG with a Gaussian Blur CI, and even a CI Blend Mode, Image Multiplexers.... Yikes. No doubt that would be a hog in the iterator.

Now I remember having looked at this way back when I was first checking out SL. Crap, I reallllly hate all of these virtual patches that are in the system, and the fact that they aren't always immediately recognizable as such when working quickly. I wish they could have just been Developer examples, or Clips, or Composition Repository...or Virtual Patches, but require the User to move them there or something. Just something more obvious than having to hover over the patch and look for "-Custom". I guess the path to the orig qtz is there in the description, so I'm just whining ;-)

PreviewAttachmentSize
Circle.qtz14.53 KB

cybero's picture
Re: what makes this slow...

This iterates pretty swiftly - 50 - 60 fps , using the same construction for iterating as I used in RunSpotRun.qtz, incorporating your re-engineered circle.qtz.

PreviewAttachmentSize
RunSpotRunRedraft2A.qtz27.64 KB

jersmi's picture
Re: what makes this slow...

uh, cybero, isn't that the same circle.qtz that gt was pointing out as the built-in patch? am i missing something?

cybero's picture
Re: what makes this slow...

You aren't missing much, jersmi :-).

The circle.qtz is a 'reverse engineer' of the custom patch internals.

I was just interested to see how well it iterated was all [ which was pretty well], better indeed than the results achieved by iterating the actual custom patch 'Circle".

jersmi's picture
Re: what makes this slow...

Right -- Circle.qtz is a macro that can be edited using the Library using the pulldown menu.

I am missing this: why does it make any difference in QC using the "reverse engineered" patch over the original Circle.qtz?

cybero's picture
Re: what makes this slow...

In short , taken out of its custom patch wrapper and run in situe, the circle creating macro would seem to operate more efficiently.

This is something that this has in common with other custom patches, clips and virtual macros, namely that although one constructs something, it doesn't always provide both a simple and efficient means of appropriating the desired for graphical effect.

This becomes all the more evident when one iterates the graphical object.

I love it when virtual macros don't only provide a utility or object, but also do that efficiently and fps wise the ease of dropping the Circle onto the editor stage doesn't really compensate for the resulting performance drag which can, ironically enough, be overcome by 'reverse engineering' the item and re-structuring for performance efficiency , the composition one wants to exploit that kind of object within.

I've got a few custom patches that looked like really good ideas , but they worked even better when re-employed in a more broken up / modularised fashion. Then again, some of the custom patches I've made really do provide excellent results under other conditions.

Horses for courses, I guess.

cybero's picture
Re: what makes this slow...

Why does it make a difference ? - now there's a question, probably down to the graphics pipeline and how an iterator deals with a custom patch that effectively contains nested macros.

See attached example, Press i for Info.

This uses the Circle Custom Patch, or a CI Circle piped into the Iterator and a CI Circle within the Iterator.

3 options and once they are fully loaded, the fps difference is entirely obvious.

Now I might have been talking right past you about this, but it is an observable fact that the Custom Patch Circle does not function as efficiently as when its primary component is put to work inside of or outside of an Iterator.

That's the difference it makes, in a nutshell, higher frame rate.

PreviewAttachmentSize
spotDrop123.qtz84.04 KB