michaelb-01 Posted June 29, 2014 Share Posted June 29, 2014 I'm hoping this is a very basic question and i'm missing something.. I'm playing around with writing some vex code to achieve self collision in a basic particle system and I was wondering what the best way is to iterate over all (other) points, i.e. if a connection (or check) has been made between point 0 and 1 it should then be re-made for point 1 and 0. Obviously this would simple in python or mel for example but vex is harder since its multithreaded? I've only just started looking at vex so i'm only half sure this is correct so far? I have a work around but is not efficient (I may be iterating over thousands of points) so maybe a python sop would actually be better?? Thanks, Mike Quote Link to comment Share on other sites More sharing options...
xray Posted June 30, 2014 Share Posted June 30, 2014 You could try testing for coincident or nearby points using the vex point cloud functions, but that won't solve your "previous connection" issue. Quote Link to comment Share on other sites More sharing options...
michaelb-01 Posted June 30, 2014 Author Share Posted June 30, 2014 Yea thats what i'm doing, and then I was thinking of adding a string attribute with the connections the point has (e.g. 12,4,25,42 etc.) and then getting this attribute on subsequent points, splitting it by the commas and check a conncetion already exists. But this doesnt really work since vex works in parallel... At the moment i'm creating a primitive between all nearby points found by a point cloud (ignoring any double connections) then using the clean sop to remove double primitives then iterating over the prims in an attribwrangle and getting the connected points, but this seems slow to me... Quote Link to comment Share on other sites More sharing options...
xray Posted July 2, 2014 Share Posted July 2, 2014 You could do the testing and string attribute creation of which particles are connected to which particles in VEX and then run it through a python SOP for your parsing and list splitting. Quote Link to comment Share on other sites More sharing options...
ikarus Posted July 2, 2014 Share Posted July 2, 2014 (edited) Why would you want to keep track of what particle pairs have been tested? If you're doing the detection/correction in VEX, each operation can only work on one point at a time anyway, your algorithm should result in the same output on both points of a collision. ie vex code runs on point A, finds B within the collision radius, applies correction to A based on B, then vex code runs on point B and would result in the equal (but opposite) correction from A. Edited July 2, 2014 by ikarus Quote Link to comment Share on other sites More sharing options...
michaelb-01 Posted July 2, 2014 Author Share Posted July 2, 2014 Thanks for the response Raymond. I was just thinking of efficiency really but maybe i'm completely missing the point, i'm still pretty unknown to VEX and spring-mass systems (but keen to learn). You don't happen to have any example hip files for this? I know it's pretty basic stuff but i'm a bit stuck. I've been following this tutorial (http://paulbourke.net/miscellaneous/particle/) and my system sort of works but when you add more particles it starts to lose control and keeps expanding and not conforming to the rest length - I don't yet have a breaking threshold for the springs, and i'm not re-evaluating the restlength which may be an issue? Here's my file (how do you attach a file??): https://dl.dropboxusercontent.com/u/18098614/basic_solver_v9.hip It would be incredible if you could find a few minutes to have a quick look through it. I'm not using pops, just a basic solver in sops and some variables are set on their relevant nodes (i'll make a proper ui with all the controls soon). Thanks, Mike Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.