Leaderboard

Hi all I am posting a simple procedural desintegration that is very fun to build, as always, with quaternions and vex. Vex is annoted, Hope you will like it. There is a line in vex where i remap a random quaternion [0, 1] to [-0.7, 0.7]. It roughly removes the random overlapped orientations. If you disable it you can see that orientations are a bit biased because of the 0 - 1 range. Update : Now with RBDs lego_desintegration_RBD_001.hiplc

I'm not much chops in DOP so did it in SOP vu_VellumInstancing.hipnc

Midnight recording on how to do a basic texture bombing shader: https://www.youtube.com/watch?v=sUkyHbSocUE texture_bombing_shader.hipnc

Thanks, that's exactly what I was trying to accomplish! I did go back and find a way to do it in DOPs if anyone else is interested. VellumInstancing_02.hipnc

Hi, this example shows you how you can get impact points after simulation with bullet solver. This method you can use with classic animation. Since you already managed to get the points just use solver sop only. dop_import_records.hipnc

check hip file vellum 2.hip

hi - check the file - it may be useful .. but you can make your own behavior.. vellum.hip

Dear nuki Thank you advice. You are right , uv is over 0-1. so , fixed ad type : polygonmesh , and adjust uv 0-1 , it went well. Thank you good solution!!

Hey Ballington, Its been awhile since I have worked with this stuff. I have successfully gotten a leaf venation system to work, building off of the efforts of those who have gone before me. It turns out, the most efficient method to get you started with leaf venation is a reuse of the space colonization algorithm showcased here: Now i guess it depends on what your goals are. I wanted to make realistic veins for texturing displacement. Using seeds to randomize the result. This is quite possible. Ive attached some picks that show the system working based off entagma's code. There is a problem though. The algorithm is not intelligent enough to organize the resulting geo in a logical manner. Its a madhouse of prims and points, trust me. Thats where you come in. You need to create a logical system to help with the creation of geometry itself. First, you need a generational pattern. Main stem, first gen, next stem, second gen etc. Ive attached a pick that shows the logic of this process. Once you have a generation setup, you can loop through each generation using connectivity, and create a a width attribute along each 'vein' this will be what drives the size of each vein when you actually add geo. Ive shown some picks of a nice result. You can then literally project this geo onto a heightfield and export a displacement texture. Now its challenging and there are all sorts of loopholes along the way. I wish I could show you the code, but its not soemthing I am allowed to share. All the best mate!

Connect the bind uv with a bind export, and of course export always the uv attribute. You also need to add an "aov" or Extra image plane in the mantra node. Set it to vector and VEX variable to be uv.

@density = volumesample(1, "density", @P); v@v = volumesamplev(1, "vel", @P);

attribfromvolume does that.

Hey, I just wanted to add to this for those looking at this type of thing. For this to work correctly the setup is specific. Using wrangles is the easiest. Lets say there are 2 objects. A falling box and a floor sitting horizontally. Both of these need to have a "collisiongroup" assigned to them. So for this we will call them box1 and floor1. For box1 to ignore collision with floor1, both object streams need to have "collisionignore" specified to them. So more clearly, box1 would need collisionignore to be set to floor1 and floor1 would need to be set to box1. This way both objects are aware of the other. This is based on a setup where these objects are both being piped into a single rbdpackedobject node in the DOP. If box1 is set to floor1 but floor one has no setting for any collisonignore objects. The default will be a collision. A bit involved but it worked for me. s@collisiongroup = "floor1"; s@collisionignore = "box1"; s@collisiongroup = "box1"; s@collisionignore = "floor1"; The syntax for the objects added is similar to the syntax in the group field of most nodes. So space to separate multiple objects and "^" to exclude objects. Even wildcards will work, "box*". The docs describe this but until try to set it up you discover all of this. I hope this helps the next person.

I found the piece of code that i was looking for to modify the algorithm in the creation stage. I asked for a "post" solution at first because i knew some side fx would come along, but now i got everything under control. My code generates one prim at each iteration, the advantage of this approach is that i can separate the various branches in chunks after the creation stage. That's what i do using a FuseSOP set to Unique, acting only on a group of points ("primchunk_node" group). This primchunks are used later for the "flip/unfold effect". F1 code is much better optimized since it creates only one primitive per branch. But in this way i can't separate them afterwards, or at least not with the FuseSOP/Unique approach. I modified the code to create one prim also for each primchunk_node. The only downside is that while tweaking the unfold effect, if i want to change the primchunk distribution i have to re-run the solver. Thanks for helping once again! ///Original - Primchunk selection after solver int new_pt = addpoint(0, newP); int new_prim = addprim(0, "polyline"); addvertex(0, new_prim, @ptnum); addvertex(0, new_prim, new_pt); ///F1's - Primchunk selection in solver int new_pt = addpoint(0, newP); if (neighbourcount(0, @ptnum) == 1 && !@group_primchunk_node ) { // Add new point to existing polyline. int new_prim = pointprims(0, @ptnum)[0]; addvertex(0, new_prim, @ptnum);//addded addvertex(0, new_prim, new_pt); } else { // Create new generation. Seed case + branching nodes + primchunk nodes int new_prim = addprim(0, "polyline"); addvertex(0, new_prim, @ptnum); addvertex(0, new_prim, new_pt); int old_prim = pointprims(0, @ptnum)[0]; int new_branch = prim(0, "branch", old_prim) + 1; setprimattrib(0, "branch", new_prim, new_branch); Attached you find the project im working on, I started from a already done space colonization algorithm. I customized it and worked mainly on the post solver effects to randomize growth speed and other attributes, and on the unfold effect. I will publish a cleaner network, when ill be done! If you have any question feel free to ask space_colonizer_v11.hip

I have a simple space colonization with post-solving setup. It may be a bit unclear what is going on inside loop without digging in it, but you may visualize attributes and see if they are what you need, then try to make your own version, or just grow a new tree with same look. spacecol.hipnc