meshConsumer.qtz

cybero's picture

Anyone ever figured out why meshConsumer.qtz is encased within a Lighting Environment patch with Shadows enabled, making it's function more slowly ?

Does it really make any difference, I wonder ?

Comment viewing options

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

SteveElbows's picture
Re: meshConsumer.qtz

Where is meshConsumer.qtz? I tried looking in the usual places for compositions on SL and didnt see it.

gtoledo3's picture
Re: meshConsumer.qtz

Yeah, so it can show shadows on the Sprite below - that's pretty obvious. It's an aesthetic choice.

What actually doesn't make sense is for there to be a Trackball environment that's unused.

@steve, it is a resource of the QuartzComposer framework. It's not particularly interesting for any reason, imo.

cybero's picture
Re: meshConsumer.qtz

Well, I can understand the matter of aesthetics, & although I quite like the Trackball effect, I can see why you would question its inclusion whilst being unused .

Not so sure it doesn't matter much at all though; that's a Shadow set Lighting Environment which is slower than without Shadows on.

Strikes me that whensoever this framework item is called upon, surely, it is still dragging that inefficiency in with it?

I'm not sure, but seems a possibility to me.

gtoledo3's picture
Re: meshConsumer.qtz

My theory is that the trackball showed how the shadow engine / model is broken, because of the way that you can see the backside of a sprite getting shadow, when it "shouldn't".

Yet, instead of going the extra mile to remove it (or maybe better, to rethink the shadow functionality entirely), which would be the correct route, someone just flicked it off.

I see the aspect that if one was using the template for making mesh filters, and had to endure the shadow being "on" all the time, that it would be tedious.

I don't use the templates for things like that (a could go on a long tirade about protocols and how they are implemented in QC...).

cybero's picture
Re: meshConsumer.qtz

I think you traced out the scenario likely as not producing the resultant MeshConsumer.qtz

So it's only being called via the Welcome.qtz then & yes, I too am avoiding the Mesh Filters template, much though I liked the Sine Wave Sphere Mesh resulting & it's usefully annotated too.

I sometimes wonder just how swapping the Sphere.dae for a Cube.dae might radically alter the rendered result.

Might try that out.

BTW, the 10 * 10 Grid comp you posted takes a dynamic OpenCL kernel plasma image pretty nicely indeed.

Do you know what though, seeing as how it is a part of the QuartzComposer.framework, I'm still not entirely convinced, but I'm beginning to avoid concerning myself about the matter.

Will probably experiment on this some other time.

gtoledo3's picture
Re: meshConsumer.qtz

It's just a typical resource that the app and/or system loads when it's called on... it's probably there instead of inside the app in case any other application needed to make use of it for some reason (so that developer tools/QC doesn't HAVE to be installed for a system to have a way to view mesh protocol compositions). It would be inherently lame if the system had no way to view this kind of protocol without the Developer Tools installed.

When you call up the Welcome(qtz), and you see the visualization of the Template - that is internal to the Welcome qtz, so at that point, the meshConsumer.qtz still isn't being called. It's only called upon once you actually are running a composition that's tagged as being Mesh Protocol, like when you actually choose the Mesh Protocol Template and create a new composition.

I find that my impression of what a given setting does is definitely made more robust by looking at how it effects multiple models; substituting with a complex cube is useful sometimes.

I'm being redundant, but that extra useless trackball environment irks me. I may do something like that in a personal demo, but this is an OS, and it's a RELEASE. I hate the idea of cruft like that. It's antithetical to what Mac is supposed to be about, to me at least. I don't like the idea that because the advantage would be so slight that it wasn't worth it to take the 5 seconds it would have taken to do it the right way.

cybero's picture
Re: meshConsumer.qtz

Quote:
I'm being redundant, but that extra useless trackball environment irks me. .......... I don't like the idea that because the advantage would be so slight that it wasn't worth it to take the 5 seconds it would have taken to do it the right way.

Precisely.

:-)