Jump to content


  • Content count

  • Donations

    10.00 CAD 
  • Joined

  • Last visited

  • Days Won


Everything posted by acey195

  1. Random link of interest

    Cool(hot) real-life lava reference
  2. How to practice and get good at Vex?

    I always have the documentation open on my second screen: https://www.sidefx.com/docs/houdini/vex/functions/index.html just to use ctrl+f to find a function related to the task I'm trying to do It also really depends if you are just new to VEX, or scripting in general, in case of the latter (and even in case of the first) we can always recommend looking at Tokeru's guide: https://www.tokeru.com/cgwiki/index.php?title=JoyOfVex
  3. blue "i" on nodes

    I guess its nodes that are "reference copies" you can make them by right clicking on a node, and then under actions edit: The reason you may want to use reference copies, is for when you want 2 nodes to behave exactly the same, but are in different places in your network. The difference with "normal" copies, is that it will also create parameter references for every controlling parameter on the node.
  4. Wrangle ch-slider standard value

    not sure how much help a .hip file is when trying to show you UI things if this is not "working" then I probably do not understand properly what you are trying to do, but here's the same steps with some visuals:
  5. Wrangle ch-slider standard value

    Yup go to edit the node's parameter interface. First check that the value range is not locked, its the small lock icons on the left and right side of the range, about 3/4ths down on the right side panel of the edit parameter interface window. Then go to the 2nd tab on the right panel (Channels), select the parameter you want to edit in the middle panel and type in the desired default value in the right panel
  6. VEX project to a nearest point in surface

    Hey The nearpoint() expression lets you find the pointnumbers of other geometry nearby. *If you instead want to get the closest location on the surface, you probably want to use the xyzdist() function. *Otherwise, if you want to get the position directly underneath (in a specific direction, no matter the angle of the other surface) you can use the intersect() function. https://www.sidefx.com/docs/houdini/vex/functions/xyzdist.html https://www.sidefx.com/docs/houdini/vex/functions/intersect.html
  7. Random link of interest

    For those who want reference for a liquid methane explosion, or are otherwise interested in rocketry. There's many angles, slow motion footage and commentary from someone who knows his stuff :
  8. Covid will delay H18.5?

    They are still working on it (currently) No idea about the release date though.
  9. Grouping unshared "in-line" edges

    Hey Just something I would do in a wrangle or group expression SOP // running over points: @group_entryPt = neighbourcount(0, @ptnum)==2; // then you just add a group promote, converting it to an edge group (with the checkbox ticked of only include complete entities (or whatever it was called, don't have hou open atm )) Edit: That should at least work for the single extreme edge-entry points. For the doubles and up, you probably have to do a bit more, but generally speaking, using the amount of neigbours of a point and the amount of vertices on a point together should work on "2d" geometry, I think but you may have to create the groups directly in vex, to avoid grouping unintended edges. But to avoid selecting edges on both sides of a corner separately, you would have to add additional logic (as soon as you allow those double-edge entry points) if its only 1 and 2 edges you probably can get away with case-by-case handling, if you want to go up to an arbitrary amount of edges, its just will have to get more complicated I guess
  10. Learn Processing before VEX?

    Yes and no. The stuff he teaches is indeed great and some of it will be transferable (at least the basic coding logic) However, the syntax of that language is quite different from Vex, and it would work the closest to Vex, run over "detail (only once)", which while valid for some purposes, is not the most efficient use of VEX. In this case using a Python SOP will be about the same speed, which is probably easier to learn (has more learning resources outside of Houdini) VEX is kind of designed to process existing data, rather than generating everything from scratch. (but note that it CAN do it) When VEX is run over "points" or "primitives", it acts more like a shader, executing exactly the same code for each of them, which allows multi-threading, unlocking its true power. Hope that helps!
  11. Creating smooth curve from imported curve geometry

    Hey, Welcome to Houdini! May I suggest using the convert SOP (converting it to third order NURBS) you may also find it useful to: use the facet SOP using the "Remove Inline Points" toggle and then play with the distance to remove some "oversampling" use the fuse SOP to merge nearby points in corners (to avoid having sharp corners using convert) resample with a large value for "Maximum Segment Length" to reduce the noise in your samples Or alternatively, you can also keep your geometry at polygons with the resample SOP, setting the "Treat Polygon As" dropdown to "Subdivision Curves"
  12. FBXoutput

    The easiest way is to use a python sop in a forloop, causing the renderbutton to be pressed. note that your node may have to be "unlocked", so having it inside a locked hda will require some additional work something along the lines of: #python code: hou.parm("../ropnet1/fbxnode/execute).pressButton()
  13. FBXoutput

    I thought it was mainly, so it would be able to save animations (using the time frame) but yeah you'll need some kind of looping structure, or shenanigans using the pre/post render scripts
  14. Vertex Point Order Issue

    Instead of poly extrude, you could try to use some work around using the "Skin" SOP, together with some copy/transform logic that way you inherently maintain the point ordering.
  15. [SOLVED] vex groups question

    Note that @ikoon's method is faster than the partition SOP at least in 17.0x and earlier, have not yet tested in later versions. Difference is of course going to be very small, but can make a difference on heavy geo
  16. For me it reaaaally depends what the end goal is. (Speaking from a Gamedev perspective) I would say #1 is not a trap, as soon as you know what you are doing, for me building something efficient right from the bat (using a lot of vex) is way faster, than building something with a lot of nodes, only to tear it all down later and rebuild it. Especially as you lose a lot of time, tracking all the attributes and stuff, and getting lost in a node network that is presumably larger, than it really needs to be Edit: basically give yourself some time to think of the general process/flow of the process beforehand, instead of diving headfirst into anything. Especially if you keep building on top of it, then it always turns into a mess I find. for #2 this is Only wrong, if this process is a step in the process near the very end. The earlier on in the chain of processes the system is, the more annoying fixing things by hand will be. In my experience spending an Hour of work on the procedure, that saves one second of hand edit, is almost Always worth it, if you sum up all those seconds of hand editing (and having to completely redo all the steps after. For example, an HDA that turns a triangle mesh into a quad mesh, has to work 100% of the time, unless you have specific manpower assigned to fix the results every time. (and I'm not going to myself ) for UI, the Houdini interface can do a lot with the basic stuff. The trick is to not have too many parameters to begin with, trying to make as many things as possible relative to each other (providing overrides for people who think they know better than you :P) but yeah, python created dropdown menu's are very nice to have in a lot of cases.
  17. Had the pleasure to meet him in person a few times, great person! For me whenever old school people get back into houdini (or when people look at outdated tutorials) and need to understand "stamping" I always point them to the following video: "Geometry Workflows in Houdini 16 // Jeff Wagner // Illume Webinar"
  18. xyzdist function check

    ok, had some time to actually at the file, what I suggested earlier should work for your case, since you are only checking the center of every primitive, once. So for the final code, I would just do this: int outPr; float maxdist = chf("radius"); vector outUV; //to use the range overflow of the xyzdist() you also have to query the primitive and uv for some reason string grp = sprintf("!%d", @primnum); f@test = xyzdist(0, grp, @P, outPr, outUV, maxdist + 0.001); if(@test<maxdist){ s@near = "close"; } with a lot more primitives, its going to be more costly of course, but probably still less than putting it in a loop. That said, with a very large amount of geometry, you may have to do the calculation in multiple steps, so not every primitive has to check Every other primitive, but just the ones that are close. Also, you could add an heuristic, resampling all primitives, adding a center point to all edges and check those first with a nearpoint() expression, then afterwards, doing the xyzdist() for all the remaining primitives. That way you could greatly optimize all the plots that have similarly sized buildings next to each other, as those points will in a lot of cases, nicely line up with the center of the neighbouring primitive in that case, if you are really afraid about performance.
  19. xyzdist function check

    Well, resampling will indeed increase the usage of RAM, and GPU if you are display it, but in terms of calculation, using nearpoints() is a way faster (lighter on the CPU) operation than xyzdist() Also, you could set your resample node's parameter "Create Only Points" (destroying the primitives for the calculation) which will greatly lower the GPU and a bit of the RAM usage. It of course matters, what kind of fidelity you need for this, if you really need 0.001m accuracy this method is of course not going to work. Though, there are certain work-arounds, like measuring the distance to the 2 closest points (instead of 1) and using some geometry math, to find out where along that edge, lies the actual closest position.
  20. about parallel processing in VEX

    the meta data block, (which you can generate with a button from the input of a foreach) will give you a detail attribute, with the current data its looping over "value", incase you are running over numbers as well as an "iteration" attribute, you can use in other cases. you can use those values, to make sure your wrangle fetches the right data/does the right thing, depending on the iteration of the loop. Also, generally speaking, putting everything in a single wrangle only gives you a very slight performance increase in terms of overhead, which is almost always outweighed, by the multi threading benefit you get from using multiple nodes. In addition, the overhead can be completely eliminated by using a compile block (which only really starts to make sense with larger numbers of nodes, or if you are taking the loop approach)
  21. xyzdist function check

    yeah looping over all primitives like this, even using groups is going to be very expensive. One optimization, is giving it a maximum search range (which will speed up the function a lot) if you have more or less similar expected distances. float xyzdist(<geometry>geometry, vector origin, int &prim, vector &uv, float maxdist) or float xyzdist(<geometry>geometry, string primgroup, vector origin, int &prim, vector &uv,float maxdist) https://www.sidefx.com/docs/houdini/vex/functions/xyzdist.html generally what I would do is: int outPr; float range = chf("range"); vector outUV; float dist = xyzdist(1, v@P, outPr, outUV, range+0.001); if(dist > range) return;//or continue if in loop Alternatively, if you are dealing with reaaaly large amounts of geo, I would suggest just resampling your primitives, saving the primitive number to those new points, and check the nearest points, instead of using xyzdist()
  22. Quads instead of triangles

    Or you could write your own quadrify node, with some wrangles/python and a dissolve node. What we did, was finding for every triangle, the longest edge (out of 3) Then, if a neighboring triangle has the same edge as its longest edge, group it. Afterwards you can just dissolve this group and you have a quite reasonable quadrify process. It will of course keep some triangles this way, depending on how have modeled the "joints" Also can't share the code unfortunately, but that could give you a start.
  23. about parallel processing in VEX

    In general, yes if you only really use point or primitive mode, if the order of processing is not important (or you compensate for it in another way, such as calculating the same data again in other points that need to access it, although this may lower the speed by such an amount that running in detail may be faster anyways) but there are other things you can do, like Skybar mentioned, or simply putting the wrangle in a for loop, potentially using the meta data block Also, don't be afraid to mix and match point and detail mode, and divide your code over multiple wrangles, so you can have the best of both worlds
  24. How do I skin connected curves?

    Not really using the polyExpand2d, you may also want to try the polyWire sop (and then flatten the result and removing the bottom) another solutions is putting a grid under it, making a distance field of the curve on the grid, and then use a clip sop based on this value (by transforming the height using the distance field) but this method creates an unaligned topology (which it sounds like you don't want)
  25. Python: Delete node

    instead of deleting, can't you just check if it already exists, and skip the creation if it already does?