they say Mesh filters now work again.... they say they corrected A performance bug, probably iterator problem.

Unverified tho', as i quit on being an alpha tester for apple and void my os and endanger my work each there's a new point release.

It's not sure 10.6.3 will be better than 10.6.2 (but hardly worse) Note that i'm still on 10.6.1 and 10.6.0 on my computers. (and my dev machine is 10.5.8)

Quote:
llvm - Resolves segmentation faults. - Resolves some compiler crashes. - Improvements for OpenCL and OpenGL.

and

Quote:
MeshKit - MeshKit framework improvements.

and

Quote:
OpenCL - Resolves some OpenCL compiler issues. - Resolves some OpenCL conversion issues. - Fixes some OpenCL crashes. - Resolves some OpenCL Framework issues.

and

Quote:
QuartzComposer - Resolves a crash in Mesh Filter. - Resolves a performance issue in Quartz Composer.

look promising.

a|x

who's compiling with llvm ? I'm using gcc4.2 - and thought apple would support clang instead.

I just love the 'Somewhere on the Internet'

Quote:

Somewhere on the Internet we picked up the seed note which warns of four unresolved known issues:

• Applications may not be updated if they had been moved from the default location.

• Displays Preferences may show duplicate profile entries.

• iTunes may hang when playing a web stream.

• The ColorSync Utility Filters tab may cause unexpected results.

• ~

Otherwise it rather reads as if Apple have been addressing both the issues that have been raised by users such as ourselves - looking forward to the update.

I thought llvm was used by QC to compile GLSL shaders. I might be completely wrong though.

a|x

we use LLVM pretty heavily (it's codegen is generally a few percent better than gcc-4.2, which can be slightly better than 4.0, or measurably worse (though maybe they've addressed that?))

LLVM is used in a number of places (never directly by QC):

• OpenGL drivers tend to use it for glsl compiling (and intel drivers even use it to synthesize features on the fly, since their hardware doesn't actually do anything ;)
• CoreImage tends to use it for kernel compiling
• OpenCL tends to use it for CL kernel compiling (confirmed by slips of the tongue by both AMD and NVidia engineers at siggraph and WWDC08)
• llvm-gcc-4.x is used to compile C, C++, and Obj-C source code into binaries (much like GCC and GCC-4.2)
• Clang uses llvm to compile C, objective-C, and some C++ into binaries (like gcc and gcc-4.2)

Don't get your hopes up. You'll be disappointed. Running it.

Mesh bend, mesh noise = still kaput

Mesh template = doesn't crash

Whoopee.

and iterator performance ? fixed ?

mean i should compile my stuff with llvm for a performance boost ? - i should try that .... ') thx for the tip

Not tested yet... I got to no mesh filter fix (save for template), and dae's rendering with different scaling, turned it off, and switched over to 10.5 for the rest of the day (and since). When I'm feeling more masochistic, I'll switch back over.

Well, to be fair, you are running a debug build, not the final. This is however coming from someone on 10.6.1 :)

Have you ever seen the debug change from the final with any seed, besides prerelease? Or rather... the build number, is the build number, and seeds see release as is for that build number.

you should try with both, and measure. Often it doesn't matter at all, but for some math-intensive code it can help (and in other, rare cases, it can hinder). The only real big downside with LLVM is that it doesn't output debug information that's compatible with a lot of profiling and debugging tools (or it doesn't output some debug info at all :/) -- with the latest iphone sdk it's actually not too bad (in the beginning, it was nearly impossible to get anything meaningful out of shark when using LLVM, iirc)

I need a bit of popularization (and i'm not the only one i suppose). Could you bring those information into general use. Does QC4 will be improve by this update ? i mean, is there some specific changes, dedicated to QC in this update ? If not, is there some non-specific changes that could affect directly QC4 performances ? What matter for neophyte is: will QC4 work "as well" as QC3 one day... ? (it should do better "usually" !!!) Does Apple seems to get an interrest for QC users in this update ? It does sound very optimistic, am i wrong ?

Apple can post multiple seeds of an OS update. All I am saying is you do not know what the final build number is.

im running 10.6.1 have tried to run 10.6.2 but QC and other apps tht use QC stuff just don't work. tried switching the frameworks but still couldn't get 10.6.2 2 launch. would like to know if qc works with 10.6.3 as well.

Oh, I got you on that, but it seems like the pattern is that pretty much every seed/build does get released as is (I didn't think that any haven't been released as is eventually, since the GM), then they just get to work on the next one.

Well, this is definitely good news for folks like me :P

http://www.macrumors.com/2010/01/12/apple-progressing-toward-full-suppor...

Some of those extensions can be super useful.

Well, it's good to know there is some kind of upside (assuming you've been successfully using these extensions).

....but in my little world of concerns, when you get an official note that tends to indicate that Mesh Filters are working right again, and that fixes have happened to OpenCL... you would tend to think that when you tested, you would actually see fixes.

