Hey,
Seems that magnitude of the force in POPs is proportional to 1 / Oversampling (I mean not value at current sample but actual magnitude which user set). I'm not sure about all forces in POPs but this is correct at least for Fan POP. Try to put Fan POP and turn on Show acceleration guide flag and you will see. Could you clarify is it bug or feature. Looks weird… H9.0.734
I've tried H8.2 and it works as supposed - force magnitude isn't dependent on Oversampling.
POPs, oversampling and forces... Bug or feature?
6894 10 2- hoknamahn
- Member
- 398 posts
- Joined: July 2005
- Offline
- hoknamahn
- Member
- 398 posts
- Joined: July 2005
- Offline
- hoknamahn
- Member
- 398 posts
- Joined: July 2005
- Offline
- wolfwood
- Member
- 4262 posts
- Joined: July 2005
- Offline
- Ondrej
- Staff
- 1072 posts
- Joined: July 2005
- Offline
hoknamahn
Try to put Fan POP and turn on Show acceleration guide flag and you will see. Could you clarify is it bug or feature. Looks weird… H9.0.734
The length of the acceleration guide does account for the size of the time step. The more samples, the shorter the time step, so the smaller the impact of the applied acceleration during that time step.
I don't see anything wrong here, or with the example file you provided.
- hoknamahn
- Member
- 398 posts
- Joined: July 2005
- Offline
I understand that fact that force in current time step should be equal to magnitude divided by oversampling but don't understand why final look should be different. In that scene the magnitude is proportional to oversampling (I mean final effect) - more samples - bigger magnitude. But I expect to see result which is not dependent on samples (I mean overall magnitude of force should be the same or close enough). This is one weird thing. But if you turn on a visibility flag on… for example fan1 pop and play with oversampling effect will be completely different: more samples - smaller magnitude. Probably there is some logical explanation for these side effects? :?
f = conserve . diffuse . advect . add
fx td @ the mill
fx td @ the mill
- Ondrej
- Staff
- 1072 posts
- Joined: July 2005
- Offline
- paul
- Member
- 832 posts
- Joined: July 2005
- Offline
- hoknamahn
- Member
- 398 posts
- Joined: July 2005
- Offline
- hoknamahn
- Member
- 398 posts
- Joined: July 2005
- Offline
- old_school
- Staff
- 2540 posts
- Joined: July 2005
- Offline
All the default POPs do this.
If you are writing your own VOPs, nope. I want that control. Just like in shader writing, you have to manage some things yourself when writing POP tools. With a POP vex tool, you manage the velocity and acceleration with regards to the time step increment. If you incorporate CHOPs, you should also resample the channels to the same particle oversampling rate. Same goes for other data that you bring in to your particle sim.
I sometimes change the playback rate to match the oversampling so I can step through each timestep and see what is moving constant, linear and smoothly between frames. Doing that makes the insantaneous velocity vectors back in line with your playback.
If you are writing your own VOPs, nope. I want that control. Just like in shader writing, you have to manage some things yourself when writing POP tools. With a POP vex tool, you manage the velocity and acceleration with regards to the time step increment. If you incorporate CHOPs, you should also resample the channels to the same particle oversampling rate. Same goes for other data that you bring in to your particle sim.
I sometimes change the playback rate to match the oversampling so I can step through each timestep and see what is moving constant, linear and smoothly between frames. Doing that makes the insantaneous velocity vectors back in line with your playback.
There's at least one school like the old school!
-
- Quick Links