Polygon Effects

It would be great to be able to apply these kinds of effects to 3D meshes: http://www.vimeo.com/672580

I guess it could be done with Geometry Shaders, though I don't know if they're usable in a QC context.

a|x http://machinesdontcare.wordpress.com

Duplicate of [http://kineme.net/node/9218](http://kineme.net/node/9218)

franz's picture
CPU ?

it could be done on the CPU if Chris or Steve decide to make a : - Explode 3D patch (actually my number 1 request) - Gravity 3D patch - Collision system for 3D objects....

a lot of work i guess....

DanieleCiabba's picture
Gravity 3D patch - Collision

Gravity 3D patch - Collision system?

a stuck in my head

Daniele

cwright's picture
definitely

this isn't special enough to require gpu acceleration at all (a bunch of points/polys bouncing off of a constant plane, woo, 9th grade physics! ;). Geometry shaders, as far as I know, aren't supported anywhere on Mac OS X yet -- probably with Snow Leopard...

Now, if all the polys responded to each other, that would be something (and if his animation too 6 hours for 5 seconds, it would probably take months with self-interaction.... man, processing is so slow!)

Explode is something I've been thinking about a lot for kineme 3d (what little time I have left to devote to that anymore :/) -- not entirely sure how to cleanly implement it though. (read: open for suggestions! :)

franz's picture
....

it probably took him some time to render, due to the AO effect.... but not so much as there's no inter-polygon collision (the chunks cross each-other)

cwright's picture
right

I agree, the AO stuff is probably what made it take so long. But 6 hours? Raytracing can probably outpace that, with high-quality global illumination lighting even (for accurate soft shadows). So I wonder where all that time went (incorrect settings, slow algorithm, etc). No idea.

I was saying how if he had made the polys interact, it would have taken much longer (if AO makes it take that long, calculating trajectories and rotational forces from that many falling polys would have perhaps doubled his render time...)

psonice's picture
6 hours?! / geometry shaders + ao.. a real man's example

How the hell did he manage to make that less than realtime?! o_0

Anyway, a proper example of what's possible with geometry shaders, that also happens to use AO (and just for good measure, the whole thing including the music was done in 4kb :) :

http://capped.tv/playeralt.php?vid=keyboarders-texas (boo - the [ video: ] tag doesn't work with capped.tv!)

(ed.: we added support for capped.tv)

The cubes are all done with geometry shaders - this is the kind of stuff we can look forwards to in QC if apple put the right bits in the right places. You can download the original here: http://www.pouet.net/prod.php?which=51448 if you're interested (be warned though, it only runs on vista).

toneburst's picture
It WAS raytraced

Sunflow is a raytracer.

a|x

cwright's picture
*details

sunflow is java based. (I've never been impressed by java's performance on real-world problems, but my experience with it is fairly limited, so perhaps that's not the problem).

There are ~50 boxes (I counted about 40 in the early frames), with 6 sides each = 300 sides, 600 polys (2 triangle polys per side). one more for the ground plane, and that's 601 polys, and a single area light source. no complex shaders necessary.

I don't know much about this particular renderer, nor the settings used, but I'm honestly not impressed. It mentions having adaptive sampling for area lights and antialiasing, and a deterministic monte carlo sampler, so it shouldn't really take all that long, even with global illumination (with a basic octree, or even bounding boxes, for space partitioning, the number of intersection tests would be really low, making it a pretty quick thing to render). It's also multithreaded, which should make it faster still, if it was rendered on a dual-core machine (and 4x faster if it was a quad core, etc etc). Machine specs would be nice to have I guess, as well.

in 6 hours, there are 21600 seconds. the clip is ~5 seconds long. at 30fps (vimeo drops everything to 30, maybe it was higher?), there are 150 frames to render. That's 21600/150 = 144 seconds per frame, or almost 2.5 minutes.

At this point, I was going to post some timings of various scenes rendered with povray (hardly a beacon of speed and performance, but a decent reference point), but their mac version is ppc-only, and the source requires boost, and I don't feel like building every dependency for stuff like this anymore (sorry, but so long, linux!), so I couldn't do it in a reasonable amount of time. So we'll just have to accept it as it is I guess. shrugs

toneburst's picture
I may be wrong

but I think you can do similar kinds of things on the GPU using Geometry Shaders, which deal with polygons before rasterization.

What I don't know, is if Geometry Shaders could be used in some kind of QC plugin. I guess you'd maybe have to write some new kind of Macro patch, but I don't really know.

cwright, any comments?

a|x

cwright's picture
never seen it

We discussed Geom.Shaders briefly when working on the SuperGLSL grid stuff a while back -- at that time, geometry shaders weren't supported on OS X (any card), and I still think that's the case. I'd love to be proven wrong, but without support for them, there's nothing to be done.

You're right though, it'll require a new macro patch (with a GS, as well as VS and FS sections/inputs).

(secret: I saw some demos using geometry shaders at wwdc, so I'm thinking apple's going to use them as a selling point for snow leopard or something)

Geometry shaders are an OpenGL 3.0 feature, and there was a bucket load of controversy over 3.0 (Longs Peak edition), since it originally omitted geom. shaders. It wasn't until the Mt. Evans revision that Geom. Shaders became possible in open gl -- so, they're almost certainly not possible on Leopard Right Now at all.

toneburst's picture
Interesting...

I'll wait until Snow Leopard comes out, in that case. Any chance of being able to do something similar on the CPU? That polygon explosion effect is pretty cool...

a|x

cwright's picture
totally

That demos is possible with exactly zero geometry shading -- I don't see what it's doing that requires geom shading.

(Geometry shader = "I feed OpenGL 3 vertices, and GL renders >3 vertices) -- extremely handy for generating very smooth surfaces without a bazillion polys, for doing cool effects that aren't at all like this one, and for doing displacement stuff with normals intact)

polygon explosion is probably the trickiest part of this, and that's not actually all that tricky either (in kineme3d, objects are large collections of indexed vertices, normals, and texture coords -- exploding simply extracts subsets, so you can operate on them individually without affecting the whole groups. Structures/iterators/JS are all too slow to make this kind of thing useful real-time, but that's not kineme3d's problem, it's QC's.)

franz's picture
one idea for an explosion:

  • 1 separate all faces / or group of faces according to min/max number of faces per chunk (= chunk size)
  • push all chunks outwards the gravity center (usually the pivot) according to some speed value when "explode" is triggered
  • add some chaos options: spinning/random velocity/random motion direction

and of course make it externally time-based (optional) to be able to pause/scratch the whole stuff.

Of course CPU is preffered over GPU, as it would allow to combine other KnM 3D behaviour (like morph, noise, attract....)

I think this is it for a very basic yet powerfull explosion.

Dynamics comes later -although simple dynamics without inter-chunks interaction should be doable, right ? (or should i say wright ? ...) -

gtoledo3's picture
I have recently been

I have recently been thinking that collision detection may be possible by changing the javascript part of "teapottii" and the "bounce" setting, but setting it to cross reference other objects on screen as boundaries, by having a set of input of what coordinates are ones to "bounce" when they hit... instead of it just being the edges of the composition.

Haven't got into it yet, spilled coffee on the Macbook this morning, and I am in mourning, etc....Yep,the motherboard is fried. Ugh. At a real bad time for that to happen too (but when is the best time to weigh dropping that hefty flat fee that I can't afford, vs. just getting a new one?).

memo's picture
sweet shading

If anyone is interested in realtime AO and other nice shading see the master at work http://www.vimeo.com/1359057 (and check his other videos)

franz's picture
realtime AO + 1

i'm more than interested in realtime AO.... does ne1 have such a shader (GLSL please...) ?

psonice's picture
fake SSAO

Not really true SSAO, but a pretty good fake made by Toneburst and tweaked a bit by me:

http://kineme.net/Discussion/ProgrammingQuartzComposerPatches/separating...

(see that post and the few below with attachments)

There are much higher quality ways of doing this, but they tend to be pretty hard. And true AO will be much better than SSAO, but it's even harder still... as somebody described it to me, this is a "fake implementation of a rough approximation" :)

toneburst's picture
Looking At Inigo Quilez's Stuff

makes me want To cry.

a|x

psonice's picture
iq

He puts a lot of stuff on his site about how he does SSAO etc., and provides source for a lot of his stuff too:

http://rgba.scenesp.org/iq/

toneburst's picture
Just So You All Know

I wasn't saying that video was particularly technically impressive, merely that I liked the effect (which I've seen before lots of time), and that it was a good, simple example of it in action.

a|x

cwright's picture
:)

