sebkaine

ahah i think i would mix both approach describe previously. - with only pop + gravity then vdb you will miss the swirly pattern of fluid - with a pyro sim + pop advect you will have hard time to get the simple direct gravity pattern - i will start with a pop sims ( maybe pop grain to check if it bring something more granular ) to create the main gravity behavior - then use that sim to emit vel + density in a whispy presets pyro grid - then advect some additional pop in it that pyro grid that will fade fast and render : - pop gravity + pop advected with high motion blur - and whsipy fluid with low density shader

Ok gotcha : As effective changes in stiffness requires painting over orders of magnitude, this has a logarithmic effect. i don't exactly know what it is , but i'm sure it explain the problem. houdini doesn't do a scale with a basic mult but instead use logarithmic math. anyway i don't like it cause it introduce unexpected value that i have not ask. i will use the wrangle option to be sure to control exactly the value i want. Cheers

Hi guys, i don't understand what is the internal math done by bendstiffness. i have a scene with stiffness set to 1 + stiffness multiplicator to 1. then i have a point attribute bendstiffness that i use as a scale multiplicator set between 10000 and 0.0001. i was expecting to get my stiffness between 10000 and 0.0001 but it give me weird values. to get what i want i had to bypass the feature and do it with a wrangle. I would be curious to know if someone could explain me why i get those strange values. I have attach a HIP that describe the pb. Thanks for your time Cheers E kStiffness.hip

I thinks it's because this is the way FBX has been devised. basically FBX export animation in two ways : - the most popular in game where you store animation with xform transform and bones + weight map. - the other is by exporting a vertex animation cache like the .abc format, in that case FBX export only one FBX file and store the animation in a file point cache .fpc If you want to export per frame .fbx you just want to hack the way the format has been devised. it looks to be possible thought there is a scene by tomas here : https://www.sidefx.com/forum/topic/54398/?page=1#post-349575 why do you prefer FBX over .abc for vertex cache file export ? why per frame ?

Hi masoud the question has already been ask ,with no proper solve i am afraid out of the box a beautiful world where you flip would push your vellum and then the vellum would push the flip with a dual direction interaction doesn't exist. so you will have to find a tricks that do the job. One direction influence will work without to much trouble, dual will be more tricky. i would try as a starting point, to setup my mid res sim flip correctly and use a resample lower version of my flip vel grid as volume influencer of my vellum object as pop input. then i'll bake my vellum and redo the FLIP at high rez with vellum object as vdb collider not perfect but i would try that. for the hard way i would inspect pavel tricks and see if it can be adapt to FLIP and thus reinject collision / collision vel inside the FLIP grid dynamically https://forums.odforce.net/topic/44014-vellum-and-pyro-two-way-interaction/?do=findComment&comment=207660

yes i think all have been said. both setup are based on a similar setup but not identical. both initialize the wave tank in a different fashion one use Guided Ocean Layer the other Wave Tank Guided Ocean Layer : Generates a thin layer of particles on top of a guiding ocean surface. The particles are initialized with ocean velocities. The guiding ocean surface and velocity volumes are used both as a boundary layer and as a guiding surface to drive the thin layer of particles. This preset is most useful for simulating the ocean surface where closely matching the underlying ocean spectrum surface is necessary. Wave Tank : Generates a full tank of particles initialized with ocean velocities as well as boundary layer surface and velocity volumes that can be used to update the simulation velocity in the boundary layer. This preset is most useful for simulations that require a full liquid simulation including interaction with deeper parts of an ocean. - You will use guided ocean layer when you have a large ocean with precise look define in the spectrum , then you want to have a FLIP sim splash in a small area of that ocean, but you want to be able to perfectly match the Flat ocean geo and the FLIP sim meshed geo at render time, accuracy is key here you need perfect match between deformer and simulation. - wave tank is just a way to art direct your flip, to give him a turbulent ocean pattern, basically you art direct the shape of your ocean with your spectrum, then you tell to your FLIP ok i want you to move like this but you keep your freedom during the simulation time. The goal is not to match a deformer , the goal is to define a wavy turbulent behavior in your FLIP sims

