Jump to content

Eyeracker

Members
  • Content count

    23
  • Donations

    0.00 CAD 
  • Joined

  • Last visited

Community Reputation

9 Neutral

1 Follower

About Eyeracker

  • Rank
    Peon

Personal Information

  • Name
    Govind
  • Location
    Vancouver

Recent Profile Visitors

137 profile views
  1. Stepping issue with Solver SOP

    Hello DarshMewada, I cannot say for sure without looking at your file. But, I think you have a problem with extremely fast particles. So as an initial step separate out the particles that are too fast and then use Trail SOP to generate a streak for these particles only. Merge these particles with the original particles and then input them to the wetmap solver.
  2. How to make 10x slow version in Solver SOP

    Hi yasinesin, Made some modifications to the file. Here : 002_MOD.hip Here is an explanation of how it's done: Speed is controlled by the amount of relaxation being done on the points. So let's say the point relaxation moves a point by 'x' amount, but if we only move a fraction; say for example 10% of this 'x' then we are essentially slowing down the process. The attribute wrangle node inside the SOP solver does exactly this. It interpolates the point positions before and after the relaxation slowing down the entire process. Another way to control the speed is by reducing the point relaxation iterations in the point relax node. But this parameter is an integer and the slowest speed you can achieve is by setting it to 1. However, I am not sure if the pattern remains the same when the speed is altered. I haven't done extensive tests to check that. Maybe you can play around with the file and tell me. As for the methods you have tried, tweaking the FPS doesn't change anything because all nodes in SOP Solver are time-independent and only iteration dependant. So changing FPS will not affect anything. Retime also will not work because the geometry keeps changing because of the resample node inside of the SOP Solver and you need stable geometry for the retime node to interpolate the positions with the subsequent frames. Hope this helps you out.
  3. This is great. Found some good info in that link you posted. Thank you for your help.
  4. Hello vicvvsh, Thank you for the reply. But is there a way to make a directory in the $FOLDERNAME format? like $HIP, $JOB etc.
  5. Hello Everyone, How can I add new location links to the open menu in Houdini? I know that you can add locations with the '+' sign, but it's confined to a specific project only. So is there a way to add it as a global variable?
  6. RyanJP, Could you please post the links to those threads? I would definitely like to check it out.
  7. Delay Load Geoemetry

    Hello Krishna Avril, Delay Load Geometry: If this parameter is set, packed primitives and other shared data will not be loaded immediately but will be loaded only as needed. This can be useful when opening a large scene to reduce load times. You can read more about it here: https://www.sidefx.com/docs/houdini/nodes/sop/file.html
  8. Hello RyanJP, I have built a basic setup to transfer deformations from low-poly to hi-poly mesh. Maybe you use this as a starting point. See if this setup works for you: Cloth_Deform.hip
  9. Get input to DOP Network in POP wrangle

    Hello Matic3D, I made the changes as per your request: kill_MOD.hip First of all thumbs up to Sepu, for doing a great job. It's the easiest fix for such a problem and it's always a good practice to keep things simple because I believe, as the sim gets more complex, it gets difficult to keep track of all the complex setups that we implement. But I see that you wanted more data pulled from the control object into the sim. So, I modified Sepu's file a little bit. I got rid of the proximity pop node and inserted that functionality into the pop wrangle. I also changed how the threshold works. Now it gets that value from the control object. I assume something like this is what you were after. Here is how it's done: In the POP wrangle under the Inputs tab, I changed the input 2 to second context geometry. I have also set a controller for threshold in the SOPs level. So, now the POP wrangle now gets data from the second input connected to the DOPNET, which in our case is the control object. Now let's take a look at the code. The first two lines pull the data from our control object. Here I imported the position and threshold values into the variables pos and threshold respectively. Please note that I have used the point function for this. This is because if you take a look at the geometry spreadsheet with the control object selected, you can see that it's a point and it has both position and threshold values as attributes. Now why "point(1, "P", 0)" ? The 1 tells Houdini that I want to use the second input (In Houdini 0 means first input, 1 means second input and so on..) to get the data from, which is the control object. Since there is only one point coming from the control object I put 0 as the last argument to the point function. In the third piece of code, I calculate the distance of the points from the control object using the distance function and store this value inside a variable called neardist. Finally, in the last few lines, I compare the distance stored in the neardist variable to the value stored in the threshold and deletes points based on that calculation. Using this technique you can pull any data from the control object and use it in DOPS. Even if the control object's parameters change, it's still reflected in your simulations. Now let's imagine you have multiple points in your control object, then all that is required is to put the code in a loop and check for all the points in the control object. As you can see, the possibilities are basically endless. I hope this answers your question
  10. Collision between different flip simulations

    Okay, I think I have a solution. Here is the file: suctionforce_Modified.hipnc I added a group functionality in the code. It's not as versatile as the Houdini group parameter, but it should help you out with the problem you are having. Here is how it works: Type in the groups that you need in the parameter separated by a space. You can type multiple groups or single groups in the slot. If there is more than one group please see to it that it's separated by a space otherwise it won't work. However, if nothing is typed in the group parameter slot, the entire node is turned off. So you need at least one group to make it work. Please note that the normal wildcards and group operations such as "*", "!", "^" etc will not work. So you will have to type the group name exactly as it is. There are more elegant ways of doing this, but that would require a lot of python coding and attaching codes to parameters. Unfortunately, I lack the knowledge to implement those features. So sorry about that. But for the most part, this should work. You can take a look at the code and implement a similar technique for your other nodes which don't have the group functionality; Maybe you can even improve it. I haven't done extensive testing on this, so I'm kind of waiting for your feedback on this. See if this solves the problem.
  11. Collision between different flip simulations

    Hello FunnyName, Have you tried putting the two different fluid particles into different groups? The only thing is that you have to assign the groups outside of the DOPNET, in the SOPs level. What I'm trying to say is that we assign the flat tank particles with group A and the sphere emitter with group B. Then all particles born in the sphere emitter will, by default, belong to group B inside the DOPNET. Then we can use the group option in the forces node to isolate the forces to act only on that group. So in a sense, you have control over which forces will act on each group. I have attached a screenshot of the group option for your reference: I hope this helps you out.
  12. How to convert RBD back to a Mesh?

    Hello Joelv, What exactly do you mean by converting an RBD sim to mesh? Could you please elaborate?
  13. Flip volume gain

    Hello Gangland, I have done a similar simulation with champagne being poured into a glass. To simulate volume, I would first suggest activating the Particle Separation in the FLIP Solver node even before experimenting with divergence. A common problem that we encounter with FLIP fluids is that fluids with higher velocities tend to compress the particles. The same is also true for fluids that build up in a certain section. This effect is not so much evident when the fluid is flowing from one section to another, simply because it's difficult for our brains to keep track of minor volume losses in liquid when they are in relatively fast motion. So for the vast majority of fluid simulations, particle separation is turned off by default to speed up calculations. But when the fluid starts to build up, initially the solver will try to retain the volume but as the simulation goes on and more particles are introduced, the solver has a hard time trying to keep the separation between the particles. Especially with low velocities, the effect becomes more apparent. When particle separation is turned on the FLIP solver will do additional passes to ensure that the particles keep their spacing. However, like all solver algorithms, this method is not 100% accurate. As we keep increasing the Separation Iterations, the simulation gets more and more accurate and we will be able to observe less volume loss. As a starting point, I would suggest a Separation Iteration of 4. As for the Separation Rate and Separation Scale, the default values should be fine and rarely any needs a change. If particle separation does not produce the desired results, then we can think of introducing divergence into the sim. The combined use of divergence and particle separation can sometimes yield better output. The error that you made in your sim is that you turned on the divergence calculation in your simulation, but didn't initialize the particles with a divergence attribute. To fix this problem put down a pop wrangle in your DOPNET, connect it to the second input (particle velocity) of the FLIP Solver. Then type in the following code: f@divergence = 1.0; Then change the float value in the pop wrangle to adjust the divergence attribute to get the desired fluid expansion. I highly suggest experimenting with the particle separation method first before you add any divergence to the simulation. I hope this helps you out.
  14. Visible voxels in collision object in pyro sim

    Emesse92, By the way, I'm using Houdini v18.0.499.
  15. Visible voxels in collision object in pyro sim

    Hi emesse92, I have a different approach to this problem. So, I made some changes to your file: 1. Changed the scale in the gas wrangle node inside your DOP Network to 1, so that we are not deleting any density. 2. Added a gas diffuse micro-solver to your DOP Network. Like Atom said, the density voxels are getting clamped. So basically it's an aliasing problem. I am assuming this is partly due to your velocity fields. One way of dealing with aliasing is to add a very small diffusion; more like adding a slight blur in photoshop to fix aliasing in images. The same concept somewhat applies, but here its done in all 3 dimensions. This is exactly what the gas-diffuse micro-solver does, pushing a small fraction of density onto the adjacent voxels. The diffusion has to be very small, like say 2.5% otherwise the simulation will look mushy. I did some tests on the file and even at half your original resolution, I was able to get rid of most of the sharp voxels. At the original resolution, I expect the results to be a bit better. Try experimenting with the diffusion rate to find out what works for you. The only downside is that you might lose some detail in your simulation. 3. Changed the mode under volume collision in static object to volume sample and linked a precomputed SDF volume of collision geometry into the proxy volume slot. Also changed the division method to size. For me, the previous setup was taking up a lot of processing time before the actual simulation. So your sim should be even faster now. In my opinion, with the division method to set to size, its easier to set the voxel size of the SDF collision geometry and also gives you the option to link this with your existing voxel size essential giving you more precise control. Please refer back to your obj/COMPRESSOR_COLLIDER to see all the changes made. For some odd reason, the 'attribnoise' nodes don't work in my version of Houdini. I believe this might be because I'm using a newer version of Houdini. So if some nodes don't work for you, try to recreate the changes within your version of the file. The setup is pretty simple and you should have all the other nodes that I used. Hope this helps you out. Turbine7_Modified.hip
×