Jump to content


  • Content count

  • Donations

    0.00 CAD 
  • Joined

  • Last visited

  • Days Won


Everything posted by riviera

  1. Hi, (Sorry if this kind of question was asked before) I'd like to set up a flip fluid in a fashion similar to naiad's, where the particle density can be set up separately for the surface and the volume of the fluid. (See attached image as an example) Now, the generation of this is pretty obvious, but I'd like the flip solver to behave as if the in-volume particles had a bigger scale or radius (so I'd need less particles to fill the same space). I tried to adjust the pscale attribute of the inner particles, but that doesn't seem to affect the solver. Any ideas would be appreciated... imre
  2. qLib Plugin Installation?

    Hey man -- I think these very same instructions are described in the README file for qLib. Btw, please don't use the version 0.2.5, it's _very_ old -- use the "dev branch" thing. cheers
  3. Delta Mush

    seems like delta mush is all the rage these days -- https://vimeo.com/103717638
  4. Delta Mush

    That's a cool idea... Although I was aware of the "reference geometry" input of the Edit SOP, I always felt that there should be something similar, but more general-purpose, in terms of "surface space" editing. So, having this in qLib scratches more than one itch, so to speak. (I couldn't have guessed that it could be done using a simple Edit SOP, though ) What you can find right now in qLib: - there's a gallery item ("Point Wrangle: delta mush utility"), which is a PointWrangle SOP preset, containing the necessary math for converting to/from "surface space" (or whatever you'd like to call it) - gallery items for smoothing/relaxing geometry (a pointcloud- and a topology-based one), and there's a Smooth Points qL SOP that wraps it all up in a single node - a "Displace by Delta qL SOP", implementing delta mush as a single node Having a single-node delta mush is fast (all is packed inside a single VEX block), but we're also planning to have a capture/deform pair implemented (to allow for more in-between trickery), as this is pose-based deformation territory, where many interesting things can happen. --- Yes, the actual math behind delta mush is pretty easy. It is not the math, but the effort it took that matters, though -- the time they took experimenting and (production-) testing, and concluding "hey, this works!" This is what we all got from it, not just the deformer math.
  5. Water inside of air field

    Hi -- I got really curious and ran my first very simple tests: https://vimeo.com/95335273 https://vimeo.com/95336414 (vimeo is still processing them but hopefully they'll work ) One probably couldn't get simpler than I did: every random 4th (or 2nd) emitted particle is "air" instead of water (so I'm basically emitting a water/air mixture). Even with this simpleton setup, the results look much nicer. (Fliptank tests also looked promising. I'm planning to do a cgi re-creation of Prometheus' title sequence waterfall scene for some time now, and this technique seems like a must-have for that...)
  6. Houdini UI Python Library

    Very nice! Cheers! (Also, the function you use, hou.ui.createDialog() doesn't seem to be documented anywhere in the 13.0 docs, so your code is extra useful...)
  7. L-system Local Variable (g vs t)

    There is a subtle but important difference. There are probably better L-system experts than me, but hopefully I won't spread misinformation here... First thing to know is that (at least this is what I concluded) for each letter in the generated L-system string, Houdini seems to store the number of iteration when the letter is added to the final string. So Houdini knows when each letter was generated. Now, the difference between g and t is that one refers to this stored iteration value, the other refers to the current iteration value (I don't recall which is which, though). I ran into this when I wanted to build a tree, where for the first few iterations only the trunk was created -- with letters in it that started to grow branches after a given generation count (so instead of growing a tree with shorter branches at the top, I wanted equal-length ones, hopefully I'm making some sense here...). In other words, I wrote a rule to expand the branch letters after the L-system ran for say 10 iterations (that allowed only the trunk to grow.) It could be done using one of the letters (g/t) but not the other. Don't remember which but it takes only 2 tries to find out. L-systems can be mind-bending, and there are some features that not even documented or just hinted in the docs. (I really wouldn't like to spread stupidity, though, so please anyone correct me if I'm wrong. This was quite some time ago.) cheers, imre
  8. Colour codes

    You're welcome, no big deal. In the meantime I took a look at this OnCreated.py -- here's my take on it, a minimalistic version, just by node type. I found that although on SOP level one is better careful about coloring, it can be quite the opposite on the OBJ level (probably because there's much less node types to choose from). Right now I find very helpful to color objects, lights and cameras differently. (This might change, though ) cheers OnCreated_py.zip
  9. Alternative to Fuse SOP?

    I recently tried to do a fuse on a 60mil points point cloud to get rid of duplicates, and after running on one thread for ~15 mins it started to eat up all 64gigs (!) memory of my work machine. So it can be risky with heavy geometry. Perhaps the process could be speeded up by a VEX-pointcloud preprocessing that finds duplicate points and group them. The run the Fuse SOP only on that group.
  10. Colour codes

    As an opportunity for another shameless plug, qLib comes with galleries that are basically regular Houdini nodes with some similarly customized interfaces. This is a regular Null SOP that provides information about its input geometry (also has auto-naming buttons). You can link those bounding box parameters on the Null to initial boundaries of a pyro sim to have a really fitting initial container, for example. ...or you can just go really nuts and roll an "align geometry" operator from a single Transform SOP: https://www.facebook...598018626898592 Very useful. (Although not strictly color-coding, but at least it's user interface-related )
  11. Colour codes

    I know I'm going to lose lots of $$$-s, but I'll tell it for free You can add buttons as spare parameters (Edit Parameter Interface...), then use a one-liner callback script (python) like: hou.pwd().setName("DISPLAY"); hou.pwd().setColor(hou.Color((0,.4,1))); hou.pwd().setDisplayFlag(True); [/CODE] or [CODE] hou.pwd().setName("RENDER"); hou.pwd().setColor(hou.Color((.4,.2,.6))); hou.pwd().setRenderFlag(True); [/CODE] or [CODE] hou.pwd().setColor(hou.Color((.8,.8,.8))); hou.pwd().setName("OUT"); hou.pwd().setRenderFlag(True); hou.pwd().setDisplayFlag(True); [/CODE] This is for DISPLAY, RENDER and OUT, accordingly. Once you added all buttons of your liking, you save the parameters as defaults ("Save as Permanent Defaults"). I have quite a few operators where I added some extra interface for convenience (for example my Object Merge SOP has a button which auto-names the SOP based on the name of the geometry that is merged). cheers
  12. https://www.facebook.com/photo.php?fbid=538053919561730 https://www.facebook.com/photo.php?fbid=538567726177016 cheers
  13. Colour codes

    ...and now for something not entirely different... This is how my Null SOP's default preset looks like: These buttons are one-liner python scripts which rename and colorize the Null accordingly. So I never type "OUT", I just click. ) I color "display" nodes to blue (same as display flag color); OUTs (render outputs) are purple (same as render flag color), animated ones are yellow, "waypoints" (important network points marking end of a section) are red, and that's about it. ("export points", e.g. where I fetch data from to other networks are green) I'll check out this OnCreated.py script, I didn't know this functionality existed. I wish it was documented... A word of warning: don't go too crazy with colors, or else you end up with networks that drive you crazy because they look like rainbows, and you lose what you thought you'd gain. This is an actual production network (hence a few dead ends ), IMHO this is the amount of coloring that provides relevant information without polluting everything with colored candy )
  14. In Maya there are camera parameters (which affect the viewport only) that allows you to pan and zoom on the view if it were a 2d image (and it won't affect your camera render frustrum). The tool you're talking about adjusts these parameters based on the user's mouse inputs in the viewport. The closest you can get to this in Houdini by adjusting the Screen Window X/Y and Size parameters (and reset them before you render, as they do change the camera frustrum AFAIK). But I don't think there's an interactive tool for that so you have to tweak these in the camera parameter panel. Such a tool would be very useful sometimes, though. (Another thing I'd like to have is a "dolly-zoom" camera tool. 3dsmax has it and I wrote one for myself back in my Maya days, but I don't know how to do it in Houdini.)
  15. BulletSOP 2.0.9

    Do you accept bug reports from people who buy the source? Some kind of maintenance plan perhaps, even? :DDD (just kidding) Anyhow, sounds like a great thing!
  16. Retiming Particle Sim

    I can even provide some explanations on the various aspects of particle retiming if anyone's interested. (Although hopefully everything's explained in the qLib example scene -- look for the "Timeblend qL" one)
  17. Retiming Particle Sim

    I know I'm spreading the shameless advertising of our asset library qLib all over the place, but it happens that we worked at the issue of particle retiming to quite some extent. I'm at work right now where we have limited facebook access, so I can only post the github address: http://qlab.github.io/qLib/ -- but if you check our our page on facebook (especially the "photos" section), you'll find screenshots with related explanations about how to retime particles using qLib tools (there are various example files in the distribution, too). (For instance, check this video: . This is an animated boolean, 20 frames long, slowed down with a 10x factor or so. It's an actual example scene that covers various ways of proper sub-frame emission, death, subframe-accurate age attributes and attribute mapping.)cheers )
  18. We also reported this and sesis answer was that it doesn't work because of some internal evaluation inconsistency, so they're removing it (!), and we should use the centroid() function instead. While our first reaction was righteous outrage (kidding :-D) we realized we always had evaluation problems with these variables, especially when used in digital assets. so we switched to centroid() since then. A hint: $GCX Y Z variables still work, so use that when not in the mood for much typing. Just don't tell the sesi guys :-D
  19. Just an idea--if you add color attribute to a guide geometry, the guide geom will be drawn using those colors (instead of the default guide color). So, you might achieve similar results by creating colored particles for all your geometry points, and use that geometry as a guide. (I hope I'm making sense here...) Not the exact same result, but might be close. (I'm talking about the guide geometry within a SOP asset, of course )
  20. qLib v0.1

    True enough-- those webs were generated using a spiderweb asset which would fit very nicely on Orbolt. Jokes aside, the issue here is that it relies heavily on qLib assets, so I'm not sure how to proceed here. (Believe it or not but when Orbolt came out, we had a lengthy discussion on how to fit qLib into the Orbolt "way of things". Should we _move_ to orbolt? [no] Should we upload to orbolt? [yes] We have almost a hundred separate asset files, should we upload them one-by-one or should we collapse all our assets to a single .otl file? [neither] etc etc.) Needless to say, that discussion has _not_ reached its conclusions yet. I'm not sure if it's allowed to upload assets to Orbolt that rely on other assets (that are freely available but not necessarily included). So we're not really sure on how to proceed -- although we would like the idea of uploading finished high-level assets to the store ("we" meaning everyone involved in qLib, me being the one who happened to build the web asset). Imre ps.: Btw, there's actually a spiderweb example scene in the qLib distro (not the same as the asset, though, but using a different approach)
  21. Hi, Right now I'm checking out what's going on with the various variants of HOT available (since we need to have to have it working -- and having identical results! -- both in Maya and Houdini). Okay, so I'm still looking at the available Houdini variants, and there's the original one by Drew Whitehouse, and the multithreaded one by Chris Schnellhammer. I compiled both and found the following so far: - The two variants don't give the same results (Chris's version has an additional parameter called "Largest Wavelength", and I'm only getting _almost_ identical waveforms if I set that to about ~91.75 or something) - Chris's version is somewhat faster, but not that much overall, at least on our machines (gives a ~2x speedup on 16m points in multithreaded mode, the speed difference is negligible on light geometry), but this might be due to other issues (*) Obviously I'd like to use the same version in Houdini and Maya, and the one that is the most up-to-date and gives identical results. (This is more preferred than threading performance.) So, does anyone know which version is more up-to-date? (I'd bet on Drew's but not 100% sure -- although the Maya version doesn't have the Largest Wavelength parameter, either) Imre * : We're testing this on a windows and an ubuntu box (both 64 bits) with 4 cores and getting 40-50% CPU usage at most on both machines (but only with quite large point counts, i.e. in the millions), but for some reason we can't get any multithreading in VEX either for some time (on both platforms, too), so it could be something Houdini-related. I just checked out the Maya version and it runs on ~70% usage.
  22. qLib v0.1

    As Mate said, at a certain point we agreed on not supporting anything pre-H12 any more (since this library is basically a "byproduct" of our working with Houdini, and at that point we all were using H12). This also allowed us to take advantage of new features like namespacing and to clean up some "H11-isms". However since it's under version control it's entirely possible to get a local clone from github, and go back in the commit history to a point where the assets are not yet namespaced, and build and use that version. Although it won't be the latest stuff, it'll still give you considerable advantages over an out-of-the-box H11. We started moving to namespaces between v0.0.28 and v0.0.29, so if you revert to somewhere there, you'll still be fine under H11, too. (Or just grab 0.0.28 from the downloads section.) Imre ps.: There's a note explaining qLib namespacing here, if interested: https://www.facebook.com/notes/qlib/introducing-h12-operator-namespaces-for-qlib/445701975463592
  23. per-particle radius scale for flip fluid simulation?

    That's great, I wasn't aware that it does this. However I'd prefer a solution where I create this manually (as I don't want the point count to be changed, and reseed does that). My fluid surface wouldn't do much movement anyway (it would be a calm water surface with some depth).
  24. sprite rendering artefacts

    This is an excellent idea! (I'll try to remember this next time I have to do "semi-sprites" )
  25. HOT variants ("Drew vs Christian" :))

    Btw, in H11 the mineigvec attribute was of type vector, but in H12 it seems to be a scalar (I suppose this might be a minor bug or typo when porting to the new geo architecture?). Just sayin' (I'll try to fix this in my repo and push it back...)