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?
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...).
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.
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.
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.
Where is meshConsumer.qtz? I tried looking in the usual places for compositions on SL and didnt see it.
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.
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.
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...).
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.
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.
Precisely.
:-)