The movie looks really cool, but it crashes my machine - the .qtz that is.
Process: Quartz Composer [1704]
Path: /Developer/Applications/Quartz Composer.app/Contents/MacOS/Quartz Composer
Identifier: com.apple.QuartzComposer.editor
Version: 4.0 (103.1)
Build Info: QuartzComposerEditor-1030100~1
Code Type: X86-64 (Native)
Parent Process: launchd [660]
Date/Time: 2009-11-17 12:25:01.934 +0000
OS Version: Mac OS X 10.6.2 (10C540)
Report Version: 6
Interval Since Last Report: 209224 sec
Crashes Since Last Report: 8
Per-App Interval Since Last Report: 94430 sec
Per-App Crashes Since Last Report: 5
Anonymous UUID: 5480A871-6E0B-4AF4-B8DA-1E7DC47D4D1C
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00000000dfa89000
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Error Formulating Crash Report:
Called memoryAtAddress: 0x8872, which is in an unmappable portion of [0x0 -> 0xffffffffffffffff] in PID# 1704.
0x87799426
0x832520f3
0x8050c0be
0x0000321e
0x00004df8
0x00006a50
0x00007321
0x0000945f
0x0000923c
0x80049474
0x00008943
0x8003cf8e
0x8003ce41
Backtrace not available
was what she said :-) BTW, I've never had an unmappable portion message like ever, so I'm going to investigate a little further just in case it means I have an incipient hardware fault at this end. I hope not.
& then
Followed by another crash when I re-downloaded the composition that blamed GL Tools.
Tried reproducing your working method and found that using a Mesh within the Polygon Mode patch resulted in an immediate crash. Just my luck !
Update
Just managed to place the Text Extrusion into a Polygon and a Polygon Offset and it works beautifully. So I'm still puzzled about your composition crashing QC - reliably :-)
I've attached whereabouts I'm up to with creating something similar, but literally don't have much of a clue about how close this is to what you'd composed as your composition, thus far it just doesn't even get a first render with my installation of GLTools - 1.3.
Well, I haven't looked at this yet (booted in Leopard 10.5 right now), but when I did something similar (the OpenCL video Heightfield thing), I remember having to go through what seemed like a great deal of unreasonable cropping, and in very specific ways, so that-
1: Image bounds can't be defined by the Rendering Destination size.
2: Image bounds can't be defined by an Image Dimension patch that's hooked to a video/external provider.
(when I say "can't be", I mean, "shouldn't be, unless you want the thing to tank".
3: Images have to sometimes be put through a render in image first, if it's not a still.
If that stuff isn't going on, it's really likely to crash at weird times.
Heightfield like this with OpenCL was the first thing I was interested in doing (besides hair and grass w/ OpenCL).
I'm really looking forward to this! I remember that all I had to do to get the GL Tools look was to get my comp and pop it in a Polygon Mode. I'm interested to see what twists this has.
Funnily enough, I've not had many crashes while working on this one. I've been reasonably careful not to edit the OpenCL kernel while the composition is running though.
I've never had to jump through any particular hoops to get images from the iSight working as input to the OpenCL kernel either, I have to say. Though I do have doubts about the Resize patch generally (see my grid/Iterator/Queue example from last week), it's always been fine in this context.
That one works for me, though it's not quite the same as mine, and runs much slower. I didn't have any lighting or normals in mine though, and it's not actually rendering as a mesh, as such (ie not connecting the vertices together as triangles), which I'm sure explains why it's much faster.
Furthermore, no other OpenCL related items of yours from here or machinesdon'tcare ever spits its dummy out on my machine.
Just this one.
If I open it in non GL Tools environment to get a better grasp of what's in the item to some greater extent than having the application crash, then try re-assembling into a working version I still crash, however the ItWorks example, that basically is TextExtrusion, with video instead of text image , does, as its name suggests , actually work and its running an offset Polygon patch too, with a Grid and Mesh in concurrent render.
All puzzling evidence.
Probably something either hardware specific or else software environment specific at my end I strongly suspect.
The lighting does make it run slower, but for me, it was the only reason to "do this" in OpenCL. The only advantage in doing something like that with OpenCL (again, for me), is that with OpenCL mesh rendering, the shadow/lighting works (as close to correct as it can). If not, it doesn't.
Well finally got this working after a fashion by means of cobbling together what I'd found in the non GL Tools environment version that then retained some or all of your Open CL and spliced that within the OpenCL DepthofField example and well with a little bit of kneading here and there we ended up with something very similar using a GLShader, but no Polygon at present.
Impressive OpenCL.
But not achieved for me without some considerable number of crashes.
I must admit to being surprised at how smoothly this little project went for me. As I said, only one crash, which, compared to my previous experiences with OpenCL, was quite heartening.
Well, QC crashes for me too, immediately upon opening them, with both tb compositions in this thread. I hope my dear wife will approve the purchase of an OpenCL capable Mac sooner, rather than later.
Just returned to this item to check how this compared performance wise with the CL / GLSL structures I'd been drafting recently.
Found that my post still worked and that in fact all other items now no longer work, provoking a crash but giving nil report in GF Log or Console for that matter, auto crash saves to desktop but opening these only loops through the seemingly un-loggable crash :-)
Though some OpenCL comps will crash without even running the Viewer... since you were mentioning editing the kernel with the Viewer running, I have to throw out there that setting QC so that the Viewer doesn't open/run by default when you open a qtz is a great idea (almost mandatory). The fact that they have traditionally set that as a default is a really_bad_idea. Also, editing OpenCL with the Viewer running, and to lesser extents, javascript, core image, or glsl, etc (anything you can actually write code in) can all result in crashes. Even noodle connections sometimes.
I tweak values, etc., while the Viewer is running, and sometimes even re-noodle in live/Viewer running scenarios, but that's about it. I'm squeamish about even re-noodling, since even touching the Editor surface can hose what's happening in the Viewer sometimes.
All good points and all is well in terms of being able to examine the construction and redraft , to , eventually, a renderable composition by means of setting the opening prefs to only show editor window .
Of course, there's often many a crash before success following this route .
It's definitely another GLSL Shader related coding problem, but it is more down to the contents of the Core Image processing portion that helps to create the Mesh.
Yes, I've been exploring the two examples you posted up here and the one I posted.
I'd been working upon OpenCL | GLSL combination and Mesh [OpenCL but static .dae input] constructions. Having found that there was often an incompatibility between Mesh Renderer and GLSL within the same RII [ not always, just often :-)] I thought why not check out the set of examples posted up here by yourself. I had thought I'd also posted up a redrafted variant of your construct, but in fact I'd just appropriated a similar result by a slightly different set of patches.
I am still trying to pin down why the contents of the GLSL shader flake out but what I have found since last posting thus far is that it is the Background Clip that provokes the crash.
If that is switched off then the GLSL shader does indeed work, it actually gets a chance to work. So ironically enough, it isn't the GLSL Shader code , nor the Core Image code that causes your posted OpenCL Rutt Etra examples to result in a crash on my machine, but the seemingly innocuous clear patch Macro Patch, tb_RadialBackground.
Suffice to say that replacing the Radial Background with a Gradient patch makes for a renderable composition.
Incidentally, just adding in a radial gradient bg to billboard within the shader doesn't cut it for me :-) - as in just doesn't work, so I think I've narrowed it down to by process of elimination to Billboard when Sprite will work with Radial Gradient and Billboard just won't inside the trackball.
Persistence eh ? :-)
Slight redraft attached - just started snowing again :-)
Checkout the extrusion example I posted longer back...it's been more stable for me than the ones that I've tried on this thread so far, which have all crashed on occasion, at least on my mbpro. Haven't tried the very latest stuff yet.
The thing that I have found is that pixel w/h should be explicitly/manually set in some way on the source image, whether it be a crop or a render in image, and not dictated by image dimensions, or rendering destination dimensions being hooked to those patches, ever. I think that sometimes something is happening with the graph evaluation that makes the OpenCL extrusion flake out and "not know" what the pixel w/h is for a split second, at which time everything bombs out. This is just an educated guess. You can push patches around in the Editor and have the evaluation pause/screw up, and trigger that kind of thing, especially if the pixel width and height aren't "locked in".
I haven't had the time to look through all of these examples closely enough to say that's the cause of any instabilities, I'm just relating my own experience with doing a similar setup.
I do remember trying GLSL on top of the OpenCL stuff and having it work ok, but that there where problems with using Lighting. I also vaguely remember some really bad GLSL bug in SL where pops off the screen when it shouldn't... I think if a render is out of bounds of the Viewer area, that the extrusion won't push back into the Viewer, it just thinks that nothing should show at all. All of that combined makes me lean towards using the Kineme3D Heightfield when I want to do this stuff and not feel like using my computer for a frisbee.
I think you are bang on the money about the split second flake outs & the explicit dimension settings .
Funnily enough though that so much is spoilt by silly things like RII not presenting with 2d what it can present with Rectangle, like Radial Gradient not rendering to a Billboard - these are all fundamental core patches to all intents and purposes .
It's just nice to get some fruitful CL to GLSL action going, although the constant refrain of not on my bit of kit it don't [render] is surely evident of some lack of compatibility far from intrinsic to any individual's composition, but rather found in the Frameworks needed for all compositions .
I did check out your extrusion example some time ago that you posted and a pretty good construction it is too :-) .
No doubt I shall be researching further and experimenting more with the 3D Heightfield approach in due course.
nice one!
Thanks. I've just uploaded a new version of the QTZ (with the same name, stupidly). The new one has an additional Points mode.
a|x
The movie looks really cool, but it crashes my machine - the .qtz that is.
was what she said :-) BTW, I've never had an unmappable portion message like ever, so I'm going to investigate a little further just in case it means I have an incipient hardware fault at this end. I hope not.
& then
Followed by another crash when I re-downloaded the composition that blamed GL Tools.
Tried reproducing your working method and found that using a Mesh within the Polygon Mode patch resulted in an immediate crash. Just my luck !
Update
Just managed to place the Text Extrusion into a Polygon and a Polygon Offset and it works beautifully. So I'm still puzzled about your composition crashing QC - reliably :-)
I've attached whereabouts I'm up to with creating something similar, but literally don't have much of a clue about how close this is to what you'd composed as your composition, thus far it just doesn't even get a first render with my installation of GLTools - 1.3.
Well, I haven't looked at this yet (booted in Leopard 10.5 right now), but when I did something similar (the OpenCL video Heightfield thing), I remember having to go through what seemed like a great deal of unreasonable cropping, and in very specific ways, so that-
1: Image bounds can't be defined by the Rendering Destination size.
2: Image bounds can't be defined by an Image Dimension patch that's hooked to a video/external provider.
(when I say "can't be", I mean, "shouldn't be, unless you want the thing to tank".
3: Images have to sometimes be put through a render in image first, if it's not a still.
If that stuff isn't going on, it's really likely to crash at weird times.
Heightfield like this with OpenCL was the first thing I was interested in doing (besides hair and grass w/ OpenCL).
http://kineme.net/composition/gtoledo3/QuartzComposerOpenCLSnowLeopardTi...
I'm really looking forward to this! I remember that all I had to do to get the GL Tools look was to get my comp and pop it in a Polygon Mode. I'm interested to see what twists this has.
Funnily enough, I've not had many crashes while working on this one. I've been reasonably careful not to edit the OpenCL kernel while the composition is running though.
I've never had to jump through any particular hoops to get images from the iSight working as input to the OpenCL kernel either, I have to say. Though I do have doubts about the Resize patch generally (see my grid/Iterator/Queue example from last week), it's always been fine in this context.
a|x
That one works for me, though it's not quite the same as mine, and runs much slower. I didn't have any lighting or normals in mine though, and it's not actually rendering as a mesh, as such (ie not connecting the vertices together as triangles), which I'm sure explains why it's much faster.
a|x
Furthermore, no other OpenCL related items of yours from here or machinesdon'tcare ever spits its dummy out on my machine.
Just this one.
If I open it in non GL Tools environment to get a better grasp of what's in the item to some greater extent than having the application crash, then try re-assembling into a working version I still crash, however the ItWorks example, that basically is TextExtrusion, with video instead of text image , does, as its name suggests , actually work and its running an offset Polygon patch too, with a Grid and Mesh in concurrent render.
All puzzling evidence.
Probably something either hardware specific or else software environment specific at my end I strongly suspect.
The lighting does make it run slower, but for me, it was the only reason to "do this" in OpenCL. The only advantage in doing something like that with OpenCL (again, for me), is that with OpenCL mesh rendering, the shadow/lighting works (as close to correct as it can). If not, it doesn't.
Well finally got this working after a fashion by means of cobbling together what I'd found in the non GL Tools environment version that then retained some or all of your Open CL and spliced that within the OpenCL DepthofField example and well with a little bit of kneading here and there we ended up with something very similar using a GLShader, but no Polygon at present.
Impressive OpenCL.
But not achieved for me without some considerable number of crashes.
I must admit to being surprised at how smoothly this little project went for me. As I said, only one crash, which, compared to my previous experiences with OpenCL, was quite heartening.
a|x
And another example:
That looks nice!
Cheers!
Here's a newer version.
a|x
Well, QC crashes for me too, immediately upon opening them, with both tb compositions in this thread. I hope my dear wife will approve the purchase of an OpenCL capable Mac sooner, rather than later.
Looks great indeed!
Just returned to this item to check how this compared performance wise with the CL / GLSL structures I'd been drafting recently.
Found that my post still worked and that in fact all other items now no longer work, provoking a crash but giving nil report in GF Log or Console for that matter, auto crash saves to desktop but opening these only loops through the seemingly un-loggable crash :-)
Though some OpenCL comps will crash without even running the Viewer... since you were mentioning editing the kernel with the Viewer running, I have to throw out there that setting QC so that the Viewer doesn't open/run by default when you open a qtz is a great idea (almost mandatory). The fact that they have traditionally set that as a default is a really_bad_idea. Also, editing OpenCL with the Viewer running, and to lesser extents, javascript, core image, or glsl, etc (anything you can actually write code in) can all result in crashes. Even noodle connections sometimes.
I tweak values, etc., while the Viewer is running, and sometimes even re-noodle in live/Viewer running scenarios, but that's about it. I'm squeamish about even re-noodling, since even touching the Editor surface can hose what's happening in the Viewer sometimes.
All good points and all is well in terms of being able to examine the construction and redraft , to , eventually, a renderable composition by means of setting the opening prefs to only show editor window .
Of course, there's often many a crash before success following this route .
It's definitely another GLSL Shader related coding problem, but it is more down to the contents of the Core Image processing portion that helps to create the Mesh.
Are you working on something similar to the above?
a|x
Yes, I've been exploring the two examples you posted up here and the one I posted.
I'd been working upon OpenCL | GLSL combination and Mesh [OpenCL but static .dae input] constructions. Having found that there was often an incompatibility between Mesh Renderer and GLSL within the same RII [ not always, just often :-)] I thought why not check out the set of examples posted up here by yourself. I had thought I'd also posted up a redrafted variant of your construct, but in fact I'd just appropriated a similar result by a slightly different set of patches.
I am still trying to pin down why the contents of the GLSL shader flake out but what I have found since last posting thus far is that it is the Background Clip that provokes the crash.
If that is switched off then the GLSL shader does indeed work, it actually gets a chance to work. So ironically enough, it isn't the GLSL Shader code , nor the Core Image code that causes your posted OpenCL Rutt Etra examples to result in a crash on my machine, but the seemingly innocuous clear patch Macro Patch, tb_RadialBackground.
Suffice to say that replacing the Radial Background with a Gradient patch makes for a renderable composition.
Incidentally, just adding in a radial gradient bg to billboard within the shader doesn't cut it for me :-) - as in just doesn't work, so I think I've narrowed it down to by process of elimination to Billboard when Sprite will work with Radial Gradient and Billboard just won't inside the trackball.
Persistence eh ? :-)
Slight redraft attached - just started snowing again :-)
Checkout the extrusion example I posted longer back...it's been more stable for me than the ones that I've tried on this thread so far, which have all crashed on occasion, at least on my mbpro. Haven't tried the very latest stuff yet.
The thing that I have found is that pixel w/h should be explicitly/manually set in some way on the source image, whether it be a crop or a render in image, and not dictated by image dimensions, or rendering destination dimensions being hooked to those patches, ever. I think that sometimes something is happening with the graph evaluation that makes the OpenCL extrusion flake out and "not know" what the pixel w/h is for a split second, at which time everything bombs out. This is just an educated guess. You can push patches around in the Editor and have the evaluation pause/screw up, and trigger that kind of thing, especially if the pixel width and height aren't "locked in".
I haven't had the time to look through all of these examples closely enough to say that's the cause of any instabilities, I'm just relating my own experience with doing a similar setup.
I do remember trying GLSL on top of the OpenCL stuff and having it work ok, but that there where problems with using Lighting. I also vaguely remember some really bad GLSL bug in SL where pops off the screen when it shouldn't... I think if a render is out of bounds of the Viewer area, that the extrusion won't push back into the Viewer, it just thinks that nothing should show at all. All of that combined makes me lean towards using the Kineme3D Heightfield when I want to do this stuff and not feel like using my computer for a frisbee.
I think you are bang on the money about the split second flake outs & the explicit dimension settings .
Funnily enough though that so much is spoilt by silly things like RII not presenting with 2d what it can present with Rectangle, like Radial Gradient not rendering to a Billboard - these are all fundamental core patches to all intents and purposes .
It's just nice to get some fruitful CL to GLSL action going, although the constant refrain of not on my bit of kit it don't [render] is surely evident of some lack of compatibility far from intrinsic to any individual's composition, but rather found in the Frameworks needed for all compositions .
I did check out your extrusion example some time ago that you posted and a pretty good construction it is too :-) .
No doubt I shall be researching further and experimenting more with the 3D Heightfield approach in due course.