Jump to content

k2p8

Members
  • Content count

    23
  • Donations

    0.00 CAD 
  • Joined

  • Last visited

  • Days Won

    4

k2p8 last won the day on December 3 2020

k2p8 had the most liked content!

Community Reputation

38 Excellent

3 Followers

Personal Information

  • Name
    Matt
  • Location
    France
  1. Hi folks ! I did a simple maze generator from a recursive backtracker in vex. The idea is simple : You get your adjacent neighbours and check if they are not visited, if not, you randomly choose one and move to it. If no valid neighbours, you backtrack the stack of your previous positions and check if there is a valid neighbour until you find one. If the stack is empty no valid cells are left so the maze is done. recursive_backtracking_001.hiplc
  2. Hi folks ! I am cooking a pdg network, simple setup. I just split a cache by a @cluster attribut to save each cluster independantly and run a pdg over that. But i randomly have an error i don't understand : '__pdg_preframe' is invalid or already exists' Do someone know what does it mean ?
  3. generate to fill up wire curves in tube meshes

    May be you can compute a vector field with a direction along the tube and some noises to create point trails procedural_roots_000.hiplc
  4. Pop orbit object [Tutorial]

    Hi all ! I did a simple vex scene with particules orbiting an object. The main challenge is to avoid particules to exit their orbit by computing an vector that correct their distance to the surface object from an iso value. Hope you like it. Update : Added the gradient of geodesic distance as axis of rotation for the particules. Usefull if you want to rotate along each element of a geometry, like arms, legs, tentacles, etc. pop_orbit_001_odforce.hiplc
  5. Hi all I am posting a simple procedural desintegration that is very fun to build, as always, with quaternions and vex. Vex is annoted, Hope you will like it. There is a line in vex where i remap a random quaternion [0, 1] to [-0.7, 0.7]. It roughly removes the random overlapped orientations. If you disable it you can see that orientations are a bit biased because of the 0 - 1 range. Update : Now with RBDs lego_desintegration_RBD_001.hiplc
  6. Directionally orient grid

    if you are a fan of quaternions and matrices you can do a spherical interpolation (slerp) of 2 quaternions which represent the local orient of the leaf and the global orientation to the sun orient_leaf.hiplc
  7. Hi @eunchae, The basic principle of an upres is to make a new simulation with a pre-existing velocity grid that you use to drive a new dye (density / temperature). Your new simulation should have smaller voxels and parameters close to the lowres (like temperature diffusion, flame amount, time step) if you want this new version to be close to the lowres. You then copy the lowres velocity and simply advect the upres by it. This way you only perform heavy computation like divergent free velocity (ensure the conservation of the mass of the fluid) and the boundary collision on the lowres, the upres solver only has an advect for the density / temperature / ect. all other nodes relative to velocity enforcement / computation are deseabled which allow you to quiclky compute the upres and skip all the heavy parts. Then you can add a little amount of noise with an add operation to the copyed lowres velocity to give more details to your upres. This small amount is almost divergent free on a large scale so it should not be a problem. You can add any forces at this process in the upres, but, the divergent free velocity node being desabled, only already divergent free forces should be added. Otherwise your smoke will compress into itself. And you should only add forces that do not push your upres smoke to far from the lowres, since you simply copy the lowres velocity, no new velocity will be computed outside of this bounds. So, for example, adding a wind, which is divergent free, is not a good option since your smoke will crash into the bounds of the lowres. There is some parameters that do not scale well with the upres, usually it is all parameters or operations that need neighbours voxels to be performed, like temperature diffusion. Since you change the size of the voxels, those operations have an overall result which is generaly not the same as the lowres. You could correct that by sampling the lowres version of the simulation and modify the output value, but you lose a lot of details by doing so. So in this case, it is better to slightly twik the upres simulation to perform better, by increasing or reducing the corresponding parameters.
  8. ACES Rendering output

    ACES pipeline is sometimes applying slight tone mapping before the output which they call RRT (Reference Rendering Transform), and then, your output transform sRGB / Rec.709 is applyed. So you can have slightly different outputs if you are using Utility - sRGB - Texture or output_sRGB or Output - sRGB. I don't know exactly all the slight differences between all those transforms but i dont think sRGB - Texture is a usefull transform to export your pictures. This is in the Arnold ROP. You must choose your render color space (Properties > Device > Color management ) and render output (Properties > Output > Color Space) in the Arnold Rop to know which color space is used. Theoricly if you want to use ACEScg it should be ACES : ACEScg for the render engine and a linear sRGB / ACEScg for the output then you will need to convert this linear ACEScg/sRGB to an sRGB space with an gamma 2.2 or sRGB / Rec.709 transfert function applyed to be able to display the picture on a sRGB Monitor. If you want some docs about ACES there is this articles which is a good start and the ACEScentral forum : https://chrisbrejon.com/cg-cinematography/chapter-1-5-academy-color-encoding-system-aces/ https://community.acescentral.com/ PS : And Of course you must install OCIO to manage all those color spaces / transform PS2 : If you are using Arnold be sure to convert your tx and houdini color node to the correct space. If you are using ACEScg and you generate TX textures they will have a ACEScg space applyed so you can't use them for sRGB anymore and the opposite is true too. Same thing for color node in houdini, if you enter a (1,0,0) it will be for sRGB so you need to convert your color node to an ACEScg with an OCIO transform other wise you are not sending the correct color to Arnold.
  9. Hi folks ! Is ACEScg rendering usefull for volume rendering ? I was reading more about ACEScg in general (still abstract for me at this point) : https://chrisbrejon.com/cg-cinematography/chapter-1-5-academy-color-encoding-system-aces/ And it seems, from the article, to give good results in color saturation and GI so i am planning to implement aces in htoa to do some tests. Have you guys already tested ACEScg in houdini, especially for volumes ?
  10. Bullet and Constraints learning ressources?

    if you want to know more about bullet constraints themselves there is Tokeru website : https://www.tokeru.com/cgwiki/index.php?title=ConstraintNetworks he explains in details attributs on prim / points with examples
  11. Sparse Pyro Upres H18

    @Atom What does it means 'in other DDC packages' ? If you want to match a pyro look to an other pyro you can look at the volvis_ attributs created by the post process of the pyro. You will need density / flame / temperature fields and the values of the ambiant / reference temperatures in kelvin of the pyro solver. If you match all those values you should have an identical result. If you re importing smokes simulations from an other software you might need to fitrange / scale the fields first i think.
  12. Sparse Pyro Upres H18

    Yes my bad, i tought it could be a nice idea to post the solver here since it s finished now :V
  13. Sparse Pyro Upres H18

    Hi @Noobini, i have a AMD Ryzen Threadripper 1950x (16cores) 3.40GHz, 64GB ram with windows 10, 64bits
  14. Sparse Pyro Upres H18

    Hi everyone ! I have been working on a sparse pyro upres recently and did a video to test it. You can find the hda here : https://drive.google.com/drive/folders/1H4Y0HNELDJ6lmHsM43eEI_lRgNuCEaxX?usp=sharing More details about the solver : The sparse upres solver is a deeply modified sparse pyro that allow the user to quickly upres a smoke simulation from simple inputs. The core idea for the upres is to bypass every nodes related to velocity update in the smoke solver, like the project non divergent, vel advection, collision mask, ect. and replace the upres vel field by a copy of the low resolution velocity. One can then advect any dyes needed through that vel field to create an upres. In order to keep the pipeline as simple as possible i splitted the process in 2 nodes, a 'configure_inputs' which precompute some lowres fields and normalize inputs and the upres solver itself. The sparse solver needs to match the parameters of the lowres simulation to work properly (like dissipation, flame amount, temperature diffusion, ect.). To quickly set up the upres solver i added a python script, that copy and paste all relevant parameters of a lowres pyro to the upres solver. You just need to select which pyro solver to use as reference to match the parameters. The sparse solver itself has some simples parameters like noise / random that allow the user to inject details in the lowres vel field. Noises and randomness are stored on an separated field, 'noise', to be conserved through time since vel is simply copied from the lowres. That allow the noise field to be advected by the vel and then merge with it to advect other fields like density, flames, ect. Which create a more complex pattern than a noise directly merge with the vel. Color can be added at the upres stage if the source contains a Cd and Alpha volumes. Those fields will simply be advected by the upres solver like any other fields resulting in a colored smoke. Your lowres simulation needs no color. Retime can be perform by interpolating the source and scaling parts of the upres solver. The process is automated from a tab in the sparse solver. However, it can vary if you animate the retime or set it to low (especially with flame). The upres solver does not need any modification of the velocity other than small disturbance / turbulance details. If you add strong changes in the vel field your upres dye will deviate far away from the lowres vel field. Every major modifications of the vel field like wind or buoyancy need to be added in the lowres simulation. A fake divergence can be added through the process by computing the negative gradient of the density added to the velocity. Since pressure projection has been bypassed, important amount of this 'divergence' will result in compression in the vel field creating artefacts in the smoke. However, it can be usefull to break the sharp edges of an upres smoke if needed. At last, one can force the upres to match the lowres fields by simply removing parts of the simulation which are outside the lowres smoke by taking the lowres density field as reference. If the lowres is below a threshold value, the upres smoke is multiply by amount less than 1. This can be usefull is you have strong noises and need to dissipate them to stay in the bounds of the lowres.
  15. You're welcome I updated a bit the solver and did a video to test it here is the link with the updated solver (it's the same as the previous one) https://drive.google.com/drive/folders/1H4Y0HNELDJ6lmHsM43eEI_lRgNuCEaxX?usp=sharing
×