|
|
ParticleTools Usability PollWe're interested to know what direction we should focus on for future development of ParticleTools -- it's complex enough now that future development really needs advanced planning and direction to be executed in a timely manner. Please rank these issues by importance, "1st" being most important. Choices
Lacks Adequate Documentation Lacks Adequate Examples Lacks Direction Lacks Flexibility Lacks Tutorials Too Complicated Too Generic Too Slow Too Unstable Your Vote
|
Hello,
Sorry if I'm not posting at the right place. I'm new here and... new to Quartz Composer. I'm very (very !) interested by the Particle Tools, but... it seems that it makes crash my Quartz version or it doesn't crash but nothing appears.
Do you have an idea of the trouble ? Is there an incompatibility between patches and/or different plugins ?
My configuration is : MacBookPro 13" (no dedicated graphic card), Mac OS X 10.6.3, Quartz Composer 4.0 (103.1), Framework 4.1 (156.13)
Thanks !
Yes, ParticleTools works just fine in Snow Leopard, provided QC is running in 32-bit mode (it runs in 64bit mode by default). Select QC in Finder, "Get Info", and select "Open in 32-bit mode".
(The integration between ParticleTools and Kineme3D does not work with Kineme3D 1.2, though --- it'll throw exceptions when trying to render.)
I have really just skimmed the surface of these tools until recently, and as I dig in I am experiencing a lot of crashes doing things that seem ordinary. So I can't vouch for "works just fine".
Thanks for your answers !
But (there is a "but") my Quartz version crashes everytime I try to run it in 32 bits. I guess this is a particular trouble, but if someone has the same trouble... Maybe I've installed too much plugins ?
Greetings.
Try making a duplicate of QC and then setting that one to 32 bit, that way you can run them concurrently, if you wish.
Running QC4 in 32-bit mode, I'm getting a consistent crashes using boids. One crash happens opening the demo Boid Fish comp (though I can select "continue" and delete the 3D stuff and it seems to work, though shakily?):
-[Kineme3DRenderer render]: unrecognized selector sent to instance 0x1677bae0
0x98a8ce19: -[QCContext renderPatch:time:arguments:] 0x98a8cb38: -[QCGraphicsContext renderPatch:time:arguments:] 0x98a8baef: -[QCOpenGLContext renderPatch:time:arguments:] 0x98a8b8b2: -[QCPatch(Runtime) render:arguments:] 0x0000f4d9 0x98acca56: -[QCView render:arguments:] 0x98af77d7: -[QCView _renderTimer] 0x98ad1fb2: _TimerCallback 0x98f3d70b: __CFRunLoopRun 0x98f3b094: CFRunLoopRunSpecific 0x98f3aec1: CFRunLoopRunInMode 0x95aa8f9c: RunCurrentEventLoopInMode 0x95aa8d51: ReceiveNextEventCommon 0x95aa8bd6: BlockUntilNextEventMatchingListInMode 0x91d06a89: _DPSNextEvent 0x91d062ca: -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] 0x91cc855b: -[NSApplication run]
Also, since that setup that works around with an iterator, there has been a new patch developed called the GL Structure Environment.
One can take the output of a particle scene, and connect it to a Structure:Render(particle tools) patch, and then to the input of a GL Structure Environment. After that, put your K3D Object(s) inside of the GL Structure Environment macro.
So, I don't really know which method is better because I haven't tested much, but I would think the non iterator method would be the way to go.
That said, both seem slower than it does if you downgrade to the last compatible version of K3D/Particle Tools.
Here's an example...
Speed is not so much an issue for my needs at present -- posted comps are up and running for me and that's good! Thanks so much.
(I appreciate the iterated sphere version of the particlepaint demo, too, cybero!)
This is actually a repost from one of gtoledo's posts, couldn't find whereabouts this was on the site, possibly in gtoledo's Box on his site.
Boid Workaround
It might help you out.
Particle Tools hasn't been updated to work with Snow Leopard (10.6) -- you'll have to run Leopard (10.5) or QC in 32 bit mode to get PT to work, if I recall correctly.
(Kill) Radcliffe Idea:
I have no idea if this is possible (not possible). It would be nice to have an output or some sort of event/callback/notification when a collider has a collision. This might get unmanageable with lots of particles however if it's always tracking that information.
Basically change output to true on collision and then you can fire off something nifty.
I couldn't find a way to do this currently, but I'm dumb and have a mac.
Well.... I'm not sure if it would be more appropriate as a force, or as a renderer. The idea is that you could get "fog" but control aspects of the coverage, so that it only effect certain areas of the qtz setting.
You would basically have height (altitude) and width settings (spread). Then you could have a selectable amount of "layers"... 1, 2, maybe more. There would be thickness, density settings, and color choice for the layers as well. All of that can be done without particles, so maybe I am kind of posting this in the wrong place!
But... the idea of having something like that and maybe being able to patch in forces like wind, or vortex, and maybe even utilize textures in some way (like "billow") to kind of have a billowy/foggy/particle(y) looking scene is appealing. I can see having something like a fog, but being able to have many tiny little particles creating it, or maybe a blend of particles and standard "fog/color masking" type of techniques.
I actually apologize, because I typically try to investigate something a wee bit more before blurting it out. I'm going to be a little lame and post something that isn't really what I am talking about, in the hopes that it sheds light on my thought pattern here... My idea would be something visually similar to this, except a bunch of really small particles, and the ability to "texture" somehow. It would also just be cool to be able plugin any kind of image input or texture and have the particles sort of "form" to the image.... I know my thoughts aren't focused on realistic implementation, and are kind of "pie in the sky" wishes from an art standpoint. Sorry.
Ahh, sounds like what you're describing is volumetric stuff (or media, in ray-tracer parlance). Simulating suspended particles (of dust, vapor, whatever, with brownian motion etc.)
This requires a kajillion (1x10bazillion) particles to look good, so it's difficult to really do well. Usually you can just fake it somewhat with GL Fog + a grainy texture overlay that's fog-level dependent (GLSL's pretty ok at handling this, I think).
Alternatively, one also deals with Shadow Volumes (to get through-window-style light "wedges") or something similar (accumulation buffer + Carmack's Reverse [patented] required), which doesn't have a chance in QC without accumulation buffer stuff (cue the zillion dweebs saying accumulation ops aren't HW accelerated -- not necessarily true)
There's a few ways to do reasonably fast volumetric fog (at least it's been a slightly common effect for a good few years now). I'm guessing volume slices and the like are totally out of the question here, but there's a simple oldschool way to do it that should work fine in QC.
Basically, you make a bunch of sprites, and give them a fog texture with alpha. They always face the screen, and they're all big enough to fill the screen, but they're arranged so that they spread out into the distance.
The idea is that when you render, you get the scene plus these layers of fog, and the fog effect is determined by the texture (which can make it patchy, and animated in 3d just by moving the texture differently on each sprite). The fog gets denser as it goes into the distance too.
The downside is that you need a fair few layers to get it to look good, there's issues with z sorting and transparency, and you get obvious edges where the sprites intersect with the scenery. You can get around the z issue and the intersections with some glsl trickery, at least to some extent, but it's probably not exactly easy still.
The clouds video I made (it's on vimeo) uses this technique -- unfortunately, QC's iterators are too slow to make rendering lots of sprites for this purpose useful. the video used I think 300 sprites, with random positions, rotations, and height-based colorization, and runs at a whopping 8fps on both my MacBook, and my MacBook Pro (meaning it's not GPU-limited, but crippled iteration limited)
Yeah, the iterator/sprite thing is cool in that it is almost a catch all for many things that could never be done otherwise... I'm definitely aware of the "simulation" approaches on this...
The thing about volumetrics and needing wayyyyy more particles is understood. On top of that, it seems like some of that stuff doesn't even usually work in real time. You have me a little curious about the GLSL and texture comments though...
I wonder how it is that Adrien Mondot is rigging his particle patches to be "pictures"... and then he can apply the forces. Hmmm. Maybe he's just doing an image mask on a particle scene inside of a render in image and I need to look closer...
I know the two things may seem incongruous, but in my mind, this idea of the fog/cloud thing, and mapping particles to pictures seem intertwined. Because, you could load any picture and have the particles reflect that texture... with a little accumulation or feedback you could get some nice wispy textures. I love that the particle systems have an image input for the actual particle... but it would be interesting to have an image input for the overall scene!
Besides iterators and sprites... smoke/cloud/fog like things are also really really easy by doing a gradient particle with some feedback- it looks like smoke, or even clouds. You don't have that nice grainy particulate dust stuff, but that is OK (kinda). When you put that in "add" mode you can then just plop it on top of 3D characters or whatever, and it now looks like you have smokey foggy stuff in a real setting [ok I see I am going to end up mocking up a qtz and render as illustration probably :o) ....]
If you could have a patch that looked like this fog clip at a stand still, and more like that feedback "particle wreath/smoke" looking stuff when you give it the "juice"....but you could control transparency... I think it would be the basis of a decent cloud/fog/smoke patch. I think it would be somewhat contingent on if "feedback" could be built into a renderer, so that you didn't have to go through the hopscotch of putting stuff in a render in image, or accumulation, or whatever. And... there would be no need for feedback with "still" settings, so it would have to be implemented tactfully.
This is a patch with a cloudy/foggy feedback, plus 3D (teapot, lol) object, to illustrate what I mean, sort of. A patch that approximates or betters a look like this but that works better with other background colors, and has more straightforward transparency, thickness, spread, velocity, etc, settings... and that you don't have to do this whole render in image/feedback setup thing with.... The patch would have it's own "feedback" happening, and perhaps it could kind of do a smooth blend from "feeding back" to "no feedback".
You can see that the trails that are left over from the particles/feedback do sort of resemble a standstill typical fog in many ways, and that the feedback particles do have a very cloudy texture.
The problem with what you're doing there is that it's "2d fog" - the fog is in front of the scene, not inside it. Imagine if you made a scene with a long street, with fog in it - it should get more and more foggy in the distance. With your method it wouldn't. If you're doing it that way, why not just add an overlay with some animated fog texture? (a couple of perlin noise layers plus a random noise for graininess all moving at different speeds should look much better).
I had an idea for doing what I said with the 'tons of sprites + texture" method better. This should actually look better, and I reckon it will be very fast too:
I'll have a quick go at setting it up, see what happens :)
remembers that the particle system patch ignores the z buffer
Heheh. BTW, you will see that there are two "fog" systems with different z values. So in a sense you are right about it being 2D because it IS in a render and going to a billboard, but if you have two different z values, with the other rotations, it makes that mass "wrap" around the object (in front, and behind), and it doesn't "look" flat either... though what is missing is a way to "rotate" the "trails" of the fog feedback. Really that is the only thing that can't be done for "faking this" with no patches. Once the thing leaves its feedback trail, that needs to be able to be realistically rotated inside of a 3D transform.
So the idea would be a renderer like this, with feedback, and "amount of layers" selections (versus the two layers" that I set up), a "feedback decay length", "translucency" "gl depth" "height/width", etc.
I haven't had my coffee yet, so apologies if I am saying anything too out there :o)
... and if I see that cloudy teapot turnup in some techno dance thing without some kind of credit, I swear I will toss my cookies :o)
Also... I don't know if the vote reflects what I would "say". I voted for flexibility, but I do think this is pretty flexible given what is in QC as standard :o) More features, more particles with less overhead are the two most desirable things for me. Documentation and examples are great, but somewhat icing on the cake as well. I know many people comment about the setup being complicated, but it seems to me that you just have to be willing to dig in. I don't think it's any more daunting than going through every one of the CI filters to see what they do...
if you ask me, i would say that it lacks a few features. Vector field (to slow-down/speed particles), 3D attractor, Path follow, Sticky particles... this would really help to actually CONTROL the particles. Having said that, v0.3 kicks ass and is a huge improvement over past versions. Thanks for the new release ! The comps included are great too...
Volumetric forces are on the drawing board (lots of work to implement, so we cut them from 0.3, and plan on them in 0.4 or 0.5 or something.)
Can you elaborate on 3D Attractor? (Gravitate does this, boids somewhat does).
Additional agent behaviours (avoidance, goal points, etc) are planned for future releases.
Sticky Particles changes everything -- smokris and I just discussed this, and it's a really cool idea, just a bit out of the current model, so it'll take some effort to add in. I'd like to see that feature too.
Glad you've had success with it thus far :)
yeah, good to know that some more feats. are on the roadmap. I also noted that when looking at the TODO. files included in the source.
3D attractor is basically the Gravitate particle, however, it seems that i can't get rid of the newtowian motion (reducing its param. will make the particles shaky, but they wont freeze and stop their motion). I'm still learning and tinkering with the new release, however, i didn't manage to be able to have an attract/repel behaviour. Having an attract ratio of +1 (for instance) would attract the particles, and a ratio of -1 would repel the parts. Does that make sense ?
Also, i would like to elaborate on sticky parts: a sticky surface is needed. Currently, the collision patch has no FRICTION param. Adding a friction (as opposed to bounce) to a surface would allow the parts. to stick on the surface once collided.
And yes, i'm having real succes with this patch so far (even if it was buggy up to 0.2).... !
isn't the DRAG parameter of the Collider some kind of friction ? where could i find the docs about all the parameters ? (this would avoid me asking stupid questions...)
There isn't any documentation on most of the parameters (even in the original VEE system).
I just set up a wiki topic for ParticleTools documentation, and wrote some explanation on http://kineme.net/wiki/ParticleToolsCollider.
The Drag parameter doesn't actually induce a static friction/traction force (which would be needed for a "sticky surface" as you described), it just affects the rebound velocity.
If there are no other forces in the scene, you could kinda simulate a sticky surface by setting Bounce=0 and Drag=1 — this would cause the particles to stop on contact. See attachment.
kewl, thanks for the example and the documentation. It is really appreciated. (i know this takes a lot of time, not necessarily interesting from a coder's perspective). Particles actually stick, so that's really the behaviour that i'm after, thanks again.
Strangely, when i change the renderer type, (using VBO with Quads, Lines and Tris -but not points -) , particles seems to get killed on contact .
See attached file
As a sidenote question, what's the advantage of using VBO renderer Vs. GL structure ? Speed ?
Ideally, the vbo renderer would be really fast, but in practice and profiling, it's no faster than the standard immediate-mode renderer -- too much time spent traversing the VEE data structures.
The quads, tris, and lines all might use velocity to assist with size calculations -- when velocity is zero (as when they're stuck), they might get drawn with zero size... :/ maybe fiddle with some settings to change how that works (I don't know if there's a way to modify that for the VBO renderer, but you shouldn't use that one anyway, if you can avoid it).
George -- could you elaborate on what you have in mind for "sticky fog" (and how this differs from the existing
Force: Damping)?On the "sticky" note.... sticky "fog" areas would be a heck of an interesting thing in QC.
In addition, if I take franz's qtz., and even just put a sphere GLSL patch in it, and attempt to run the two at the same time, I get a crash. I can toggle one off, one on, it works.
Without a clear and both running, it immediately crashes; with a clear, I see a could seconds of the blue glsl grid before a crash. Note, I'm NOT trying to put the particles system in the GLSL... which I wouldn't be surprised if it didn't work, but I wouldn't expect a crash.
I'm able to reproduce this -- thanks for the sample file. Not sure what's happening, but we'll check it out.
That is a cool example... evocative of a snowfall.
With the particle tools, there is a vee_marching cubes in the base folder. What would be a good example of seeing that part of vee in action/understanding what it is doing within the current context of particle tools? To be clear, I understand the concept of marching cubes, and was poking around because of toneburst's medical scan 3D imaging and speculating as to how the concept could work with particle tools.
I'm also curious about the py. files, lwo. objects and image files (it looks unlikely that they are all being used)... is some of this remnants of Vee that is just in the source but not being used?
Excuse me for not going through the xCode more stringently, as I am sure that would answer my questions, but it is a slow process for me as I'm on the uphill climb of the learning curve and I would likely not connect some of the dots. At the same time, I don't seem to see those implemented in my looking through the project (save for marching cubes)... The py. stuff doesn't seem to be used.
Remember that vee was originally for linux, and used in a very different environment. smokris ported it to OS X, removed the py bindings (.py = python files, not used). lwo's are some kind of 3d object format used in the original stuff for testing etc. I think the original build apps that used them for testing/demonstration purposes.
I'm not sure how useful the marching cubes stuff is for actual visualization as-is -- remember that marching cubes is used for lots more than just rendering volumetric stuff. In this case, I think it's for rendering/mesh generation, but not in a format that we handle natively.
Oh yeah... smokris had already pointed out how he stripped it of the python bindings, I guess that had answered that question. It shouldn't be a surprise to see them since it is the source folder!
The lwo objects caught my eye because of the "town explosion" py. file.
The idea of sticky particles is cool... It could probably be somewhat emulated/faked right now? It seems like particlepaint could be setup to kind of cop that vibe, as well as the boids forces to an extent?
This could definitely be done... I think :o) It seems like this could be done with particle paint, kineme3d, and a little spray at the correct rotation, to "meet" the line drawn by the particle paint.
For some other sticky particle stuff I have seen...
I conceive of a way of using the boids, like when the fish are flocking together, with the idea of the gravitate-nbody... which has a point right in the middle. It seems like it could at least be setup to look as if there is one central particle, and a bunch of particles gravitate and stick to it, even if they aren't technically sticking. I dunno :o) Haven't tried it....
well .. maybe this is why I'm being such a slow study. heh. Where do I find these example compositions that George mentions above? I've never seen anything appear but the plugins themselves when I unzip the various Kineme archives. That said, I'll defer to to the experienced folks regarding the poll.
They're in the source archive -- there's a folder in there titled "compositions" that has examples.
It's a somewhat illogical setup (compositions should go with the actual plugin -- source is for developers), so maybe we'll modify our update scripts to compensate for that..
Excellent. Thanks! :-)
... you could always put them in both :o) Next time around I will be going "where the heck are the examples!"
Lee, you should do the same with the GL Tools, that has many great examples.
Actually, that makes me realize the cool example with the crossbars and the fish wasn't in here, but it seems like it would be easy enough to emulate...
I am looking forward to trying to use that flying brush example in a similar way to the standard particle system I posted a few days back, but maybe flipping between some different particle types.
I haven't done any of the stuff that traditionally puts any of this on the fritz yet though :o) (like heavy replicate in space with vertex shading). So it's warm fuzzies for now.
Sincerely, gushing in florida
I want to use the new version a bit more before I take place in the poll, but it seems like this is also a bit of a discussion thread opportunity?
All I want to say is THIS IS AMAZING. After looking at all of the examples, my first impression is nothing but positive. There are many spectacular starting points in my opinion at least. The boid fish, particle collider, the flying brush and the way it's setup to flip through the various modes, good to see the particle paint as an example comp, the red wedge may potentially have me avoiding using glsl to get similar shapes.... all in all very significant. Fire vbo is wild...
Now the reason for the kineme3D translate and rotate is clearer.
I'm sure there are going to be plenty of nice surprises as I dig in....