This is a composition that takes an image and warps it using GLSL, a Sphere renderer, and Kineme3D HeightField. It also incorporates Kineme GL Tools Polygon Mode.
Oh yeah... mucho respect to tons of "inverse" panorama art on the web, Psonice's video balls experiments, the Rutt Etra, and Apple GLSL example code, without which I would likely not have gone down this route. Also even more mucho respect to cwright and smokris for the great plugins.
I bet it would look rad with most of the stuff from the Nature folder (haven't noticed if those pics are still in SL). I really enjoy using it with outdoor footage (do a keyword search at Archive.org), or scenes of buildings and such, so that it looks like a mini-planet.
The pic that's on the "front page" is actually of me, even though it looks kind of like there's some grass and land or something.
I guess it's also worth noting that I used a vert/frag GLSL that's in the MeshKit framework for the twirling GLSL effect.
The Art folder is a nice surprise, didn't think Nighthawks looked quite like that, but I've probably been influenced by glossy print copies being my only source of reference to date [light blue reflection lines, colour palette, etc] .
thats pretty bizarre mad controls, i was messing with one of the controls an all of sudden my head jumped out at me, actually scared me for a second. wicked i will have to try this with some pictures. i like interpolating the depth just a tiny bit with some organic textures kind of looks like a breathing planet to me.
Oooh, I hadn't even noticed the new Desktop pics yet! I have to say... there are a number of choices that really resonate with me, on oddly coincidental and personal levels. I really like those.
I know what you're saying about Nighthawks... It looks more mellow than the cheap posters I've seen :)
It does have a wide throw to the controls, and you can make things that look like tunnels as well (at least I can, given my average lighting conditions).
The gl point stuff can be kind of wild, given the right imagery.
I keep meaning to come back to Vertex Displacement Mapping, but every time I do, I end up getting frustrated trying to generate normals for lighting, and give up. I should just give up on that one, I guess.
Having said that, maybe I could do something like that using OpenCL....
Must investigate.
I always say this, but the plus of doing it with K3D is that you can subsequently put GLSL on it.
I was thinking the same thing about using OpenCL for something like this {though it would feel a bit like reinventing the wheel for the sake of it.... I already enjoy the way the Kineme3D heightfield works. It would also necessitate a different kind of setup, and I certainly couldn't pop the whole result in say, a Glossy Wet GLSL :) ....}.
Kineme3D does the displacement stuff on the CPU though, unless I'm very much mistaken, so doing it on the GPU, via GLSL and/or OpenCL would potentially be a lot faster.
you are correct -- k3d is cpu-only (except for the final rendering stage, where it's gpu-backed). I've been considering extending the pipeline to be GPU accelerated since before 10.6/CL was even announced, but never got around to it (it's a lot of work). It might be in the cards for a future update, but it's difficult to know... with 10.6's mesh stuff k3d's fate is in limbo...
I guess the only way to know for sure is to do it and see :)
I don't know that I'm sold on the OpenCL patch stuff and what's going on in the under-pinnings with it's QC implementation.
Something I've kind of had in the back of my head, is wondering if the manipulation of image/texture is also being GPU accelerated right now. I get halty/unsmooth results from simply rotating small, low vertex count dae's with interpolation. I kind of view the SL patches like alpha...maybe beta plugins, frankly. The only reasonable thing I can think of that would cause that kind of performance is the manipulation of textures using the deformers, or even just the rendering of them without deformers sometimes. If it is being GPU accelerated... then I guess running with two GPU's doesn't really give you that much juice :/
I've done some of the sample Xcode, where I can see the effect of GPU acceleration vs. "not GPU accelerated"... and then I open up QC, and it just gives the unsmooth "not GPU accelerated" look (not saying it ISN'T though, just that performance isn't smooth).
For example, setting up one of the Google 3D Warehouse dae's (even really small simple ones), and setting up a "walk through" qtz., the performance just doesn't seem good enough (this is without deformers). All I know, is that if I'm getting this performance on a 9400/9600 with a 3.06GHz, then I may as well not consider using that technique, because it's only going to look worse for others.
I guess what I'm saying is that I think certain common patch mixes/implementations may basically "cap" performance gains that we could eventually end up seeing down the road. Granted, the reasons "why" are totally speculative on my part. I just know what I see in my Viewer window.
BTW....toneburst, I soooo thought of you, and also tobyspark, when I looked at the mouse ribbon.qtz
gtoledo3 wrote: BTW....toneburst, I soooo thought of you, and also tobyspark, when I looked at the mouse ribbon.qtz
:)
It's exactly the same technique. All credit to toby for that one. I basically translated his custom plugin into JavaScript, and hacked-in some dodgy texture support. I'll have to have a look at the Apple example, and see if there's anything different about the way they went about it.
Oh yeah... mucho respect to tons of "inverse" panorama art on the web, Psonice's video balls experiments, the Rutt Etra, and Apple GLSL example code, without which I would likely not have gone down this route. Also even more mucho respect to cwright and smokris for the great plugins.
Sweet composition! Thanks!
Works really nicely with the Camouflage Desktop Picture.
I bet it would look rad with most of the stuff from the Nature folder (haven't noticed if those pics are still in SL). I really enjoy using it with outdoor footage (do a keyword search at Archive.org), or scenes of buildings and such, so that it looks like a mini-planet.
The pic that's on the "front page" is actually of me, even though it looks kind of like there's some grass and land or something.
I guess it's also worth noting that I used a vert/frag GLSL that's in the MeshKit framework for the twirling GLSL effect.
There were said to be some other Desktop Pictures, locatable via http://creativebits.org/inspiration/snow_leopard_desktop_pictures .
The Art folder is a nice surprise, didn't think Nighthawks looked quite like that, but I've probably been influenced by glossy print copies being my only source of reference to date [light blue reflection lines, colour palette, etc] .
I can't get enough of this silly thing... I did another render a little bit ago...
thats pretty bizarre mad controls, i was messing with one of the controls an all of sudden my head jumped out at me, actually scared me for a second. wicked i will have to try this with some pictures. i like interpolating the depth just a tiny bit with some organic textures kind of looks like a breathing planet to me.
Oooh, I hadn't even noticed the new Desktop pics yet! I have to say... there are a number of choices that really resonate with me, on oddly coincidental and personal levels. I really like those.
I know what you're saying about Nighthawks... It looks more mellow than the cheap posters I've seen :)
It does have a wide throw to the controls, and you can make things that look like tunnels as well (at least I can, given my average lighting conditions).
The gl point stuff can be kind of wild, given the right imagery.
Verry nice!
I keep meaning to come back to Vertex Displacement Mapping, but every time I do, I end up getting frustrated trying to generate normals for lighting, and give up. I should just give up on that one, I guess.
Having said that, maybe I could do something like that using OpenCL.... Must investigate.
a|x
I always say this, but the plus of doing it with K3D is that you can subsequently put GLSL on it.
I was thinking the same thing about using OpenCL for something like this {though it would feel a bit like reinventing the wheel for the sake of it.... I already enjoy the way the Kineme3D heightfield works. It would also necessitate a different kind of setup, and I certainly couldn't pop the whole result in say, a Glossy Wet GLSL :) ....}.
Kineme3D does the displacement stuff on the CPU though, unless I'm very much mistaken, so doing it on the GPU, via GLSL and/or OpenCL would potentially be a lot faster.
a\x
you are correct -- k3d is cpu-only (except for the final rendering stage, where it's gpu-backed). I've been considering extending the pipeline to be GPU accelerated since before 10.6/CL was even announced, but never got around to it (it's a lot of work). It might be in the cards for a future update, but it's difficult to know... with 10.6's mesh stuff k3d's fate is in limbo...
I guess the only way to know for sure is to do it and see :)
I don't know that I'm sold on the OpenCL patch stuff and what's going on in the under-pinnings with it's QC implementation.
Something I've kind of had in the back of my head, is wondering if the manipulation of image/texture is also being GPU accelerated right now. I get halty/unsmooth results from simply rotating small, low vertex count dae's with interpolation. I kind of view the SL patches like alpha...maybe beta plugins, frankly. The only reasonable thing I can think of that would cause that kind of performance is the manipulation of textures using the deformers, or even just the rendering of them without deformers sometimes. If it is being GPU accelerated... then I guess running with two GPU's doesn't really give you that much juice :/
I've done some of the sample Xcode, where I can see the effect of GPU acceleration vs. "not GPU accelerated"... and then I open up QC, and it just gives the unsmooth "not GPU accelerated" look (not saying it ISN'T though, just that performance isn't smooth).
For example, setting up one of the Google 3D Warehouse dae's (even really small simple ones), and setting up a "walk through" qtz., the performance just doesn't seem good enough (this is without deformers). All I know, is that if I'm getting this performance on a 9400/9600 with a 3.06GHz, then I may as well not consider using that technique, because it's only going to look worse for others.
I guess what I'm saying is that I think certain common patch mixes/implementations may basically "cap" performance gains that we could eventually end up seeing down the road. Granted, the reasons "why" are totally speculative on my part. I just know what I see in my Viewer window.
BTW....toneburst, I soooo thought of you, and also tobyspark, when I looked at the mouse ribbon.qtz
:) It's exactly the same technique. All credit to toby for that one. I basically translated his custom plugin into JavaScript, and hacked-in some dodgy texture support. I'll have to have a look at the Apple example, and see if there's anything different about the way they went about it.
a|x
Hi George, could you please share again this patch please ? thank you!