Keep Apart Issue

#1

Hi Folks,

I am trying to create a simple crowd setup using PFlow (at the moment with 40 particles on a plane 20x20m which should be big enough. the guys are 1.8m high so i assume they are less then 1m wide :D). There are 4 hidden boxes that work as walls with a collision/bounce thingy going on. So far its working fine. Thing is, if i use keep apart and use Accel Limit and Speed Limit, my guys still bump into each other (or to be precise, walk trough each other - bumping and turning round would be more or less fine). Its not as frequent as if i turn the keep apart off, but still.
I have a speed on surface that at 1.0m is exactly the speed of the walk cycle (so they donā€™t slide). So in order to have them look more or less realistic i have to restrain them to that speed (with a bit of offset).
Values are:
force: 0.01 (i tried anything between 0.01 and 1000.0 - there is no difference. only 0.0 makes a difference.
Accel Limit: 0.4 (if i offset this to 0.1 to 0.9 the collision does still happen, it just happens a little later or earlier. Depending on the value. If set to >1 the one on the picture does not happen anymore, but there are others). Furthermore the guys slide or are walking in place (which is natural as they donā€™t have the speed of 1.0 anymore, but anything above 0.5 just is way to obvious).
Speed Limit: 1.0 (anything under 1.0 doesnā€™t make sense as its not the right velocity for the guys. anything above 1 causes the problems mentioned above).
radius is set to 1, fallof something around 5. But iā€™m not entirely sure, as i have tried nearly any value. even setting the radius to about 3-5 m does still end in some collissions. and with a huge falloff, they only walk in place and turn themself round.

Any suggestions? i really donā€™t know what else i could try. changing values at random did not help me so far.

#2

As a rule of thumb your accel limit should be equal to or greater than the force value and falloff zone should be equal or greater than the core radius. Keep Apart isnā€™t a perfect solution but works well in most cases.

Box#2&3 it would be a snap (at the very least just Box#3), using a proxy system with the greatest extent of the particles shapes as your physx shape object. This will repel by collision shape, you could soften the collision by a distance check and decelerate within a certain radii of a neighboring particle (much like Keep Apart), cache this simulation and use the cached TMs to drive your animated particle shapes in the main system (box#2 doesnā€™t fully support animated particle shapes as of yet), using the Box#3 data op to gather TM data from the proxy system.

I suppose you could use a crowd system too, if you are going vanilla max.

#3

Thanks for the reply Johnny.

Box#2&3 (or any other commercial plugins) are not an option iā€™m afraid. Iā€™ll have to manage with what max can offer (and with what i am able to script). Free stuff is fine though.

If i use accel limit 2, speed 1. Radius 1, fallof 2. it looks actually quite fine. There are no more collisions. However, now my characters start to slide an walk on the spot (i uploaded a video. their is one in the mid right section thats especially scared of the others and afraid to walk anywhereā€¦).
So: is there a possible solution (maybe via script) to always check the speed of a particle and use this speed to trigger different ā€œplayback speedsā€ of the animation? (right now they are point caches - one walk cycle is 32 frames. so at a speed of .5 maybe stretch it to 64 frames and vice versa). best thing of course would be to play actually different clips, not only speed up/slow down the animation. but it would be a start :slight_smile:

About Crowd: Crowd cannot handle bipeds correctly, nor can it handle Point caches (i can link them, but its not really convincing).

Link to Crowd Test Video

#4

Have a look at this thread maybe it is what you are looking for, somebody had asked about this a little while back:

http://forums.cgsociety.org/showthread.php?p=6673218

Basically works with the particle shape instances animation offset keying using the particles age and speed magnitude.

#5

That really looks like the solution! nice video btw.
But i do have a very stupid question: How do I actually use that script? The Scipt operator on its on doesnā€™t do anything and with script wiring in keep apart and the script operator below or above, itā€™s either not amending the speed, or its having collisions again (and still not changing the animation speed).

#6

The snippet of code for the script op in the other thread is incomplete, it is just the proceed interval. Here is what the whole script op should look like:



on ChannelsUsed pCont do
(
	 pCont.useAge = true
	 pCont.useSpeed = true
)

on Init pCont do 
(
 
)

 on Proceed pCont do 
 (
	 count = pCont.NumParticles()
	 
	 for i in 1 to count do
	 (
		 pCont.particleIndex = i --the particles Index number
		 speedMagnitude = (length pCont.particleSpeed)*100 --this acquires the length or the particle speed vector and multiplies it by 100 to make it more usable with age
		 adjustedAge = pCont.particleAge + speedMagnitude -- add the vector length plus the particles current age to create a new particle age
		 pCont.particleAge = adjustedAge --set the new particle age
	 )
 )


on Release pCont do 
(
 
)

You donā€™t need to script wire this to anything, just place it before the Shape Instance operator.
Just make sure your out-of-range types is set to loop in the trackview.

#7

Thanks for the Script. I changed the speed by surface to control speed continously (otherwise the script wouldnt do anything). Now it at least speeds up the animation (if particles accelerate). However, if i they slow down, they still will walk in place :frowning:
See this video link. There are also some weird ā€œi refuse to move at allā€-guys happeningā€¦

#8

Hi Johnny,

I did some changes to my PFlow System. There are now 2 more or less identical events going on. both events spawn 50 people each. They use one keep apart operator (speed limit 2, accel limit 25 and some other stuff).
What is different: the left event (red people) have their speed set to 1.1 with a variation of 1. the green (right event) have there speed set to 1.1 with variation 0. Both speed by surface are set to control continiously and use ā€œsync by ageā€.
The Red ones should use the script you gave me.
Now the issue: As you can see in the link, the green ones are moving quite fine (there are one or two collisions happening, but thats fine and considering the density of the crowd ok) without any sliding. But they have all exactly the same speed and they only turn to avoid collisions. They donā€™t slow down or speed up to avoid them.
The red ones do have different speeds. However, each red guy keeps his own speed. They dont slow down, nor do they speed up. The really weird part though is, that all the red ones have the same playback speed. So the script obviously isnt having any effect.
Now you might think ā€œhey, there are 4 scriptsā€. Well, i basically tried every one of them (004 and 005 are instanced copies of 003. 006 is just a copy). I tried switching different ones on and off. But all it does, is giving them different starting positions. It doesnā€™t affect their speed though.

Any help would be much appreciated. Iā€™m kind of lost here.

One thing i thought: could it be possible, because my guys are actually just PointCaches with only 2 keyframes? (one at the beginning of the cycle, and one at the end - so i can use the ā€œout of rangeā€-loop option)

cheers,
Chris
P.S: Video-Link
P.P.S: Pflow layout:

#9

I meant to reply earlier, got side trackedā€¦

Here is a simple test scene, you will need to download SuperMesher reader here, relink the Supermesher cache and the Point Cache file from the rarchive, so the particle will have its mesh and animation cycle.

Take a look at the Point Cache TrackView in the attached scene to check for the correct setup. I am thinking you have it correct.

max2010_PF_AnimatedParticle_Loop

let me know if that helps.

#10

I think Iā€™ll just go mad for the time beingā€¦

If i open your scene, everything works fine. If i replace your shape with mine (and my Point Cache) it works too. If i try to edit the speeds (so it looks more realistic) everyone stays in place! They are animated, but they dont move.
If I use my scene. Nothing works. Neither my PF Source, nor if i rebuild yours (even with your values). I cheked the keyframes and the out of range animation. I honestly have No idea whatsoever what is causing all this.

#11

That is odd, there really is nothing locking in a static position just to the surface. You donā€™t have the Speed By Surface + speed by greyscale enabled and that checker map do you? Those checks are small enough you might not get much motion before the particle stops on black.

#12

No I havenā€™t. I did notice something though. I think if i edit the speed and use the values i figured are working for my scene (e.g. 1.0m) they just seem to not move. But i think they do move, just very very slwoly. and because it is so slow, the script doesnt really go in, if you know what i mean.
Anyway: i will try again with several set ups. I might aswell try changing the multiplication in the script. I guess your scene is in inches - mine is in meters. so times 100 might not be enough (or to much). Since we now established that the script is in fact working it might just be some very weird number tweeking.
Iā€™ll tell you if i have made any progress, or if i officially surrendered and went to the madhouse instead.

#13

Progress! So as i feared, it really is a matter of system unit setup and the multiplier.
If i use your scene (inches) and merge my guy in, 100 is way to fast. multiplying by 32 does seem to give a fairly good result. But, and thats kind of annoying, it seems to only speed animation up, not slow it down. So if anyone walks slower than the base speed, he still walks in place (more or less). And this happens in both scenes. the inch and the metric one.
If I use the metric scale, i need to multiply the particle speed by 1000, not 100. then the faster particles are scaled just fine. Slower ones, as mention above, still walk in place.
here the links:
inch system. speed*32. Slow person in the left corner:
http://www.youtube.com/watch?v=KBQWlULb1-E

inch system. speed *100. Slow person again in the left corner:
http://www.youtube.com/watch?v=3HzFFR45pAc

metric system. speed*1000. Slow person in the right corner:
http://www.youtube.com/watch?v=G2Udr2M3RgU

Out of lazyness i did not hide the source mesh. So one person is always walking in place :wink: but he ainā€™t a particle.

#14

Yes my system setup should be in inches (or centimeters) It has a tendency to get muffed up on occasion because so many people use different system scales.

A thought may be to slow the walk cycle down to its slowest possible increment. My walk cycle is fairly slow.

#15

Hi Johnny,

Iā€™m not sure how stretching the walk cycle would solve the problem that the walk cycle isnā€™t stretched by the script, but iā€™ll give it a try. At the moment it seems as if the slowest possible playbackspeed would be the length of the source cycle.

#16

This is gonna be so good when itā€™s out!
Agent Crowd Contol:
http://www.geoffsamuel.com/Project_Files.php?proj=9

#17

I know, Iā€™ve seen it yesterday. Already asked a couple of questions :wink: Iā€™m especially interested in the animation part :smiley:
But until it does come out, I have to manage on my own. and iā€™m rushing towards a deadline :slight_smile:

#18

Well it was difficult for me to tell if it was actually going slower than the cycle I sued, since it was fairly slow already. I speed it up to check and it does indeed slow it down, I wasnā€™t sure if it was working correctly, ie a bug or something similar. It does work as expected.

You could throw in a Speed Test + Velocity Magnitude < 10 (or something), if the particle is moving too slow, recirculate back into the main influence event.

Event01+Speed Testā€“>Event02+Send Outā€“>Back to Event01

#19

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.