I hope we know that :) it just turned into a weird technical discussion on minutiae.... what nerds do best I suppose. :)

Anyway, it turned up some /really/ impressive stuff from the discussion, so I'm very grateful for the contribution. I had never heard of Inigo before, that's very impressive to me.

Sorry to drag it out in the wrong direction :/

[as a disclaimer, I personally am really interested in interactive raytracing and the like, which is why I took such notice at that detail. I've not poked at them in several years now, but was expecting things to be considerably faster, just because of faster machines etc...]

toneburst's picture
Did you ever try

picking apart that realtime isosurface raytracer I uploaded here a while ago?

Sorry for being a bit prickly.

a|x

gtoledo3's picture
Oh this is

Oh this is unbelievable...60k...geez.

psonice's picture
and there's more!

tons of 64kb stuff:

http://www.pouet.net/prodlist.php?type[]=64k&order=views

tons of 4kb stuff:

http://www.pouet.net/prodlist.php?type[]=4k&order=views

If you're looking through them, pay attention to the date if you want impressive stuff - there's a lot of old but highly rated entries that will look pretty dated compared to the latest and greatest.

Also, that 64k is by RGBA (iq is their coder), but it's a 64k version of another demo by a group called plastic. They do some really amazingly high quality stuff, and are always trying out new techniques like AO and HDR. Check out their stuff here:

http://www.pouet.net/groups.php?which=3210&order=release

gtoledo3's picture
You know what... Apple was

You know what...

Apple was full of it. The laptop is working now :o)