Have been playing with vvvv and DX11.Pointcloud a while ago and found out recently that DX11.Particles has been enhanced with a lot of cool features. However, I can’t reproduce some old Pointcloud functions. The most crucial is emitting a dense particle stream from Kinect. In the old version, that worked pretty nice. But I can’t reproduce it in the new version. It seems that it either emits only once per 1 sec. lifespan in a dense resolution (Mod node Input set to 1), or in lower resolution (when Mod node Input set to 20+) every frame. So I’m wondering if there is a max particles setting somewhere or anything else I’ve overseen. From what I understood, all particle number settings are related to initial particles rather than already emitted particles.
The image illustrates the difference between the old and new version. On the left side the old version with a continues dense particle emission. On the right side my (failed) approach to reproduce this in the new version by getting only one emission per lifespan. Attached also the two patches, which are based on the Packs examples and a video of the two renderer. Thankful for any help or hints. emission problem.zip (2.0 MB)
The Total Emit Count relates to the memory footstamp, that this particular emitter reserves within your particle system. If you manually move this higher, you get more particle slots in memory, and the Emitter will not have to overwrite older particles (this was different in the older pointcloud system, where AppendBuffers where used, with variable length).
edit: I believe the ElementCount pin of the GetThreadSize plugin and the EmitterSize pin on the shader should also have your manual value to work correctly, i.e. adaptively finding slots within a larger range. the dynamic emitter has even more logic there, so take this with a grain of salt
The next step is to overcome the limitation of the Kinect emitter, that it cannot manually change a particles max lifespan (by design, this is set to 0, so all Kinect particles can be reused the next frame). For this, you can use a Selection of all newborn particles, and mod-pick a few. Those can than be modified to have an actual lifetime.
Please not, that this is purely theoretical without a test with the kinect, but maybe it helps to get you to the look you want. I am sure, there are better ways to do it, but thats the best I can do now ;)
I was fiddling around with the Mod and emitter count/size parameters a lot but never achieved the desired result. Increasing the mod input to 20, uses every 20th particle to emit from and then indeed emits more particle per frame, but on the cost of a dense emission from every point.
Increasing the count/size seems to do “something” as the performance starts to drop massively. But there are only a few additional particles emissions.
I’m still hopeful that there is a solution because it doesn’t seem to be related to performance, otherwise it wouldn’t has been possible in the old Pack. When looking at the geometry emitter example, I also had trouble to get a seamless emission from all points, even if the geometry resolution is low. So I might have missed some right parameter settings or selection dependencies.
as I said in the particles thread, you can achieve the evenly distributed particles emission with help of the modulo selector.
you can also calculate the needed size of the emitter with number of (max particles per frame * fps * lifetime) / mod value.
That helps a lot giving the low dense emission a more even distribution.
What’s still not clear to me is how to get a dense emission from all visible points as it was possible in the pointcloud Pack (comparing image below)
In the patch you sent, emitting from every point by reducing the mod input still causes a huge performance drop (almost freezing). Strangely, this even happens if there are no particles/Kinect players visible. It seems that any filtering affects only the visual appearance but not the actual calculated particles and related performance load. In the old Pack it seemed that the amount of emitted particles directly affected the performance. Thus, the use of texture and 3d filters had a positive impact on the performance and was very helpful for optimization, especially as in most scenarios only particles generated by players are relevant. Maybe that’s why it was possible to achieve a more dense emission from the Kinect grid in contrast to the new Pack. Not sure if I am correct with this observation (still hope it can be proofed wrong). It would be really strange if the new Pack with all its great features has such a limitation. Please Help!
that cannot be the case by design, since all the calculations are done for living particles only. so if your kinect emitter doesn’t emit particles, all following shaders will skip calculations. so… are you really sure that your texture filtering is correct?
you can check that by using a readback (uint) on the ALIVECOUNTERBUFFER (from the output pin of the particlesystem node -> have a look inside to get the correct slice number). also check that count after disconnecting the second emitter.
the patch I uploaded before runs at 120fps on a nvidia gtx680 when I remove the framelimit and let the emitter spawn particles in a 30fps cycle. ah and by the way… the pointcloud screenshot looks like you are emitting only every X frames. is that right?
Many thanks for the hint. Tested the particle count. Indeed I am not sure if the filtering I am using is correct, so I just covered the sensor. Only a little area was detected and emitted particles. Please have a look at the screenshot. On the left side the sensor is covered and on the right side particles emitting from the full image. The values from the readback IDs are very similar in both cases (just jittering). The test was done with the patch you sent earlier and only the Kinect node changed to Kinect v2 (attached).
I guess the equal count result is not how it supposed to be. Also, your patch barely exceeds 40fps here (gtx980) when removing the limiter and the rate drops down to 10 when adding the readback nodes. So luckily it looks like a glitch somewhere in my setup/installation (unless it’s related to the changed sensor/node version). Any suggestion?
Btw, the pointcloud screenshot runs at 30fps, one can see the individual frames because the motion is quite fast. A video is attached in the first post along with the two patches. As the old pointcloud runs fine on my system, it might be possible that the new Pack relies on some other packs/updates (latest dx11 pack already installed). Any other requirements or suggestions how I can get this working here?
remove the second emitter and compare it again. the same count is normal as long as the second emitter is connected.
and please do only a readback on ALIVECOUNTERBUFFER. it is also normal that readbacks drop fps.
There are 4 emitters in the patch, so not sure which one you mean with “second”. Also don’t know the ID of the ALIVECOUNTERBUFFER. When removing the “Emitter, AND, Mod” nodes, ID 4 drops down and jitters up occasionally. When disconnecting the other Emitters/Selections from the Group all IDs either dropping a bit or freezing.
I downloaded the “Kinect - dx11particles.v4p” patch and I’m playing around with it (thank you and OP so much for sharing). I am on a deadline for a project which consists of having movements being captured by the Kinect and have it drive a particle animation. This patch is exactly what I was looking for, however I do not understand how I can customize it ? I’m a newbie, I did not know what VVVV was a week ago…
I’m trying to choose (for starters !) the direction of the particles. Right now they’re going up. Any tips ? Would it be possible to add text to the important nodes in the patch to point out which values to change to customize the particles ? Colors, speed, direction, lifetime, linking particles etc…
please have a look at all the modifier help patches (by clicking on the modifier and pressing f1).
there are a lot of modifiers like force, velocity, lifespan, color, colorbydistance, colorbylifetime,…