hi, I am looking at help file on pop creep example, and found creep does actually change pstate.
and I have came across the following two threads, whcih seems the different pstate will have different attribute, property acts (inc force?) on pop
so, what does those two state means and what they are?
pstate 32768 (sliding splash example)
pstate 16 (turn pop creep stuck to 1)
http://www.sidefx.com/index.php?option=com_forum&Itemid=172&page=viewtopic&t=20805&highlight=pop+creep [sidefx.com]
http://www.sidefx.com/index.php?option=com_forum&Itemid=172&page=viewtopic&t=17326&highlight=pstate [sidefx.com]

please help, thank you in advanced

So as far as I've been able to discern, the particle state codes are as follows:

0 = normal
2 = dead
4 = stopped
8 = just hit
16 = stuck
32768 = sliding

Turning these on one at a time with the State POP will yield the numbers above, but turning on multiple states actually adds them together. The function of this is so you can have sleeper states, like if a particle is sliding AND stuck, when it becomes unstuck it starts sliding again rather than flying away. The numbers are powers of 2 in order to be able to preserve multiple states, i believe this is called a bitmask(?). That said, I have always wondered why there are so many missing states between stuck and sliding.

So, you could manually turn these things on and off with vops, but it's a hell of a lot easier to do it with State.

wao, thank you Jesse for your time to post this, it is very helpful and clear to me now.
Am I allowed to follow up a question as how would you know which property works under different state, as jeff mention in above post.
It seems obscure for some properties under certain states.

thank you

Here is a couple of more.

http://www.sidefx.com/index.php?option=com_forum&Itemid=172&page=viewtopic&t=9839& [sidefx.com]

Thank you wolfwood for putting up that information.
Actually, I did came over that post before I asked.
I am not familar with api or c++ stuff, thus when I saw that number behind state, I thought it was memory address ??
Think I am wrong, if thaken out the ox code from number, it seems represents the pstate number.

it's the hexadecimal representation of the state code
http://www.numberplanet.com/number/8000/ [numberplanet.com]

jorosy
Thank you wolfwood for putting up that information.
Actually, I did came over that post before I asked.
I am not familar with api or c++ stuff, thus when I saw that number behind state, I thought it was memory address ??
Think I am wrong, if thaken out the ox code from number, it seems represents the pstate number.

They are just numbers. Pstate is handled with a bitmask.

http://en.wikipedia.org/wiki/Mask_(computing) [en.wikipedia.org]

The decimal representation of pstate hides all the neat stuff going on. If we look at it in binary we'll see a different story.


DYING
0x0002 (hex)
2 (decimal)
00000010 (binary)

STOPPED
0x0004 (hex)
4 (decimal)
00000100 (binary)

COLLIDE
0x0008 (hex)
8 (decimal)
00001000 (binary)

STUCK
0x0010 (hex)
16 (decimal)
00010000 (binary)


So if you want to have particle that has a shared state, say it just collided and is now marked for reaping (dying) you could have a dual state.

00000010 (dying)
OR 00001000 (collide)
= 00001010 (dying and colliding)

(or in decimal 10)


Why is the handy? Cause you can use logical operators to quicky get info.

Using the example above, I want to know if my particle is colliding, then you can do.

00001010 (your particle)
AND 00001000 (colliding state mask)
= 00001000 (non zero, thus TRUE)

So yes, your particle is colliding.

Another example, lets test if the same particle is stuck.

00001010 (your particle)
AND 00010000 (stuck state mask)
= 00000000 (zero, thus FALSE)

In this case, your particle is not stuck.

Looking at the numbers this way makes using VOPs to check for various particles significantly easier and faster.

that's why it's called bitmask
thank you Wolfwood for posting this
i didn't think about it in binary form, it's all making sense now

tamte
that's why it's called bitmask
thank you Wolfwood for posting this
i didn't think about it in binary form, it's all making sense now

Yea bitmasks can be quite handy. Sometimes I'll use them to speed up instancing. The more material overrides you have the slower instancing can become, so I'll collapse a bunch of toggles down into a single bitmask then override just that one parm. So 8 evaluations become just one, which has some impact when instancing 100,000 things.

Plus, artists love bitmasks!

(sorry, couldn't resist)

Wolfwood
Yea bitmasks can be quite handy. Sometimes I'll use them to speed up instancing. The more material overrides you have the slower instancing can become, so I'll collapse a bunch of toggles down into a single bitmask then override just that one parm. So 8 evaluations become just one, which has some impact when instancing 100,000 things.

nice trick, however, there should be something done with the instancing speed, it's not funny when ifd generation takes longer that render itself, I hope speed increases are comming

btw: how do you use that mask? do you convert it to binary in VEX?

SanQ!

thank you wolfwood for putting such clear information. Thank you