It is still extremely challenging to do small scale elegants sims involving thin sheets of liquids with the FLIP solver and the default tool. Actually we have the option to use surface tension that force us to use a very high susbteps between 10-16, to get clean result. The main advantage of FLIP over SPH, is that it can solve about everything with just 1-4 substeps max, so this kills the advantage of FLIP over SPH in certain scenario. The best small scale liquid houdini artist in town like Pazuzu or melt vfx guys, both ended up to develop there own particles solver to preserve surface tension + thin sheets. That would be great to have by default inside Houdini : 1 - a particle based tension solver that would be based on a solver directly plug in the particle input of the FLIP solver, mimicking the concepts describe here by using mean curvature flow to compute surface tension force allowing us to keep low substeps : https://www.cc.gatech.edu/people/home/turk/my_papers/surface_tension.pdf 2 - a preserving sheets particle solver, that will be able to reintroduce particles cleverly inside the sims, to avoid gap in thin sheets area in the same idea describe in this paper would also help a lot : https://ryichando.graphics/sheetflip/download/tvcg.pdf 3 - an anisotropic methods for meshing small scale liquid would be very useful , the fact that VDB constrain us to use isotropic meshing is also challenging when you want to get a very clean thin flat surface that preserve detail / curvature / continuity, like describe here : https://faculty.cc.gatech.edu/~turk/my_papers/particle_surfaces_tog.pdf 4 - i would love to see better interaction between a ripple solver 2.0 and the generated FLIP mesh / sdf, to be able to post process a FLIP sims to add additional detail ripples on top of the FLIP sims base on velocity / curvature / tension. like what is describe here : http://www.cim.mcgill.ca/~derek/files/surfaceWaves.pdf EDIT : Artem Smirnov has just publish an implementation of this concept. To have a tool able to do exactly what happen at 00:32s in this video inside Houdini would be really useful. 5 - a specific 2D FLIP solver that is specially devise and optimize to work as a thin slice of data that can work with SDF and heightfield colliders. This could be combine with the new ripple solver to post process extra detail. This would allow us to generate very detail 2D map of length(velocity), vorticity, wet influence very fast, and transfert them directly to a heightfield/sdf. ( same logic of the flowmaps tools ). Generally i think a better interaction between FLIP / Heightfield / Ripple Solver 2.0 for small scale shots is really possible and would help a lot. There are very very few area where houdini is not already the perfect weapon, but for small scale elegants sims, i have the feeling that we can do better than the actual toolset, or maybe i'm wrong and small scale elegants sims will always remain the hardest nuts to crack in FX creation. PS: i know there are some randoms piece of codes on this noble forum to solve those problems, but a clean upgraded small scale workflow done by SESI wizzard would be ace.

You looks to be more on the CG artist side than the TD side. So better focus on this. and it's never too late to learn coding and explore TD side later in your career if you really need it. then replace the 2 years computer science academic program in your country , by a fine art degree in whatever you love the most , - drawing / painting / sculpting - photography / cinematography - architecture / design and focus more on a generalist artist / environment artist portfolio , the idea is the same, learn the fundamentals of your craft in an academic place instead of a CG school to avoid spending 3 years of your money in a school with very expensive fees. start the button pushing training on your own during your first years, then when you have develop your artistic skills and 3d skills apply for a good VFX school that will allow you to specialize and get good contact and reference to apply for your first jobs. what is very useful in a school like artfx / esma / gobelins / supinfocom in France it's the contact they have with the best company, they have meetings with recruiters and they do help to get your foot in the doors. that's why i would recommand going in a school for 2 years, it will not give you great course, but it will give you connections , with people in the industry. i spend 2 years only at artfx , and they do deserve the money i give them ( 5700 euros per years at the time ) , i get my first gigs thanks to them , but i would never have been able to pay the money they ask today ( 8500 euros per year * 5 ). i also think you need time to discover what you love most , and sometimes it's not what you expected, i start with the idea of being a lighter and ended up doing fx for exemple. sometimes discovering what you love most in VFX and most importantly what you are GOOD AT, take time.

