borisb2

you can easily creat your own emission criteria. No need to use shitty houdini-one. Just sample in a VOP neighbor velocities, subtract from current points velocity and fit range length of that vector into emission criteria. Remove all points that dont meet emission criteria . thats just one way

as far as I remember it was because of droplet-attribute which I was using .. disabling it fixed that issue.. but this was way back with H14 I believe

Hmm, its a customized wavelayer-setup (120m x 50m) with one moving collision object (which is also used to drive the moving boundaries.. so nothing too special. Particle separation is at .085, roughly (only) 14mio particles, 16mio voxels. Single simulated it takes up about 30gb, sliced up on 2 machines it takes up about 25gb each - but at least half the sim-time (which is good) I also noticed sometimes the sim freezes after 30-50 frames for no reason (simtracker doesnt show pending)..

Hi. I'm setting up distributed simulations on a small farm with tractor. It all seems to work ok, simtracker gets started, the slices are started, synced and doing their job. I also can measure expected time-benefits when simulating on 2 or 4 machines .. BUT .. I can see barely any benefits in memory usage, whether I am doing flip (with pressure solve) or pyro .. It all takes up the same amount of RAM, no matter if I simulate single, on 2 machines or more. Maybe 1-2GB benefit on a 30GB flip sim. Is that expected? I can see that the flip points are half the amount per slice (when distributed on 2 machines), the volumes are half the voxels etc. .. but it still takes the same amount of RAM - which makes the whole point of distributing a bit meaningless. What is wrong here? Did I forget something? The only thing I added in dops (besides the slicing plane) is the gasnetsliceexchange as well as setting the address etc. in distribution tab of course .. as mentioned it seems to work fine (according to simtracker.py). does anybody noticed similar behaviors?

be careful with the order when multiplying vector with float. vector multiplied by float is still a vector. the other way around is a different math-calculation

Testing out fracturing with finite element solver in H15. I find it hard to produce stable and good looking results. Simple tests may work fine but when it comes to simulating 400.000 tets the story is a little different. So far I tested various combinations with the following: - concrete building made of several solid objects. Colliding rock transfers pintoanimation-attribute in sop-solver to dop-objects to release parts. - dopnet substepping / FEM-solver substepping (fixed 1, 2 and 3, adaptive 1-2, 2-4, 2-6, 3-10) - max linear solve 1024 / 2048 / 4000 / 10000 - collision passes 5 / 15 / 30 / 40 So far it NEVER looks nowhere near a stable simulation. Pieces that are colliding with the ground snap sometimes back or rotate weirdly, I also cant get rid of stretching tets here and there. If I would use more stubsteps, the sim-times would sky-rocket. The last setup (about 350.000 tets, embedded geo, 7 solid objects) simulates about 20-25 frames, then suddenly freezes in the sim, meaning no error, I could still escape, it just doesnt continue. (wtf?) At MPC I'm used to work with kali (DMM-solver), so the idea would be to test out how good houdini can compete. But at this point I better not start comparing both. Houdini FEM just doesnt seem to be ready for hires-fracturing. And I do remember when testing the free DMM version in maya (despite all issues) it never had these solving issues. Any more attributes/setups I could test out to get it more stable? Could sidefx maybe switch to implement the DMM-solver instead using the current ?

I can highly reckon RenderPal as a cheaper and eas(ier) to use option to Deadline. Did a lot of customization-scripts (distributed sim, batch-jobs, wedging etc.) with hython. Pretty easy to setup and works very stable between houdini and RenderPal

Hi. As long as I let POP-grains fall onto something static they behave as expected. As soon as I am using a deforming mesh (anythign animated), the grains behave very bouncy - getting way too many velocities from the animation. Is that a typical thing with POP grains? when I lower the velocity blend in solver tab, it improves, but then the grains loose a lot of volume thanks for any help

no, its the wavelayer setup with some customized velocities (around the boat). Seems like this is happening only on this cache - a different cache-version doesnt show that behavior. As mentioned, also acceleration and curvature are showing weird results (stretched)

I'm setting up a new flip sim - open ocean shot. main flip sim so far looks good. But whitewater source is causing problems. When using "volumes and particles" as source I get nothing with vorticity, When using "Particles only" I get this: (see image) Also trying acceleration or curvature gives not one good source for foam emission - didnt have that before any idea whats causing this?

I was sure that I had to be wrong ..didn't know about that one: d = 1/2gt2 thanks

we know that 1 unit in houdini is 1m .. is it really? Thought I just test it: Placed a cube 10 units in Y above the grid, RBD-object, gravity 9.8 .. uups, takes 35 frames to hit the ground. according to physics: g = 9.81 m/s^2 v= s/t a= v/t -> a = s/t^2 t = sqroot(s/a) = sqroot(10m/9.81m/s^2) t = ~1s = 24 frames .. not 35 !! whats wrong ? placing the cube 5 units in Y it needs exactly 24 frames to hit the ground by the way

solved! .. perfect! .. Thanks!

I installed a new NAS (Synology 1815+) - all good with all programs, just houdini shows me a partly grayed out file browser. I can load and save files but I can't click on them or create a new folder. The old NAS or saving on C: doesnt show that issue. Is that still a premission issue? has anybody seen this? .. very strange and very annoying.

You mean installing both houdini and engine, but licensing and using in my scripts only engine?