It's just a tool to bake lightmaps. Most 3d packages do this already. Make a city in your favourite 3d package, use your lighting model of choice (beast uses global illumination), bake the lighting into your textures, load the textured model into qc or whatever and you'll get similar results.
Next job, implement this in realtime ;) [seriously, that's how everyone does it - the 'hard to do' lighting is pre-rendered for the static scenery, then some low quality 'hacky' lighting (say some basic soft shadowing plus SSAO) is used on everything that moves]
Psonice, give me a little credit ;-) It's not that this does anything that can't be done in apps already (and that I haven't been doing a ridiculous amount for the last bit), it's more that I thought it was cool that it was game engine independent.
I think it would be really helpful and efficient if QC actually had provisions for this sort of thing (crazy huh!?). I'm always kind of fascinated by hacktastic stuff like that - like how Z-Brush goes ahead and "locks in" stuff you aren't working on, so that your computer doesn't go into a spiraling death grip.
Of course it's game engine independent, so is maya and softimage ;) It's just generating a lightmap, and baking it into the textures (not to put it down, it does a fine job judging by the screenshots). If you can load a textured mesh into QC, and export in a compatible format from beast, it works with QC too.
I'm guessing beast is pretty much the same as many other lighting systems, but more game focused (so it'll generate texture data meant for realtime, and formats used by the various game engines).
Oh, and you can do something like this in QC yourself. High end lighting is possible with a shader or two, but not in realtime (at least not at this quality). But you can do this once, and save the results to a texture (i.e. you bake the lighting when the comp starts). Then you can use your nice ambient occlusion or whatever (real AO, not the SSAO crap we normally do ;) with very little speed hit.
I used smash's (of fairlight fame) 64kb intro tool once for a demo we did some years back. That worked this way - you make a mesh, then hit the 'generate lightmap' button, it goes and does some fancy AO for 0.5 seconds and you have cool lighting.
Hmm, good point about "baking your own maps" using QC, except that if you write it/read it to file, QC isn't going to handle it well (you may have to do clever things to cover possible stutter steps with largish images, and that's lame), and if you use something like a sample and hold or a RII to hold the image, your going to start bogging stuff down.
I know you're being a little tongue in cheek with the comment about maya... yeah, you can use an app to render lighting to your textures, and you can do workarounds in QC (albeit cludgy). A lighting engine that was well integrated could allow us to "save to texture" without stalling the viewer when the image loads (this could also be implemented with K3D and the stock OpenCL meshkit and SHOULD BE). We just "wouldn't see" the image (or resource) until it loads, and we wouldn't have the friggin' beachball. This is something I was talking about with cwright when he went off to Valhalla ;-)
Boy, maybe if people were like "yeah, give me some good lighting tools" we might actually get them! Sometimes it's sort of sad to suggest QC doing stuff that actually expands it's potential uses into the realm of non-trivial, and see it get limited traction. I feel like the QC community can be sort of lifeless in envisioning where the tool could go in making it less niche (not referring to you psonice, or anyone on the board, more the people that DON'T chime in too much, but use QC for professional activities and are lurkers).
QC is Apple's only genuine 3D graphics engine, and it's only real tech that allows for the extensibility and ease of use that is good for designers as well as programmers (not saying it's there yet- coding in QC and some other aspects need to be amply fleshed out). As such, I think it needs a lighting model that doesn't_suck. The QC lighting model is problematic and should be slowly deprecated, while be shored up by a more fully featured shader engine.
A QC that doesn't eventually go into areas like this is going to be a QC that stays stuck in SL while we've all moved onto other stuff.
gtoledo3 wrote: I feel like the QC community can be sort of lifeless in envisioning where the tool could go in making it less niche (not referring to you psonice, or anyone on the board, more the people that DON'T chime in too much, but use QC for professional activities and are lurkers).
And strangely enough, there are a ton of them. The crash counts we get internally are insane compared to what I collected at Kineme. And yet there's no discussion outside of about half a dozen users. :/
gtoledo3 wrote: As such, I think it needs a lighting model that doesn't_suck. The QC lighting model is problematic and should be slowly deprecated, while be shored up by a more fully featured shader engine.
Those are mutually exclusive, to some extent. non-sucky lighting models are shaders, so a more fully featured shader model = you are in charge of making it not suck. There's some overlap (built-in defaults, etc) of course, but there's only so much handholding to be provided. When you look at demos like what psonice posts, it's imperative to understand that that's the end result of tons of effort in making great shaders, and QC cannot possibly do that for you.
gtoledo3 wrote: A QC that doesn't eventually go into areas like this is going to be a QC that stays stuck in SL while we've all moved onto other stuff.
goes into shaders, or non-niche areas? (not exclusive or, but do understand that time isn't unlimited)
cwright wrote:
And strangely enough, there are a ton of them. The crash counts we get internally are insane compared to what I collected at Kineme. And yet there's no discussion outside of about half a dozen users. :/
Does that include users of OS X apps that crash which are using the QC framework in some way or is it exclusive to users using the QC application itself (ie. Editor)?
gtoledo3 wrote: Hmm, good point about "baking your own maps" using QC, except that if you write it/read it to file, QC isn't going to handle it well (you may have to do clever things to cover possible stutter steps with largish images, and that's lame), and if you use something like a sample and hold or a RII to hold the image, your going to start bogging stuff down.
No, the idea is to generate these maps [i]before[/i] the composition starts running. For a big scene, you're looking at several seconds to several hours (depending on the method you use) to generate the light maps. Loading the scene and showing it unlit for half an hour while the maps are calculated would suck bigtime ;)
Quote: I know you're being a little tongue in cheek with the comment about maya... yeah, you can use an app to render lighting to your textures, and you can do workarounds in QC (albeit cludgy). A lighting engine that was well integrated could allow us to "save to texture" without stalling the viewer when the image loads (this could also be implemented with K3D and the stock OpenCL meshkit and SHOULD BE). We just "wouldn't see" the image (or resource) until it loads, and we wouldn't have the friggin' beachball. This is something I was talking about with cwright when he went off to Valhalla ;-)
Nope, I'm dead serious about maya. This genuinely is how you do it. You make your mesh, you generate your light maps (which takes hours, because you're doing it offline with really heavy duty light models like GI and this is how long it takes!), you bake them into your textures and you load them pre-lit into QC. This is how people do it :)
You could also do AO, soft shadows and the like realtime in QC. But the quality will be nothing like as good. This is why people pre-calculate the lighting, then combine it with AO for animated parts of the scene.
Expecting QC to have an integrated light + shadow setup to do it all for you is a bit unrealistic though. A lighting method that works great in every scenario is going to be either super slow or have some other issue. The reality is that you have to pick and choose your lighting methods depending on the scene.. in some cases SSAO looks perfect, in others you need deferred rendering, in others you have to pre-calc the lighting.
Like cwright says, you have a choice of sucky-but-good-in-some-cases lighting (which we have already), or you hit the GLSL editor and start writing :)
And for complex, static geometry, you bake your lighting with beast, maya, softimage, etc.
Quote: Boy, maybe if people were like "yeah, give me some good lighting tools" we might actually get them! Sometimes it's sort of sad to suggest QC doing stuff that actually expands it's potential uses into the realm of non-trivial, and see it get limited traction. I feel like the QC community can be sort of lifeless in envisioning where the tool could go in making it less niche (not referring to you psonice, or anyone on the board, more the people that DON'T chime in too much, but use QC for professional activities and are lurkers).
QC is Apple's only genuine 3D graphics engine, and it's only real tech that allows for the extensibility and ease of use that is good for designers as well as programmers (not saying it's there yet- coding in QC and some other aspects need to be amply fleshed out). As such, I think it needs a lighting model that doesn't_suck. The QC lighting model is problematic and should be slowly deprecated, while be shored up by a more fully featured shader engine.
A QC that doesn't eventually go into areas like this is going to be a QC that stays stuck in SL while we've all moved onto other stuff.
You have to consider here that apple is a business, and they're only going to implement stuff that is going to improve their software or enable devs to build better stuff. Looking at it that way, I'm not entirely sure what the value of the 3d tools and lighting is.. what's it going to get used for? How's it going to benefit apple or bring in some money? Given how apple use QC, the 3d stuff is probably intended mainly for things like titles in imovie.
Personally I think work on QC would be better spent making it more useful in general apps, doing things like cool UIs that go beyond what core animation will handle and integrate video and stuff smoothly. (And to prove it, I'm going to re-work the UI for an app I'm working on purely in QC :)
We don't have GLSL support that would allow us to do things needed to get this kind of lighting. I'm not suggesting automagical.
If you're reworking a UI in QC, pay attention to window focus and the UI "doing the right thing" when you touch a control without bringing the window into focus first.
Again, I know about baking lighting. Also, no one hits the GLSL shader and starts writing in QC, because this kind of stuff isn't supported.
Points taken about lighting/ "what is in it for apple", but more than anything I'm talking about more fully supporting current GLSL possibilities. The same can be said about that, I guess, though I think there comes a point when things like lighting (yeah, I'm entangling this with GLSL improvements), and possible poly count start to look embarrassing compared to other graphics engines. For someone to want to use something it has to have a modicum of support for things that are considered "modern".
What I'm always SHOCKED by is the pervasive knowledge about QC by people in projects I've worked on, whether they work in offline animation, designers, techs, or artists.
"When you look at demos like what psonice posts, it's imperative to understand that that's the end result of tons of effort in making great shaders, and QC cannot possibly do that for you."
Do I have a dumbass sign posted on my back today? ;-) I know you know that I would conceive that this has to be done with GLSL from talks we've had, so I'm hoping that was a kind of "for general clarification" thing.
To your last quote; not shaders, non-niche areas. Now, psonice makes the salient point of "What's in it for Apple?" (paraphrasing).
Nintendo64 (1997), could draw 100,000 polys per second and that was considered low.
We're not talking about a gaming engine, I know, but I would argue that gaming engines set a certain bar of achievement for what can be achieved in real time graphics, and that in some cases, they have probably become better developed for pure quality of graphics rendering. At some point, the Mac graphics engine and framework offerings start looking very dated (some would argue this happened years ago), when taking into account what someone would consider a state of the art graphics experience.
It wouldn't be totally unreasonable to have support for GLSL at higher level, etc., and also have some more robust built in support akin to stuff like the Unity lighting engine. It doesn't have to totally be one way or the other - it's not right now. Both sides of the coin could use a spit shine.
Nothing I'll really disagree with there, but again... what is QC supposed to be for? If it's not a game engine (or doing game-engine like work) things like poly counts and lighting models don't matter much. Efficient filter chains for video effects matter, and moving a few dozen billboards with a few effects as part of a UI matters.
That said, the ability to light a static mesh on load with AO would be very handy actually. An extruded font and a few cubes plus AO lighting would make for great titles in imovie ;) (Yeah, we could pre-light this stuff in a 3d tool, but in this case we'd want to maybe edit the text and a second or two of precalc wouldn't matter much)
psonice wrote: Personally I think work on QC would be better spent making it more useful in general apps, doing things like cool UIs that go beyond what core animation will handle and integrate video and stuff smoothly.
There's much merit in that argument, it's just that for non-Cocoa-programmer's QC opens up so much potential ground for originality in realtime/motion graphics and programming, it's tempting to see how far it could go as an stand-alone IDE geared to the visually inclined coder and visually oriented apps.
psonice wrote:
(And to prove it, I'm going to re-work the UI for an app I'm working on purely in QC :)
I'm sure that's what QC's good for but I really look forward to the (hypothetical) day that a Quartz 2D type framework (as distinct from core-animation) exists for use inside QC. Quartz Extreme & NIB style Binding to Dialogues/Info Panels/Menus that sort of thing too would round QC out for me.
im with your george i think the stock lighting in qc is pretty bleak. i suppose the only things that are comparable to qc in the realtime context are game engine type of sdk's or what not. which are usually proprietarily designed for a particular device or console, making most lighting type of engines like "Beast" lets say not really affordable when compared to a free quartz composer.
they don't even have a price on the web-site which leads me to believe it must be pricey because it integrates with unreal 3. so your probably talking a 7 figure digit to get this thing running the way it supposed to be running.
if mr wood is correct in saying that this thing is baking textures on the fly then using an entropy or maxwell renderer for maya or cinema 4d or something to pre bake your textures seems a whole lot cheaper but even then autodesk software isn't that cheap either.
personally i think unity can produce some nice lighting when you combine the stock lights with some pre baked textures and shaders. even still you need to fake some shadows with sprite based projection maps etc...
for free qc is really powerful even in the offline context. i have not done a 4k render in a while but qc is fully capable of producing 2k and 4k quality renders, i think even some people are doing this resolution in realtime with qc on triple heads and stuff.
I don't think it's baking textures 'on the fly' - it probably takes many hours to light a scene like this. But at the end, I'm sure it does just bake the lighting - perhaps it does more than that, but that'll be the essence of it.
And doesn't blender do this for free? Probably not to the same standard, and probably not quite so well as beast for realtime use, but good enough for many people.
But yeah, QC's lighting isn't exactly top notch. 3d support in general isn't. But QC isn't a game engine, it's not really a 3d engine, and I'd be surprised if apple seriously wants it to become either :)
psonice wrote: But yeah, QC's lighting isn't exactly top notch. 3d support in general isn't. But QC isn't a game engine, it's not really a 3d engine, and I'd be surprised if apple seriously wants it to become either :)
I pretty much agreed with this when I read it the other day. Yesterday I was looking at some '3D' clipart being sold for Keynote. Despite the iPresentees hints that it is real 3D objects you can "rotate", it is just 2D image files rendered in a 3D application.
It occurred to me that some day in the future when the web is full of free / low cost (good quality) 3D assets, having an Mac OS native way of loading and displaying 3D objects in apps, the same way the default text tools are provided for all apps that don't want to do font & type control themselves could be a good thing.
QC could be a basis for such a framework/toolset for programmers. Developers could write plugins to add lighting features or whatever else to build on the basic tools. The same way say the Adobe Kuler colour picker can be added as a tab in the standard OSX colour picker floating palette and it appears in all apps that use the colour picker palette. Not saying I've thought this through a whole lot but it's potential 'usefulness' for QC beyond what QC already does.
It's just a tool to bake lightmaps. Most 3d packages do this already. Make a city in your favourite 3d package, use your lighting model of choice (beast uses global illumination), bake the lighting into your textures, load the textured model into qc or whatever and you'll get similar results.
Next job, implement this in realtime ;) [seriously, that's how everyone does it - the 'hard to do' lighting is pre-rendered for the static scenery, then some low quality 'hacky' lighting (say some basic soft shadowing plus SSAO) is used on everything that moves]
Psonice, give me a little credit ;-) It's not that this does anything that can't be done in apps already (and that I haven't been doing a ridiculous amount for the last bit), it's more that I thought it was cool that it was game engine independent.
I think it would be really helpful and efficient if QC actually had provisions for this sort of thing (crazy huh!?). I'm always kind of fascinated by hacktastic stuff like that - like how Z-Brush goes ahead and "locks in" stuff you aren't working on, so that your computer doesn't go into a spiraling death grip.
Of course it's game engine independent, so is maya and softimage ;) It's just generating a lightmap, and baking it into the textures (not to put it down, it does a fine job judging by the screenshots). If you can load a textured mesh into QC, and export in a compatible format from beast, it works with QC too.
I'm guessing beast is pretty much the same as many other lighting systems, but more game focused (so it'll generate texture data meant for realtime, and formats used by the various game engines).
Oh, and you can do something like this in QC yourself. High end lighting is possible with a shader or two, but not in realtime (at least not at this quality). But you can do this once, and save the results to a texture (i.e. you bake the lighting when the comp starts). Then you can use your nice ambient occlusion or whatever (real AO, not the SSAO crap we normally do ;) with very little speed hit.
I used smash's (of fairlight fame) 64kb intro tool once for a demo we did some years back. That worked this way - you make a mesh, then hit the 'generate lightmap' button, it goes and does some fancy AO for 0.5 seconds and you have cool lighting.
Hmm, good point about "baking your own maps" using QC, except that if you write it/read it to file, QC isn't going to handle it well (you may have to do clever things to cover possible stutter steps with largish images, and that's lame), and if you use something like a sample and hold or a RII to hold the image, your going to start bogging stuff down.
I know you're being a little tongue in cheek with the comment about maya... yeah, you can use an app to render lighting to your textures, and you can do workarounds in QC (albeit cludgy). A lighting engine that was well integrated could allow us to "save to texture" without stalling the viewer when the image loads (this could also be implemented with K3D and the stock OpenCL meshkit and SHOULD BE). We just "wouldn't see" the image (or resource) until it loads, and we wouldn't have the friggin' beachball. This is something I was talking about with cwright when he went off to Valhalla ;-)
Boy, maybe if people were like "yeah, give me some good lighting tools" we might actually get them! Sometimes it's sort of sad to suggest QC doing stuff that actually expands it's potential uses into the realm of non-trivial, and see it get limited traction. I feel like the QC community can be sort of lifeless in envisioning where the tool could go in making it less niche (not referring to you psonice, or anyone on the board, more the people that DON'T chime in too much, but use QC for professional activities and are lurkers).
QC is Apple's only genuine 3D graphics engine, and it's only real tech that allows for the extensibility and ease of use that is good for designers as well as programmers (not saying it's there yet- coding in QC and some other aspects need to be amply fleshed out). As such, I think it needs a lighting model that doesn't_suck. The QC lighting model is problematic and should be slowly deprecated, while be shored up by a more fully featured shader engine.
A QC that doesn't eventually go into areas like this is going to be a QC that stays stuck in SL while we've all moved onto other stuff.
And strangely enough, there are a ton of them. The crash counts we get internally are insane compared to what I collected at Kineme. And yet there's no discussion outside of about half a dozen users. :/
Those are mutually exclusive, to some extent. non-sucky lighting models are shaders, so a more fully featured shader model = you are in charge of making it not suck. There's some overlap (built-in defaults, etc) of course, but there's only so much handholding to be provided. When you look at demos like what psonice posts, it's imperative to understand that that's the end result of tons of effort in making great shaders, and QC cannot possibly do that for you.
goes into shaders, or non-niche areas? (not exclusive or, but do understand that time isn't unlimited)
Does that include users of OS X apps that crash which are using the QC framework in some way or is it exclusive to users using the QC application itself (ie. Editor)?
No, the idea is to generate these maps [i]before[/i] the composition starts running. For a big scene, you're looking at several seconds to several hours (depending on the method you use) to generate the light maps. Loading the scene and showing it unlit for half an hour while the maps are calculated would suck bigtime ;)
Nope, I'm dead serious about maya. This genuinely is how you do it. You make your mesh, you generate your light maps (which takes hours, because you're doing it offline with really heavy duty light models like GI and this is how long it takes!), you bake them into your textures and you load them pre-lit into QC. This is how people do it :)
You could also do AO, soft shadows and the like realtime in QC. But the quality will be nothing like as good. This is why people pre-calculate the lighting, then combine it with AO for animated parts of the scene.
Expecting QC to have an integrated light + shadow setup to do it all for you is a bit unrealistic though. A lighting method that works great in every scenario is going to be either super slow or have some other issue. The reality is that you have to pick and choose your lighting methods depending on the scene.. in some cases SSAO looks perfect, in others you need deferred rendering, in others you have to pre-calc the lighting.
Like cwright says, you have a choice of sucky-but-good-in-some-cases lighting (which we have already), or you hit the GLSL editor and start writing :)
And for complex, static geometry, you bake your lighting with beast, maya, softimage, etc.
You have to consider here that apple is a business, and they're only going to implement stuff that is going to improve their software or enable devs to build better stuff. Looking at it that way, I'm not entirely sure what the value of the 3d tools and lighting is.. what's it going to get used for? How's it going to benefit apple or bring in some money? Given how apple use QC, the 3d stuff is probably intended mainly for things like titles in imovie.
Personally I think work on QC would be better spent making it more useful in general apps, doing things like cool UIs that go beyond what core animation will handle and integrate video and stuff smoothly. (And to prove it, I'm going to re-work the UI for an app I'm working on purely in QC :)
We don't have GLSL support that would allow us to do things needed to get this kind of lighting. I'm not suggesting automagical.
If you're reworking a UI in QC, pay attention to window focus and the UI "doing the right thing" when you touch a control without bringing the window into focus first.
Again, I know about baking lighting. Also, no one hits the GLSL shader and starts writing in QC, because this kind of stuff isn't supported.
Points taken about lighting/ "what is in it for apple", but more than anything I'm talking about more fully supporting current GLSL possibilities. The same can be said about that, I guess, though I think there comes a point when things like lighting (yeah, I'm entangling this with GLSL improvements), and possible poly count start to look embarrassing compared to other graphics engines. For someone to want to use something it has to have a modicum of support for things that are considered "modern".
"And strangely enough, there are a ton of them."
What I'm always SHOCKED by is the pervasive knowledge about QC by people in projects I've worked on, whether they work in offline animation, designers, techs, or artists.
"When you look at demos like what psonice posts, it's imperative to understand that that's the end result of tons of effort in making great shaders, and QC cannot possibly do that for you."
Do I have a dumbass sign posted on my back today? ;-) I know you know that I would conceive that this has to be done with GLSL from talks we've had, so I'm hoping that was a kind of "for general clarification" thing.
To your last quote; not shaders, non-niche areas. Now, psonice makes the salient point of "What's in it for Apple?" (paraphrasing).
Nintendo64 (1997), could draw 100,000 polys per second and that was considered low.
We're not talking about a gaming engine, I know, but I would argue that gaming engines set a certain bar of achievement for what can be achieved in real time graphics, and that in some cases, they have probably become better developed for pure quality of graphics rendering. At some point, the Mac graphics engine and framework offerings start looking very dated (some would argue this happened years ago), when taking into account what someone would consider a state of the art graphics experience.
It wouldn't be totally unreasonable to have support for GLSL at higher level, etc., and also have some more robust built in support akin to stuff like the Unity lighting engine. It doesn't have to totally be one way or the other - it's not right now. Both sides of the coin could use a spit shine.
Nothing I'll really disagree with there, but again... what is QC supposed to be for? If it's not a game engine (or doing game-engine like work) things like poly counts and lighting models don't matter much. Efficient filter chains for video effects matter, and moving a few dozen billboards with a few effects as part of a UI matters.
That said, the ability to light a static mesh on load with AO would be very handy actually. An extruded font and a few cubes plus AO lighting would make for great titles in imovie ;) (Yeah, we could pre-light this stuff in a 3d tool, but in this case we'd want to maybe edit the text and a second or two of precalc wouldn't matter much)
im with your george i think the stock lighting in qc is pretty bleak. i suppose the only things that are comparable to qc in the realtime context are game engine type of sdk's or what not. which are usually proprietarily designed for a particular device or console, making most lighting type of engines like "Beast" lets say not really affordable when compared to a free quartz composer.
they don't even have a price on the web-site which leads me to believe it must be pricey because it integrates with unreal 3. so your probably talking a 7 figure digit to get this thing running the way it supposed to be running.
if mr wood is correct in saying that this thing is baking textures on the fly then using an entropy or maxwell renderer for maya or cinema 4d or something to pre bake your textures seems a whole lot cheaper but even then autodesk software isn't that cheap either.
personally i think unity can produce some nice lighting when you combine the stock lights with some pre baked textures and shaders. even still you need to fake some shadows with sprite based projection maps etc...
for free qc is really powerful even in the offline context. i have not done a 4k render in a while but qc is fully capable of producing 2k and 4k quality renders, i think even some people are doing this resolution in realtime with qc on triple heads and stuff.
I don't think it's baking textures 'on the fly' - it probably takes many hours to light a scene like this. But at the end, I'm sure it does just bake the lighting - perhaps it does more than that, but that'll be the essence of it.
And doesn't blender do this for free? Probably not to the same standard, and probably not quite so well as beast for realtime use, but good enough for many people.
But yeah, QC's lighting isn't exactly top notch. 3d support in general isn't. But QC isn't a game engine, it's not really a 3d engine, and I'd be surprised if apple seriously wants it to become either :)
I pretty much agreed with this when I read it the other day. Yesterday I was looking at some '3D' clipart being sold for Keynote. Despite the iPresentees hints that it is real 3D objects you can "rotate", it is just 2D image files rendered in a 3D application.
It occurred to me that some day in the future when the web is full of free / low cost (good quality) 3D assets, having an Mac OS native way of loading and displaying 3D objects in apps, the same way the default text tools are provided for all apps that don't want to do font & type control themselves could be a good thing.
QC could be a basis for such a framework/toolset for programmers. Developers could write plugins to add lighting features or whatever else to build on the basic tools. The same way say the Adobe Kuler colour picker can be added as a tab in the standard OSX colour picker floating palette and it appears in all apps that use the colour picker palette. Not saying I've thought this through a whole lot but it's potential 'usefulness' for QC beyond what QC already does.