nParticles, Self Collision, padiusPP overlap weirdness

#1

Hey guys,

So after many hours of trying to figure this out, reading the Maya docs, and old threads, I’m still completely stumped on this issue.

What I’m trying to do is scatter objects on to a surface, using nParticles and the particle Instancer. And I want there to be self collision between the objects, to prevent overlapping. I also want the ability to set the “radius” on each of those particles so that I can adjust the radius based on the different sizes of objects.

So what I have is:
Particle system connected with an instancer of two objects.
A creation expression that randomly picks an object, sets the first object’s radiusPP = 1 and sets the second object’s radiusPP = 4.

And when I run this, all the particles collide, but they jump and pop off of the surface, as if emission pruning isn’t on. This has been driving me crazy! I’ve got a screen shot of the my current settings and what it’s doing. And ideas?

From my tests, it seems to me like the emission pruning is only taking into consideration the “radius” attribute, not my radiusPP attribute, but i could be completely wrong there.

Thank you!
-Ryan

#2

Hi Ryan,

have you tried goaling the particles to the surface? Need parent UV needs to be turned on in the emitter attributes. Add parentU, parentV, goalU and goalV to the particle attributes and set the runtime expression to

goalU = parentU;
goalV = parentV;

The will push each other apart with the collision but try to maintain their goal position.

Cheers

#3

Hey simchron,

Thanks for the suggestion! I hadn’t tried using goalU/V yet. Definitely a good thought. However, it still isn’t working on my end, still have the same issue.

I’ve made an interesting discovery though. If I don’t have radiusPP on my particles and I’m simply controlling things with the radius (under particle size tab) when I scatter particles, there’s no overlapping or anything like that, it’s all good. If I continue to add particles, the new particles simply try to find an open space, and then spawn there. However, when using radiusPP, when I continue to spawn new particles, the new particles will actually push the previously placed particles out of the way to make room! I believe this is my main problem, any ideas on why there’s such a different nature between using radius, and radiusPP?

Thanks again!

#4

Hey Ryan,

I tried to recreate the problem and remember having it. The self collision display was not considering the radiusPP but the collision did. I tried using the internalRadiusRamp and radiusPP with creation expression and both behave dutiful :wink:

What Maya version are you using?
Cheers

#5

Hey simchron,

After looking at your latest post, which looked like exactly what I’m after, I decided to go in completely fresh and build things up. By doing so I’ve actually discovered what the issue is. At the most basic setup I was getting the desired results, like you. The issue appears to come from my more complex setup. I have the speed attribute on the emitter set, as I need some velocity data at creation time (I then zero out the velocity). As soon as I set a value for the speed attribute on this basic setup I was testing with, I got the same popping/jumping issue as I was having in the complex setup.

So good news, I found the issue. Thank you very much for your help on this! Was much appreciated.

Bad news, looks like I wont be able get both my velocity data, and the self collisions I’m after, which is rather unfortunate.

I’ll ponder on that some more though, as I’m still unsure why everything seems to work on my complex setup, using just the radius attribute, and not when using radiusPP.

Thanks again!
Cheers!

#6

Hey Ryan,

if the only way leads around the problem you could use the goal approach and instead of storing velocity you may take goalWorldNormal0PP and multiply it by whatever you need (in case you emit from a surface).

Cheers

#7

Hey simchron,

Thanks again for your comment. When I was first doing this project, I actually tried to use goalWorldNormal0PP but found that wasn’t going to work for my needs cause, this setup needs to work with surfaces that contain no UV data. So I’ll need a solution that’s separate from UV methods, and also using “closestPointMesh” to get normal data, won’t work cause that method is just painfully slow. I should’ve mentioned this before, my apologies.

Cheers!

#8

Hey Ryan,

there still is SOuP for you :wink: would scatter and copier suit your needs?

Cheers

#9

Hey simchron,

Funny thing, the whole reason for all this, is that I’m making my own scatter tool :stuck_out_tongue: haha. You may or may not have seen my recent thread on it:

http://forums.cgsociety.org/showthread.php?f=7&t=1444438

Thanks for the suggestion though!

But, good news is that I have thought of a new way to go about doing this. I’ve just coded up a function that will select a group of particles that are within a radius of a given point (seems to be a fast computing function too). So I figure now I can just loop through all my particles, with the desired radius of that object, select all the particles within that radius using my newly coded function, and delete them. So essentially getting my self collision :). But I also still plan to use the self collision + radius with a small value, to help evenly distribute objects at first. Then I’ll run everything through this new function. The scary part is I’m unsure how much of an impact this will have on performance. Praying it’s not too bad haha.

#10

Hey Ryan,

my bad. I read your thread and watched the video but did not recognize that it was you :wink:

So you made it to your satisfaction? Sorry it did not work out as it should.

Keep it up.

#11

Hey simchron,

No worries haha. I have not yet fully tested this new method, but it’s looking promising. I’ll just have to see how bad the performance hit is. But again, thanks for your input on this issue!

Cheers.

#12

Your fan club eagerly awaits updates and news, Ryan. No rush. No pressure. Just take our money when you’re ready. :slight_smile:

#13

Thanks for the comment infernal haha. I’ll be updating my other thread soon with an update (hopefully this upcoming week). Things are coming together well though :). Except for the issue mentioned here.

Tested my algorithm for self collision the other night on a complex scene and it was quite slow unfortunately. So I think I’ll just stick with having the simple avoidance for now. But the good news is that when it comes to painting objects, I should be able to have per object avoidance working on there just fine :), which I believe will be more important.

I do plan to revisit this particular issue at a later time, and will update here if I discover a reasonable solution. But for now I’m moving on.

Cheers.