This looks very cool! What I can see of it. I'm getting 3-5 frames per second. I can barely get the macros open to inspect them. I don't see any OpenCL offhand in there, but something is sure enough bringing my iMac to it's knees. Any ideas?
Try backing off on the queue/iteration count. Also, one can place an image resize or lanczos scale transform before the queue input to downsize the pixel count of the image... that will make the queue not work as hard.
Awesome, and thanks for giving credit on the qtz. Yeah, exactly, you can use this same method to make some cool volumetric/extrusion looks. I'm doing a project that uses that premise right now...
If you use something like bulge or twirl at the front end of the image, you'll see that chase down the stack... another cool thing to try perhaps.
yes, that's another thing to implement. worse from now I want to focus on having a good key color and other methods of blending, for the video and get a finer result.
thanks for your patches!
Toneburst did something like this a while back, but using a raycasting shader to render the volume. I also did something, more like what you did there (see this youtube clip: http://www.youtube.com/watch?v=eD-PD1EOxlE ).
I found the main thing was to get good transparency to give the volume a clear shape. If you can use masking that's probably ideal (eg. say a bluescreened video). If not, try using edge detection to give you an idea of where the edges are, then use those areas to mask the video (what I did was edge detection -> blur, then use that ask an alpha mask).
The other thing is shading - shadows and lighting will make it look MUCH cooler. Ideally you want AO type soft illumination, with self-shadowing. Getting that to work with slices is rather hard though ;) I managed to get passable soft shadows, but no self shadowing (for that you really need to render it as a volume instead of slices).
My version was NOT realtime btw - I'm using 200+ layers, it was running <1fps.
Navis (of ASD fame in the demoscene) has been doing some volume rendering for medical data - his work had the same "lack of depth" feeling that I've seen in all of our videos, but a quick bit of persuasion on pouet.net and he came back with a new version of his renderer with AO. The results are a lot better:
So, it is possible, and it does look good. You just need to be extremely good at programming to make it work ;) (Notice too how he's getting realtime results at WAY higher quality than we are!)
Well, fwiw, on this one, I'm way more interested in having a workable realtime technique that works to make volumetric looking stuff with whatever you feed it. I agree about the high quality stuff looking really nice though, don't get me wrong. On my computer, the qtz I posted runs at 30fps with a 800x600 viewer... which makes it usable for a live scenario (even if it has cut out niceties).
When doing this stuff, it would be so cool if you could just crank up a z scale on a sprite and have it turn into a cube-like object that's image would carry over to the sides in the correct places. I've thought that numerous times while making iterator setups like this.
The video's of navis' volumetric stuff above is realtime - it's a fully interactive application. This stuff is possible, it just needs a plugin I suspect to be workable in QC.
As for feeding it live data as a dataset - there's a bunch of complications here I think. There's a ton of stuff you can do to the data to speed up rendering with a fixed data set. Even so, it's possible to do something between what we've done and what navis has done, with decent quality and speed.
What you suggest with the cube should be possible with a cube + GLSL shader btw - it'll just need a little maths to figure out what part of the texture you're looking at (assuming you want transparent parts of the image to form 'holes' in the cube).
That's really cool stuff. As you say, there's loads of optimisation you can do on static volume datasets (like empty-space-skipping, and pre-calculating normals for lighting) that can't be done on constantly-changing volumes though. I suspect ambiVU uses a lot of these techniques.
It's also possible to generate actual 3D geometry from volumetric data using Marching Cubes or Marching Polygon techniques. I attempted this in OpenCL, but gave up because it was too complicated. It could be done in a CPU-executing custom patch though. That's where being able to use the new faster Mesh Array port-type would come in handy (see my other post).
What would be interesting to me is to be able to do the rotations and extrapolate the real 3D geometry (as opposed to the iterator pseudo volumetric "chase" stuff), but with the sheets splayed out side by side, instead of being stacked. That's something that has proven a big p.i.t.a any time I've tried it.
Check this out... tweak the gamma and blend modes to control your brightness.
This looks very cool! What I can see of it. I'm getting 3-5 frames per second. I can barely get the macros open to inspect them. I don't see any OpenCL offhand in there, but something is sure enough bringing my iMac to it's knees. Any ideas?
Try backing off on the queue/iteration count. Also, one can place an image resize or lanczos scale transform before the queue input to downsize the pixel count of the image... that will make the queue not work as hard.
Decreasing the queue count did it. Thanks! Man, the render in image option is very attractive! Cool!
Hi, this example serves to return me an idea I had in mind for a long time. this is the result.
Time Warp estrusion 3d ( qtz patch) from gnomalab on Vimeo.
Awesome, and thanks for giving credit on the qtz. Yeah, exactly, you can use this same method to make some cool volumetric/extrusion looks. I'm doing a project that uses that premise right now...
If you use something like bulge or twirl at the front end of the image, you'll see that chase down the stack... another cool thing to try perhaps.
yes, that's another thing to implement. worse from now I want to focus on having a good key color and other methods of blending, for the video and get a finer result. thanks for your patches!
Toneburst did something like this a while back, but using a raycasting shader to render the volume. I also did something, more like what you did there (see this youtube clip: http://www.youtube.com/watch?v=eD-PD1EOxlE ).
I found the main thing was to get good transparency to give the volume a clear shape. If you can use masking that's probably ideal (eg. say a bluescreened video). If not, try using edge detection to give you an idea of where the edges are, then use those areas to mask the video (what I did was edge detection -> blur, then use that ask an alpha mask).
The other thing is shading - shadows and lighting will make it look MUCH cooler. Ideally you want AO type soft illumination, with self-shadowing. Getting that to work with slices is rather hard though ;) I managed to get passable soft shadows, but no self shadowing (for that you really need to render it as a volume instead of slices).
My version was NOT realtime btw - I'm using 200+ layers, it was running <1fps.
There are some clips on a similar theme on my Vimeo page: http://vimeo.com/user340793/videos
I did try adding some kind of lighting a while back, but it didn't really work very well, for a variety of reasons, I think.
a|x
Navis (of ASD fame in the demoscene) has been doing some volume rendering for medical data - his work had the same "lack of depth" feeling that I've seen in all of our videos, but a quick bit of persuasion on pouet.net and he came back with a new version of his renderer with AO. The results are a lot better:
http://www.youtube.com/user/ambivu1#p/a/u/1/7KdFtd1JmYU
So, it is possible, and it does look good. You just need to be extremely good at programming to make it work ;) (Notice too how he's getting realtime results at WAY higher quality than we are!)
Well, fwiw, on this one, I'm way more interested in having a workable realtime technique that works to make volumetric looking stuff with whatever you feed it. I agree about the high quality stuff looking really nice though, don't get me wrong. On my computer, the qtz I posted runs at 30fps with a 800x600 viewer... which makes it usable for a live scenario (even if it has cut out niceties).
When doing this stuff, it would be so cool if you could just crank up a z scale on a sprite and have it turn into a cube-like object that's image would carry over to the sides in the correct places. I've thought that numerous times while making iterator setups like this.
The video's of navis' volumetric stuff above is realtime - it's a fully interactive application. This stuff is possible, it just needs a plugin I suspect to be workable in QC.
As for feeding it live data as a dataset - there's a bunch of complications here I think. There's a ton of stuff you can do to the data to speed up rendering with a fixed data set. Even so, it's possible to do something between what we've done and what navis has done, with decent quality and speed.
What you suggest with the cube should be possible with a cube + GLSL shader btw - it'll just need a little maths to figure out what part of the texture you're looking at (assuming you want transparent parts of the image to form 'holes' in the cube).
That's really cool stuff. As you say, there's loads of optimisation you can do on static volume datasets (like empty-space-skipping, and pre-calculating normals for lighting) that can't be done on constantly-changing volumes though. I suspect ambiVU uses a lot of these techniques.
It's also possible to generate actual 3D geometry from volumetric data using Marching Cubes or Marching Polygon techniques. I attempted this in OpenCL, but gave up because it was too complicated. It could be done in a CPU-executing custom patch though. That's where being able to use the new faster Mesh Array port-type would come in handy (see my other post).
a|x
This is quite cool
http://www.youtube.com/user/ambivu1#p/u/12/WGRu9QEPKhQ
;)
a|x
What would be interesting to me is to be able to do the rotations and extrapolate the real 3D geometry (as opposed to the iterator pseudo volumetric "chase" stuff), but with the sheets splayed out side by side, instead of being stacked. That's something that has proven a big p.i.t.a any time I've tried it.
I'm halfway through an email suggesting a way to do that ;)
Received... the first thing I tried actually ;) ... and it's worked, with caveats.
This
thread
is
getting
too
thin
a|x
nah
not
yet
.
in the g body upload qtz, this has probably been addressed... in this comp, is there a way to delay the output of the next queue index?
EDIT: sorry, i just found this: http://kineme.net/Discussion/General/RenderingLiveVideo3DVolume