Hi anna, if you target a houdini career, i would definitly not recommand to spend 5 years in a VFX school, you will pay too much for what you need and for what you will get. If you live in latvia, you live in a country with very good computer science guys around you. and i guess there must be some strong academic school in computer science very close to you. So if you target a Houdini TD career , i would start with a 2/3 years generalist computer science gaduation where you will learn Math / Physics / Algortithmic / C/C++/Python / some good OOP methods, if by chance you can have a computer graphics option with OpenGL/GLSL/HLSL course that would be even better. And during your 2 years learning computer science i would eat as much houdini tutorials as i can, trying to do small exercices just to practice with houdini 1 hour everyday. then i would assemble a small reel of what you can do with code and also with houdini during those 2 years and then apply in a school for a 2 years houdini focus training, i would not spend more than 18.000 euros for this. the good things about learning computer science , is that you will be a better houdini artist than anyone in your school cause you have train your brain to solve hard problems doing math and code. and when you will get older and want to leave the vfx circus like many people around 40/45 you will have a strong academic diploma to move to tech companies. people from eastern europe have strong skills with math and code, you had to exploit this to your advantage. for the tutorials to watch in priority : 1- during your computer graphics academic, focus on learning the basics and the vex/vops/sops fundamentals : https://www.hipflask.how/courses -> good start https://entagma.com/ -> best in class to play with code and solver https://www.tokeru.com/cgwiki/?title=Houdini -> best in class to get advanced info https://www.pragmatic-vfx.com -> i don't watch it but friend tell me it's AAA for advanced vex 2 - In VFX school now that you have strong basis with houdini logic on top of your houdini class, you can start mastering the solvers FLIP / PYRO / RBD https://vimeo.com/goprocedural/videos/search:masterclass/sort:date -> sidefx masterclass are AAA https://www.rebelway.net/ -> for pyro / flip / rbd 3 - at anytime For online help : https://forums.odforce.net/ -> THE place to be https://www.sidefx.com/forum/ -> good info too For discord help : Houdini-and-chill -> best houdini artist around Think Procedural -> very good too with this you will be ready to go : 2 years in computer graphics + self training on houdini basics then 2 years in a Houdini TD focus training + self training with advanced tutorials on solvers. Good luck and whatever you do obstinacy and hard work will get you there. Cheers

Thanks for your answer Shantanu, unfortunatly i can't as it's a NDA work.

Ripple Solver 2.0 with - support for Ripple source object with SDF collision and ability to better inject @v in the grid, - better physical behavior for ripple self collision - enhance and better connect the Ripple SOP deformer to the solver be able to art direct more precisly the ripple behavior - ability to control the behavior at the boundary ( bounce / no bounce / continue on opposite boundary ) - integrate the tool smoothly with heightfield workflow

Well i still have strange behavior of DOP's trying to evaluate all the time. I did find a working solve for this. Each of my DOPs output is connected to a switch node, one is the DOP network the other a NULL, then i have a master null at /obj level that control all the switch, thus i can activate and deactivate everything i need. and this does work , when all switch are set to NULL houdini doesn't evaluate anything. I did prefer this method over always playing with the brain logo and the manual / update switch.

well i think i get where the problem come from. my collider was not properly setup. I use direct vdb conversion instead of the collisionsource SOP. thus my emitter wasn't properly evaluating animation on the collider for substeping. things works without viscosity and stick on collision because i guess houdini only need one substep to solve the calculation. but when visco and sticky collision were activated houdini need more substep. so i think that each time the solver was trying to substep , it can't find proper info from the collider and thus fallback on the bbox of the object. using collisionsource that use a proper timeblend solve the issue.

thanks for taking the time to open the scene ryew. i'm on 18.5.633. the weirdest thing is that after your comment, i just reopen the hip delete the noViscosity group and test the viscosity only, and now it looks to works. ahaha something esotherical here, generally in those situation the problem come from behind the keyboard. the hip i share is a quick exemple of a scene i can't share here, where the problem is the same. i'll double check that tomorrow. Cheers E

i get the exact same issue, but i can't remember having seen this before , weird ? - i use pre cache vdb collider loaded as static object - the collider is a deformed object - when i don't activate viscosity everything work smoothly - as soon as i activate viscosity the solver stop to use the vdb collider, and is unable to evaluate the sdf grid properly - instead it use the bouding box of the collider I'll investigate on this and this if i can find a proper solve ! Cheers I have attach a simple scene that illustrate the problem. flip_collision_problem.hiplc