A camera is possible with the 3d Transformation patch (just inverse-transform everything)
FOV is available as a built-in patch (private), and as part of GLTools.
Lenses and DoF are impossible to simulate real-time (it's possible to fake it with some clever tricks, but it's very specific for each composition, and there's not real way to do it everywhere automatically).
Motion Blur (not listed, but another property of cameras) is also not trivially possible, but possible with clever tricks.
path information can be done with the timelines patch or with javascript, attached to the 3d Transformation patch above.
While inverse transformation is possible -for math guys- , it is still a bit un-natural i think - do you have any such macro ?-
With the unleashed power of the KnM 3D plugin, a real camera patch would be an awesome bonus (100points for pedestrians).
Especially with the possibility of loading some external camera file with keyframe animation (maybe in CSV format, as discussed somewhere with smokris , as i remember - 3DSmax can export such kind of data).
Timelines are a real pain to use (imo), a greatly under-developped function to be efficient.(just check MaxMsp for curves, or vvvv or After Effects or DigitalFusion ...)
A trick for DoF: render the scene as a Zbuffer (with the FOG patch) then use the image as a mask for a blur filter ... (cheapo DoF)
A trick for MoBlur: slightly feedback the comp ...
No, seriously, a camera patch would be an OVERKILL bonus.
Let's keep dreamin'
GLTools 0.5 (due in any minute now ;) will have a private GLLookAt patch, which can help simulate a camera -- not sure how well it'll work, but it'll start some discussion for sure :)
Dof ..... ..... (I've seen the fog trick used with good success... reading the zbuffer would give slightly better results, but would take much longer and require a lot of ugly hacks that probably won't work reliably).
Compo Feedback for MoBlur isn't quite right -- you want in-between frames fed back, not older frames... though it's a start I guess :)
GLT 0.5 also has a new viewport and matrix loading patch, so if a math nerd would kindly step up and make a killer Camera macro patch from those, they'd wind up famous in the blogosphere! :) hint hint
Funnily enough, I've just been messing around with Depth of Field effects in QC.
My very simple method, based on the vvvv 'TexCtrlBlur.fx' by kalle, seems to work quite well. The only problem is, I'm embedding the depth value of the rendered cubes (in this case) in the alpha channel, which means I can't use the alpha to comp the cubes on top of anything else later on. I'm thinking of embedding the depth in one of the other channels, but then I'll lose the ability to represent colours properly. If anyone can think of a clever hack to get around this, I'm be interested to hear it.
Here's an example of a standard first person controller using the lookat patch. "s" and "w" to movie forward/backward, mouse to change look point. Now just need faster reporting from the keyboard for smooth motion.
The example file ran for a couple of seconds before losing most of the backdrop, then I was left with the cylinder object that moved with the mouse, loss of what looked like a golf range or something - merely blinked the background before it disappeared, so just hazarding a guess :-)
First and foremost, your javascript is only looking at 1 character per frame (charAt(0)), so even if the freeboard patch sent multiple keystrokes, you'd never actually use it.
second, QC only delivers 1 event per frame. They apparently queue up, but keypress repeats aren't queued (I'd need to do some experiments on this to see for sure how it works -- events are somewhat complicated). So the freeboard patch can't deal with more than 1 event per frame (because only 1 is delivered) -- if the key's released, it doesn't know when it actually happened to know how many repeats to include.
What you'll want to do is something akin to "pointer ballistics" with mice -- when the key is down, instead of linearly stepping, you'll want to have some sort of curve that increases over time (to some defined maximum)
A camera is possible with the 3d Transformation patch (just inverse-transform everything)
FOV is available as a built-in patch (private), and as part of GLTools.
Lenses and DoF are impossible to simulate real-time (it's possible to fake it with some clever tricks, but it's very specific for each composition, and there's not real way to do it everywhere automatically).
Motion Blur (not listed, but another property of cameras) is also not trivially possible, but possible with clever tricks.
path information can be done with the timelines patch or with javascript, attached to the 3d Transformation patch above.
While inverse transformation is possible -for math guys- , it is still a bit un-natural i think - do you have any such macro ?- With the unleashed power of the KnM 3D plugin, a real camera patch would be an awesome bonus (100points for pedestrians). Especially with the possibility of loading some external camera file with keyframe animation (maybe in CSV format, as discussed somewhere with smokris , as i remember - 3DSmax can export such kind of data). Timelines are a real pain to use (imo), a greatly under-developped function to be efficient.(just check MaxMsp for curves, or vvvv or After Effects or DigitalFusion ...)
A trick for DoF: render the scene as a Zbuffer (with the FOG patch) then use the image as a mask for a blur filter ... (cheapo DoF) A trick for MoBlur: slightly feedback the comp ...
No, seriously, a camera patch would be an OVERKILL bonus. Let's keep dreamin'
GLTools 0.5 (due in any minute now ;) will have a private GLLookAt patch, which can help simulate a camera -- not sure how well it'll work, but it'll start some discussion for sure :)
Dof ..... ..... (I've seen the fog trick used with good success... reading the zbuffer would give slightly better results, but would take much longer and require a lot of ugly hacks that probably won't work reliably).
Compo Feedback for MoBlur isn't quite right -- you want in-between frames fed back, not older frames... though it's a start I guess :)
GLT 0.5 also has a new viewport and matrix loading patch, so if a math nerd would kindly step up and make a killer Camera macro patch from those, they'd wind up famous in the blogosphere! :) hint hint
Funnily enough, I've just been messing around with Depth of Field effects in QC. My very simple method, based on the vvvv 'TexCtrlBlur.fx' by kalle, seems to work quite well. The only problem is, I'm embedding the depth value of the rendered cubes (in this case) in the alpha channel, which means I can't use the alpha to comp the cubes on top of anything else later on. I'm thinking of embedding the depth in one of the other channels, but then I'll lose the ability to represent colours properly. If anyone can think of a clever hack to get around this, I'm be interested to hear it.
a|x
fantastic work..
That's exactly what I did franz. Except I didn't use the Fog patch. My method needs some tweaks, but it's looking promising so far.
vvvvery promising, indeed. keep us posted !
Here's an example of a standard first person controller using the lookat patch. "s" and "w" to movie forward/backward, mouse to change look point. Now just need faster reporting from the keyboard for smooth motion.
The example file ran for a couple of seconds before losing most of the backdrop, then I was left with the cylinder object that moved with the mouse, loss of what looked like a golf range or something - merely blinked the background before it disappeared, so just hazarding a guess :-)
The keyboard commands, w and s also worked
This is a two-sided problem.
First and foremost, your javascript is only looking at 1 character per frame (charAt(0)), so even if the freeboard patch sent multiple keystrokes, you'd never actually use it.
second, QC only delivers 1 event per frame. They apparently queue up, but keypress repeats aren't queued (I'd need to do some experiments on this to see for sure how it works -- events are somewhat complicated). So the freeboard patch can't deal with more than 1 event per frame (because only 1 is delivered) -- if the key's released, it doesn't know when it actually happened to know how many repeats to include.
What you'll want to do is something akin to "pointer ballistics" with mice -- when the key is down, instead of linearly stepping, you'll want to have some sort of curve that increases over time (to some defined maximum)