Mesh Creator + Billboard or Sprite = Crash

What QC version are you using? Are you running Lion?

Haven't tried you composition, but I also get a system shut down when ever using the mesh Creator and a Bend Mesh, OpenCL in QC scares me now.

4.5 and Lion.

I don't think that new hardware will solve this problem. IMHO it's a bug. The crash is reproducible for me in QC 4.5 and 10.7.3.

Its the Mesh framework rather than the OpenCL IMETD.

It doesn't in SL... if you flip QC to the 32 bit mode, will it still crash? (I'll try it later on...)

Yep, 32 bit mode produces the same results.

Try uninstalling kinemecore....idk if that's the solution here, just poking around, looking at the crash report at the moment.

The mesh seems to render fine without the billboard or sprite patch, but it could still be the mesh framework.

Also, in terms of OpenCL, I've had a crash every time I hover my mouse over an output of an OpenCL Kernel patch (or macro patch utilizing one) to see the results. Same when using a JavaScript or Structure Count patch to analyze the results.

It crashed before installing as well, I installed it thinking it would help.

I just switched over to Lion... for me, it's not crashing, but it makes my whole monitor screen flicker black (and frozen for a few seconds), and then the Viewer outputs solid white. Sorry to not be of help, I think this is a regression/bug.

(It's crummy that new bugs are coming out with Lion, so long down the road, and that are so basic in nature.)

It's creating a channel exception w/ the driver...

1/11/12 10:02:18.000 AM kernel: NVDA(OpenGL): Channel exception! exception type = 0xd = GR: SW Notify Error

I'm not sure what the total implications of that are, save that some users are saying that they started getting warnings like this way back after 10.5.6, and it's gone back and forth on "being correct" since then.

I sometimes derive such a hovering over a structure output crash, but it is no more to do with OpenCL specifically than it is to do with JavaScript specifically IMHO. You can also get the same sort of crash when using a Mesh with a separate Gradient patch for a background.

Definitely full of bugs are both xCode and Quartz Composer.

I'm using an Intel GMA X3100, so I don't get the "NVDA" part on my crash report - I don't think that's the problem. Also, I'm thinking that if a new computer comes with Lion built in, I'll just try to install Snow Leopard (if I can…).

Try rendering the Mesh in a Render in Image and present to render upon either a Billboard, Sprite or GLSL Grid. You can run layered Sprites or Billboards that way.

My point was that the problem isn't gpu specific...it's happening on a machine without your gpu, BUT only with lion.

Yeah, it's definitely resultant upon trying to make a Mesh and a Sprite/Billboard/Gradient bg concurrently.

See prior comment about wrapping the Mesh patches inside a Render in Image.

It's a workaround at least and works for me.

This is a joke, i'm still having issues with the mesh creator accompanied by any other renderer. Can't find any other solution. Any one found a work around?

What does your composition look like? Is the mesh creator inside of some kind of macro? Try moving the mesh creator to the top level of the composition outside of any macros it doesn't need to be in, and having only the mesh renderer inside; I remember finding a little different bug with it that was "fixed" by that.

The best idea is probably not to use it if you're having to bend over backwards to get it not to crash. Are there any other patches involved that removing will stop the crash?

Here is an simplified version of the composition George, i've tried exploding all the macros, placing RII into the process. But still no luck.

*in addition I don't get the crash whilst QC is running in 32bit mode

I haven't started it yet, because of some of the patches I see involved, and some of the stuff I'm working on... can't do a freeze at the moment :-)

I do see that grid indices generator is involved - I filed a bug on that because it actually will initialize sometimes, and not other times, at least on my machine. At some point, the built in Mesh Bend has also not worked or still doesn't, so I wouldn't be surprised if there's an issue there too. In addition, the normal input on the mesh creator can sometimes not work correctly - using the "set normals" patch afterwards without using the mesh creator's normal input has at least at one time been a workaround.

Not that it matters much, but I was suggesting something more along the lines that if processing patches were in an RII or even something like a lighting macro, to take them out and see if that helped, not the reverse :-) The RII has some kind of optimization that makes it so that if it doesn't think things need to evaluate inside because nothing is firing off a time, they won't, which can screw up compositions in some scenarios. I've also run into some scenarios where the lighting patch will do weird things with some CL kernels.

This is in Lion?

Ok maybe i need to step back here abit and explain what i'm actually trying to actually accomplish.

Simply (but yet annoyingly troublesome) I hoping to get a image into a mesh format so I can use the built in mesh filters.

If the mesh creator is the problem is there another way of doing this? And yes i am running QC 4.6 on 10.7.4

I have had problems with sprites and mesh renders being on the same level. sprites and billboards simply just do not render for me. i don't get a crash. how ever placing everything inside an render in image then using a billboard does work for me. see comp.

So i kinda feel like this should work. I'm tring to map the image onto a plane and then use some mesh filters.

Is this what the 'set mesh texture' for?

Yeah i did try that dustin, it works in a simple composition. But once i place it in a larger composition with a couple of RII patches i get some horrible glitches from the other RII patches :( + i don't want to lose the depth information

If it's reasonable for you to run 32 bit, maybe you could just do that for the time being as a workaround, and file a bug against the 64 bit. If you deploy the qtz as a resource in an app, you could make the runtime 32 bit.

(not that it makes much difference, but I pretty much always run the 32 bit variant. I don't think there's any point in 64 bit math for anything I need to do, and the 32 bit seems more road tested.)

looks like you want to paste album art as texture - best off making your mesh as a grid to size and giving it the appropriate texture. see attached. gets rid of all that os x .dae by framework version problems.