The fact that the only friggin' thing that is working better is that Wind Tunnel comp (because it will actually open now instead of throwing an exception), and even then the DAE is rendering at totally different scale, and with some other weird problem, is not heartening. They aren't even pretending to try to maintain features across updates, or any kind of consistency.

I don't understand how we can be from .2, and now .3, and on BOTH, there are two major mesh filters broken- bend and noise. I dread working in SL, because I'm always gung-ho, then I get disappointed. Initially, I was pretty peeved that there were more bugs than Leopard, but now that there are more bugs than earlier versions of SL, it's like "WTF".

When it gets to the point where a team has spent time on "updates" and it breaks standard, public, features, that should be really OBVIOUS... my opinion is that they should bite the bullet and regress, or not release those updates, whatever the case may be. At this point, I would be way happier if they would just update QC to be how it was in the GM, because at least it worked.

Any serious business would have to be insane or just plain stupid to use OpenCL for anything at this point, because it's a moving target.

....and I will add; it's gotten to the point that I have a list of +12 unfiled bugs, but I REALLY DON'T CARE at this point, after my results from spending time filing bugs in earlier seeds. The responses I've gotten from bug reporter have been insane at times, like the person vetting the stuff hasn't even ever looked at QC. The other thing is that many times, it's totally obvious that the problem scenario isn't being totally duplicated (BUG REPORTER, you need to match ALL conditions, duh), like running on a certain graphics card, or running QC in 32 bit vs. 64 bit. So, if I spend close to a day hunting something down, then spend an hour writing a detailed report, I may as well be getting paid. It's wayyyyyy against my values to be doing what amounts to free work for Apple, vetting the steaming pile of shit that they call QC4.

So tell us how you really feel :)

Yeah, I thought about mincing my words some, but this last update was a full fledged piss off.

Quote:

I would be way happier if they would just update QC to be how it was in the GM, because at least it worked

quite agree actually, although unlike a lot of others my level of misery with 10.6.2 has been intermixed with a lot of rewarding and fruitful sessions in 10.6.2, but if the 10.6.3 just gets worse then it really should be time to regress and refresh.

I can't say it's worse, just that the only tangible improvement is that when you select a mesh filter template, that QC doesn't crash anymore. Who the hell cares though, since mesh filter function is totally undefinable at this point, since Apple's own examples don't work. It's kind of like putting a band-aid on to try to re-attach a limb.

My complaints about the iterator, the shadow engine, and the undesirable GUI changes almost seem quaint now, given that the whole thrust of the QC update was this OpenCL crap, and built in model rendering, etc. The only thing that was "sort of" cool about the DAE loader is the way it loads textures, except that I still don't like it, because the texture is imported through a mesh port, instead of being it's own separate "pipeline". I'm 100% certain that Chris could have done texture loading in the same way, except that... Apple's conceptualization was poor, and I don't think Chris would have conceived to have approached it in a way that's out of whack with the rest of QC. For textures not to load through their own image port is out of line, and the whole "set texture" thing is lame-ola to the max.

Boy, I seem surly about this, but I assure you all I have a big smile on my face. More than anything, I feel like:

1. I love QC.

2. It's like someone disrespecting something you love (ala the Apple team).

3. A bunch of change for the sake of change, without being actually useful is a recipe for disaster.

4. Does anyone even test this crap before they release it?

I feel confident about there being a resolution to this eventually, but it's frustrating in the meantime.

To chime in a bit (since I was name-dropped ;):

I debated about loading textures in kineme3d. The main reasons not to were as follows:

• MD2 uses pcx (loading pcx is ridiculously difficult because ImageIO doesn't do it for you, and writing image loaders stopped being fun when I was 17)
• FBXSDK is a joke (just getting vertex data out of it is somewhat miraculous -- just the other day gtoledo discovered a bug where loading a certain OBJ causes it to export to a collada (in memory), and then reparse the collada (in memory) and crash... idiotic) -- paths for image resources aren't consistent, nor is image data inside the sdk (when it does it itself).

Further complicating things, I like stuff in QC to be editable -- I like people being able to tweak individual vertices, normals, texture coords, and colors of a mesh. (Kineme3D didn't expose any of this, because QCStructure is unusably slow on 10.5, and this wasn't addressed until 10.6). QC's approach (bundle vertices, normals, colors, textures, and texture coordinates all together as an opaque object) didn't "feel right" to me (and still doesn't) -- sure, you can break out stuff using mesh components (except for texture coords, for some unknown reason), but it just feels like it shouldn't be another data type (esp. when it's composed of all the other already-existing data types). The same case could be made for images (images are just integer dimensions and a huge array of color data), but it feels "ok" because of how users use them (and performance would be awful if you had to synthesize images from in-memory data all the time for filters etc).

When you have numbered lists like that, it looks funny and huge in my RSS reader :)

re: The big font:

First time I did it, it was an accident, but it makes me laugh when I see it, so I do it on purpose now.