Welcome to od|forum

Register now to gain access to all of our features. Once registered and logged in, you will be able to contribute to this site by submitting your own content or replying to existing content. You'll be able to customize your profile, receive reputation points as a reward for submitting content, while also communicating with other members via your own private inbox, plus much more! This message will be removed once you have signed in.


  • Content count

  • Joined

  • Last visited

  • Days Won


Community Reputation

49 Excellent

About iamyog

  • Rank

Personal Information

  • Name Anthony Arnoux
  • Location London

Recent Profile Visitors

3,251 profile views
  1. disregard notes given in dailies ?
  2. not to whine but there's an answer without copy stamp in your other topic:
  3. assuming you have pieces neatly separated, kind of what a voronoi fracture would output you, you can just pack via an assembleSOP (check "create Name attribute" and "create packed geometry"). This will give you one packed primitive per piece and thus one point. You can manipulate them as you need via the intrisic attribute "transform" A point wrangler running this code should get you on the tracks. float _seedpiece = rand(@ptnum); // multiplier per piece float _seed = fit01(_seedpiece, 0.5, 1); // unique rotation speed multiplier float _startframe = ch("startframe"); float _fadeout = ch("fade_out") * _seedpiece; matrix3 _m = ident(); // initial transformation matrix float _angle = (clamp((@Frame - _startframe), 0, 1000) * _seed) * ch("speed"); vector _axis = set(rand(@ptnum + 1), rand(@ptnum + 5), rand(@ptnum + 9)); // random rotation acix _fadeout = 1 - fit(clamp(@Frame - _startframe, 0, _fadeout), 0, _fadeout, 0, 1); vector _scl = set(_fadeout); rotate(_m, _angle, _axis); scale(_m, _scl); setprimintrinsic(0, "transform", @ptnum, _m);
  4. a VEX solution int ls [] = array(); if (inpointgroup(0, "in", @ptnum)) { ls = neighbours(0, @ptnum); for (int i=0; i<len(ls); i++) { setpointgroup(0, "neighbours", ls[i], 1); setpointattrib(0, "Cd", ls[i], {1,0,0}); } }
  5. I cannot download your file (.rar) but you can try using a divideSOP with Remove Shared Edges activated, then delete any primitive that has an area above a certain threshold: in a primitive wrangle: float measured_area = primintrinsic(0, "measuredarea", @primnum); if (measured_area > ch("th")) removeprim(geoself(), @primnum, 1);
  6. Open thought after wandering a bit on the Discord channel: A search function is said to be coming on Discord but I cannot see how it can compete with a good old search that returns a full-of-info post from years ago on a forum. Discord brings more chats on the moment, with solutions for the person asking, not lasting more than a few lines and lost forever. And yes I know about pinned post. Many "easy" questions would find an answer with a simple search on odforce/sidefx but users are more likely to simply ask. Forums tend to create rather richer discussions, showing different approachs, hip files, fancy gifs and the occasional [insert_houdini_guru_name_here] genius idea. Some topics are even brought from the dead months/years later and completed with up to date informations. I can hardly see Discord having a similar depth of knowledge after a few years. Also, I'd happily refresh odforce during a work day, waiting for a cache. Topics are organised and you can easily read what you are interested into. Discord is harder to catch up as it can go into many cross discussions within the same channel (#hou-effects can encompass a lot of things) and I'm less willing to spend my work day reading a chat. Muting #lounge is not enough. I've got nothing against a Discord channel, it does not serve the same purpose, but I hope it will not drag quality content out of the forums. Closing thought: seems like I'm gently knocking to the old geezers' door
  7. primuv() should do: http://www.sidefx.com/docs/houdini/vex/functions/primuv
  8. You can have velocity where you have no density. DOP networks are using Houdini volumes so all fields should have the same dimensions and "weight", I mean, filesize. Since you convert to VDB you are scrapping out useless voxels. If you have the situation described above, each VDB cached field would have a different filesize, well, at least for density and vel. vel.x, vel.y and vel.z should be have the same file size since they are all part of the same original field. To import a field from a DOP network, use DOPImportField rather than a DOPImport. if you want to double check which voxels will be stored: after your VDB conversion, add a blastSOP and keep only one of your field then lay down a VDB Visualize Tree where you change the Active Voxels dropdown to Points. Depending on which field you keep in your blast SOP you might see more or less points. More points = more voxels = more Mb to store.
  9. I'm not sure about what you are trying to do ? the foreach is behaving as expected, you've got access to each set of connected primitives at a time. If you want to work on the whole "asset" (just confirming we are talking about 'torus + boxes' or 'boxes + spheres', anything coming out of the ASSET_MDL) you have to define your class attribute per asset, not per set of connected primitives. Add an attribwrangler set on primitive mode before each one of your black nulls and define a class attribute manually per asset: @class = 0; // or @class = 1; etc, But in that case I don't understand why you want to go through a foreach approach and not do your operations before the merge.
  10. I do not actually have an answer but just wanted to share a thing: I'm not sure the lost of precision is coming from the conversion from string. if you run @base = 123456789; @div = pow(10, 9); @RESULT = @base / @div; RESULT will return 0.1234567 instead of 0.123456789 not sure where to go from there though.
  11. in an attribWrangle: vector _ndc = toNDC("/obj/cam1", @P); float _errorx = ch("errorx"); float _errory = ch("errory"); float _errorz = ch("errorz"); if ((_ndc[0] < 0 - _errorx) || (_ndc[0] > 1 + _errorx)) removepoint(geoself(), @ptnum); if ((_ndc[1] < 0 - _errory) || (_ndc[1] > 1 + _errory)) removepoint(geoself(), @ptnum); if ((_ndc[2] > 0 + _errorz)) removepoint(geoself(), @ptnum); update the path to your camera, then set your error margins accordingly
  12. Since you plugged ptnum into the length of "for_begin1", I believe you are misunderstanding how the for loop works in an AttribVOP. An attribVOP, or a attribwrangle set on anything else than detail mode, will process all of your points at the same time through all the cores available on your CPU. It is NOT a linear iteration through all points. When you plug ptnum into the length input of a for loop, you are actually telling the attribVOP to loop for ptnum'th times. The way you connected your nodes means: - For point 0, please loop 0 time. - For Point 1, please loop 1 time and import the Pstate attribute where ptnum == length (import Pstate from point 1) - For Point 899, please loop 899 times and import the Pstate attribute where ptnum == length (import Pstate from point 899, but do it 899 times...) Regarding the snippet2, the constant is just a blank attribute created outside the snippet that I then fill with the correct point number value. When you plug a constant in a snippet, it generates the corresponding output for you (try it by yourself). I'm using this output for the rest of the loop. If I did not plugged the constant pt_to_process in, I would have had to use either the row_point array or the iteration attribute blue arrows ouputs to carry on my loop. Since I want to keep them clean for their own purpose, I created the constant and used it to ouput the data I needed. pt_to_process does not fetch anything, it is just a placeholder created before where I store the correct data I've found.
  13. couple of things: - did you specify which input to read in your volumeSampleFile1 ? Either change the input dropdown menu to Second Input, or connect Opinput2 to the filename, or promote the parameter and fill the path appropriately - make sure the output type is set to SDF Volume on the isoOffsetSOP - do not use addAttribute. From the doc: https://www.sidefx.com/docs/houdini/nodes/vop/addattrib Just replace it by a bindExport. - Finally... last but not least, you are trying to find the depth of each point of the sphere. They are by definition on the surface of the sphere. That means you should have the same value for all points: 0 = on surface. You will however see the depth attribute with values >0. This is because your are sampling a volume that is a representation of your sphere. The higher the resolution of your volume, the closer the depth attribute will be to 0, and the opposite.
  14. full disclosure: I've no idea how to recreate this in an AttribVOP without using VEX in a snippet... I find arrays to be kind of a pain to deal with in Houdini. Possibly by a lack of knowledge on my side. I think I remember reading there were updates on that, but in the past you could not really save an array as a point attribute. I'm usually using the technique where you convert the data into a string, saved as a string attribute per point then converted back into int/float values after. It works but it's not handy to use. Not even talking about multi dimension arrays. Since the new array change, I never had to deal with heavy array things to store as attribute so I did not wrap my head around yet. I should. Back on the topic, you are painting a Pstate attribute and try to use this as an input for the loop. You declared Pstate as an int array, but if you check the Geometry Spreadsheet (protip: ALWAYS have this open to check what's happening), you will see Pstate is actually empty. Into AttribVOP, since the array is empty, arrayLength will return 0 and the loop will never iterate. snippet2 is easy: pt_to_process = row_point[iteration]; I feed a constant called pt_to_process in which I will save the point number I want to work on for this loop iteration. row_point is the array containing all the points that I want to be considered. This is basically the content of snippet1 iteration is the index of the loop iteration. row_point could be written as [id] [value] [0] [464] [1] [258] [2] [211] First loop iteration, index == 0 so the code output 464 in pt_to_process 2nd loop iteration, index == 1, the code output 258 in pt_to_process etc.. hope it makes sense. edit: not sure what's wrong with the white patch, I got colours:
  15. for multiple points, you need a second loop. First loop to identify which point you want to find the neighbours Second loop to actually find the neighbours and colour them I'd say you're starting to see why AttribVOP is a good thing to hide the scary code to beginners but it quickly starts to be really convoluted to do a simple double loop. I added a VEX solution that does the same job in a few lines, much simpler to debug than a web of lines between nodes in AttribVOP. At least in my opinion. I'd suggest suffering a bit at the beginning but it's definitely worth spending the time to learn VEX. Not sure what you mean by the white patch, the grid is indeed coloured in white where neighbours are found. Edit: even better, if you paint an attribute on points, you can run your AttribWrangle in point mode, which means multithread and save you one loop as you have it for free. Won't make any difference in your scene but try to run the same thing on a multimillion points mesh and it'll be pretty obvious. see file v3 VOP_Neighbour_Colour_change_odforce2.hipnc VOP_Neighbour_Colour_change_odforce3.hipnc