Leaderboard

Totally Agree! - And build in wedging in the file sop, so you can use a $COPY variable anywhere in your chain and modify parameters along the way with it (very similar to copy stamping, only each copy goes to disk rather than in memory). Make it read and write a single copy, or all copies. Many effects now are clustered/partitioned. - and build it so that this diskcaching node can be triggered from rops and dependencies are respected when the copies are still running. - make it so that you can choose to use this node and run it - locally as well as on hqueue: ***) as a single sequential process in the background (all copies are running back to back in the foreground - this would be for heavy stuff where you are limited on memory on your local machine), ***) as a single sequential process in the background ( all copies are running back to back in the background - still for fairly heavy stuff, but you can continue working) ***) as a parallel process in the background ( a specified amount of copies are running as different processes or on different threads in the background - this is for light stuff or intermediate. As most workstations have quite a bit of ram and multiple cores. ) *)Make it so users can put in their own output path or switch to an automatic path that has a few names defined by default based on $SHOW, $SHOT, $SEQUENCE, $JOB,... + a version number like v001 or f01_v01.

these are two different things. the points which are being returned by pcopen are always sorted by distance no matter what the pointcount is. but let´s suppose you have 1000 points. you can't be completely sure that point 500 will be processed after point 499. still this doesn't change the order of queued points in pcopen. that's true but since pcopen relys on building a search-tree (kd-tree) it won't be multithreaded anyway. at least not for generating the structure (accessing the tree is threadsafe afaik). but as i said before, this might have been changed in houdini 12. petz

Give us a kickass caching node! Every place I worked for so far has their own version of a diskcache node. Usually they are the most useful of nodes and each shop has their own great features (writing to network, automatic versioning, file optimizations, loading clusters, selective loading, etc). Some of these features are pipeline specific but I am sure that we could do much better than the file and cache sops!

pcopen returns all found points ordered by distance. but due to its SIMD structure and particularly with pointcounts above 256, vex doesn´t necessarily process the points in order (above 256 points vex starts splitting them up into parts for better threading). afaik that's how it was for houdini 11. i have no idea if it's the same with H12. hth. petz

Yeah, I think SESI has a challenge in understanding where it wants to go next - whether they continue to refine and introduce FX components or they try and sell Houdini to other aspects of the biz, and especially to early adoptees - get them building procedural tanks in Houdini instead of low-poly robots in Maya. To be fair SESI has been attempting to push Houdini as more than an FX Tool for a while, and it looks like the recent price cut is a further move in that direction. I think the biggest barriers to getting into Houdini for a beginner are some limitations around the poly tool set and the shading methodology. I would love to see a Hypershade style graph with predicted rendered swatches. Most people diving into the vex context of a shading network for the first time.. go 'what the... $!'... and back out. FEM would be greaaaat, but I wonder as Houdini has the best RBS system available they'd wanna go down that route just yet. I agree about the speed, and most users are willing to forego the extra speed for the functionality Houdini offers. SESI just had their best year apparently, so I think they should go all guns blazing and keep going after modelling/lighting/animation as well as FX.

There are a few areas where Houdini could shine in the future. Handling massive datasets is one of them. I'd love to see some clever approaches to dealing with huge sims, geometries and such things. Mantra is also coming along nicely and I think it has become a very good renderer. One of the next big things may be serious fem solvers and I hope sesi will jump in early. Perhaps a few more exotic 'toy' solvers would also be a good thing. They don't have to be production-ready but if they are there to take apart I'm sure the community would pick up on it. Personally I haven't used Naiad but I've worked in places where they have and my impression was that it's not the wonder-tool it's been portrayed as. The same thing goes for Arnold by the way. Having such functionality in one unified, beautiful package is hard to beat, even if it may be slower here and there.

the iterating in while loop returns correct values as well, but note that your line if (pciterate(handle)) actually iterates over first point and then calling: while (pciterate(handle)) straight afterwards without importing anything from that point first, you are actually ignoring it completely and importing values from second point on so that's why it returns just 3 values per point

somehow some faster/better poly modelling tools/workflow would be nice too.

Never mind. Those two above beat me. EDIT: Actually, there is another way. You can use POP context and just birth particles with a help of "Source POP" and Emission type set to Volume. You don't have to use ISOoffset with this method. Instead of seed parameter, to randomize point placement, you can than use various parameters on POP network node itself , like "Preroll Time","Start Time". Just make sure to set particle "life expectancy" to something shorter than it is by default so you don't have to set those parameters to high to start notice change. One sec. should be good.

- Use an IsoOffset on the geometry. - Now use the Scatter SOP. As an alternative you can use the "Points from Volume" SOP. EDIT: Dang, Symek is fast

Hey Oliver, Hopefully, it is not too much of a shameless promotion but I ended up creating an asset to do this (in python) and uploaded it to the new orbolt store. You can get it here: http://www.orbolt.com/asset/aswaab::soptools_match_by_distance I ended up storing all the information in arrays and then using python sort tools to filter by distance. Not the quickest method, but much faster and cleaner than the foreach route I was using previously - and you don't need to handle deleting points from the second object at all. Check out the trial version. Maybe it does what you need? I don't know if the python code gets protected in the asset or not, but if not you should be able to check it out. -Adam

hi, im trying to make a bunch of droplets over a surface, im almost fine when droplets are over a grid surface, but when is over sphere or other, metaballs are complete mess.... i wanna know which other methods could be for creating realistic droplets. here is the hip. DROPLETS_MIAS.hip