Interesting...more video spheres! :-) What brought this about?
(I feel as though the Rutt and K3D heightfield have both been superseded by extrusion with OpenCL, and also, the fact that you can also do extrusion in GLSL now... both routes are more flexible, imo, and OpenCL can pull off higher res and looks better with lighting.)
I feel as though the Rutt and K3D heightfield have both been superseded by extrusion with OpenCL, and also, the fact that you can also do extrusion in GLSL now... both routes are more flexible, imo, and OpenCL can pull off higher res and looks better with lighting
Quite agree as to how useful and flexible OpenCL is, although I've also been re-discovering just how useful and apposite these other plugins and technologies can be, even though I'm very enthusiastic about what OpenCL can do.
For instance, sometimes a CI Filter will do a far better job of a particular type of routine [ or perhaps I'm better at creating these in CI rather than OpenCL ]. Of course, OpenCL will do a whole lot of things that CoreImage won't do or support.
Displacement of vertices can create incredible effects and the Mesh Renderer patch takes a whole range of scaling. Similarly a displacement shader can be placed within a Polygon Mode patch. It all opens up a whole load more in the way of possibilities.
I do find that these sort of OpenCL pipelines work brilliantly in QC, but sometimes are resistant to offline rendering - then its off on one or another of the memory leaking loop outs. For instance, Image Resize can and does lower the breaching of some sort of accumulative threshold resulting in offline renders and also screen captures for a set of Gradient Flow CL to > Optical Flow CL to > Turbulent / Gradient/ Ridged / Mono CL to > Image to Mesh CL works more reliably when the Image is resized down prior to meshing.
Just a matter of processing power / time, I guess.
Here's my take, to clarify, because I have no inherent criticism, and I'm worried it may have come across like that, whereas I think it's cool and gave it a point :)
If something can be done without a plugin, I opt to do it without, because it's more portable, less likely to break in the future, and has no licensing or intellectual property aspects involved.
While I see the point of opting for a plugin for acceleration of performance in the case of duplicate functionality, I usually regret it when I've used a plugin for something that can actually be done stock. When that happens, you're also subject to changes and updates in that plugin. So if you've made something based on a plugin, and this plugin gets some new functionality, or loses functionality, you're totally at whim of the manufacturer of the plugin.
Two cases-
Introduction of new scanline modes in Rutt. Not bad, but has confounded people in some cases.
Lack of Alpha Blending with GL Tools now (though I can't do anything about that one, as there is no stock workaround.)
With GLSL, you can do the extrusion, you can do the scanlines, you can do the dots, the full mode, and you can do a "mirror mode" for making convex hulls (there was a thread where this was fleshed out, kudos to fsk and vade for their chiming in as well). I can't, offhand, think of any aspect of function that can't be achieved with the stock GLSL patch. This wasn't the case in Leopard, so the Rutt was a must.
With the OpenCL extrusion, the scenario is similar, except that it can do a much higher vertex count (at least on my laptop) than either method, to the point where it looks much more "high definition". The thing that's nice visually is that the res can be so high, and stuff can be so smooth that it gets a "wet" look that's very appealing. Again, all the draw modes can be achieved one way or another too.
This isn't criticism of the comp or Rutt, it's more that it reminded me of regret for the fact that I did something that used Rutt when I was still hanging onto Leopard for stability issues, when I feel like it would be way cooler in SL now with stock patches and some new stuff that can be done, but I haven't had any opportunity to update.
Are you using that OpenCL Converter on the renders that are failing?
I am hardly ever using the OpenCL converter for anything at all - not nowadays anyhow.
I like that wet look. I find that suits well Triangle into Full Render, not Wireframe and also Points. although they can also produce a great instant grid if made smaller. Also the crazy high scale "Etra" like effects. Another favourite thing about the OpenCL graphics.
I am finding my primary pitfall nowadays with OpenCL is down to either bad coding on my side, or else good code that runs AOK in QC, can be screen recorded, but doesn't like being offline rendered. That's especially sad.
Having said that, this seems especially the case when running the OpenCL OpticalFlow kernel. I think I need to take another close look at that.
I think a set of kernels can do the sort of task that the convertor is meant to do, but being editable, it can be updated / corrected & improved upon if needs be.
That's my suspicion on the OpenCL converter [it needs updating :-)].
Besides I can provoke an OpenCL related crash just by asking that the OpenCL routine render a 1280*720 full definition re-mesh, especially when there is a lot of changing graphical "information".
I find myself drawn recently to looking at raw array renders, though avoiding the Volume setting on the Mesh Creator [too many complications].
The good thing about the increasing proliferation of GPU accelerated plugins for QC is that they are likely to be improved upon and thus provide increasingly flexible means of exploiting OpenCL in the QC pipeline.
For me, given my recent involvements, I think the next logical thing would be a Wavelet Transform image kernel.
Interesting...more video spheres! :-) What brought this about?
(I feel as though the Rutt and K3D heightfield have both been superseded by extrusion with OpenCL, and also, the fact that you can also do extrusion in GLSL now... both routes are more flexible, imo, and OpenCL can pull off higher res and looks better with lighting.)
Good study example, both the GLSL code and the efficient construction.
Interesting way of getting a dynamic texture, using the LFO & Checkerboard.
Quite agree as to how useful and flexible OpenCL is, although I've also been re-discovering just how useful and apposite these other plugins and technologies can be, even though I'm very enthusiastic about what OpenCL can do.
For instance, sometimes a CI Filter will do a far better job of a particular type of routine [ or perhaps I'm better at creating these in CI rather than OpenCL ]. Of course, OpenCL will do a whole lot of things that CoreImage won't do or support.
Displacement of vertices can create incredible effects and the Mesh Renderer patch takes a whole range of scaling. Similarly a displacement shader can be placed within a Polygon Mode patch. It all opens up a whole load more in the way of possibilities.
I do find that these sort of OpenCL pipelines work brilliantly in QC, but sometimes are resistant to offline rendering - then its off on one or another of the memory leaking loop outs. For instance, Image Resize can and does lower the breaching of some sort of accumulative threshold resulting in offline renders and also screen captures for a set of Gradient Flow CL to > Optical Flow CL to > Turbulent / Gradient/ Ridged / Mono CL to > Image to Mesh CL works more reliably when the Image is resized down prior to meshing.
Just a matter of processing power / time, I guess.
Here's my take, to clarify, because I have no inherent criticism, and I'm worried it may have come across like that, whereas I think it's cool and gave it a point :)
If something can be done without a plugin, I opt to do it without, because it's more portable, less likely to break in the future, and has no licensing or intellectual property aspects involved.
While I see the point of opting for a plugin for acceleration of performance in the case of duplicate functionality, I usually regret it when I've used a plugin for something that can actually be done stock. When that happens, you're also subject to changes and updates in that plugin. So if you've made something based on a plugin, and this plugin gets some new functionality, or loses functionality, you're totally at whim of the manufacturer of the plugin.
Two cases-
Introduction of new scanline modes in Rutt. Not bad, but has confounded people in some cases.
Lack of Alpha Blending with GL Tools now (though I can't do anything about that one, as there is no stock workaround.)
With GLSL, you can do the extrusion, you can do the scanlines, you can do the dots, the full mode, and you can do a "mirror mode" for making convex hulls (there was a thread where this was fleshed out, kudos to fsk and vade for their chiming in as well). I can't, offhand, think of any aspect of function that can't be achieved with the stock GLSL patch. This wasn't the case in Leopard, so the Rutt was a must.
With the OpenCL extrusion, the scenario is similar, except that it can do a much higher vertex count (at least on my laptop) than either method, to the point where it looks much more "high definition". The thing that's nice visually is that the res can be so high, and stuff can be so smooth that it gets a "wet" look that's very appealing. Again, all the draw modes can be achieved one way or another too.
This isn't criticism of the comp or Rutt, it's more that it reminded me of regret for the fact that I did something that used Rutt when I was still hanging onto Leopard for stability issues, when I feel like it would be way cooler in SL now with stock patches and some new stuff that can be done, but I haven't had any opportunity to update.
Are you using that OpenCL Converter on the renders that are failing?
I am hardly ever using the OpenCL converter for anything at all - not nowadays anyhow.
I like that wet look. I find that suits well Triangle into Full Render, not Wireframe and also Points. although they can also produce a great instant grid if made smaller. Also the crazy high scale "Etra" like effects. Another favourite thing about the OpenCL graphics.
I am finding my primary pitfall nowadays with OpenCL is down to either bad coding on my side, or else good code that runs AOK in QC, can be screen recorded, but doesn't like being offline rendered. That's especially sad.
Having said that, this seems especially the case when running the OpenCL OpticalFlow kernel. I think I need to take another close look at that.
I think a set of kernels can do the sort of task that the convertor is meant to do, but being editable, it can be updated / corrected & improved upon if needs be.
That's my suspicion on the OpenCL converter [it needs updating :-)].
Besides I can provoke an OpenCL related crash just by asking that the OpenCL routine render a 1280*720 full definition re-mesh, especially when there is a lot of changing graphical "information".
I find myself drawn recently to looking at raw array renders, though avoiding the Volume setting on the Mesh Creator [too many complications].
The good thing about the increasing proliferation of GPU accelerated plugins for QC is that they are likely to be improved upon and thus provide increasingly flexible means of exploiting OpenCL in the QC pipeline.
For me, given my recent involvements, I think the next logical thing would be a Wavelet Transform image kernel.