Welcome to od|forum

Register now to gain access to all of our features. Once registered and logged in, you will be able to contribute to this site by submitting your own content or replying to existing content. You'll be able to customize your profile, receive reputation points as a reward for submitting content, while also communicating with other members via your own private inbox, plus much more! This message will be removed once you have signed in.

rbowden

Members
  • Content count

    183
  • Joined

  • Last visited

Everything posted by rbowden

  1. If you want to use RBDs, you need to change the drop down on the rigid body solver from bullet to RBD. Since it is set to bullet, it is creating a convex hull across to connect each box.
  2. I am a little confused. To make sure I have this right, you already did a water explosion and now you want to take that result and have that collide with another tank? Or did you make the water explosion in just a popnet (non flip)? Basically are you creating something like this? https://vimeo.com/106930270 Or are you trying to emit flip particles from an actual mesh?
  3. Don't have the bunny geo so, can't really add to your file because it is erroring out. If you want to do this as a flip sim, I would look into doing some variable viscosity. Here are some forum posts to put you in the right direction: https://www.sidefx.com/forum/topic/31114/ https://www.sidefx.com/forum/topic/31574/ http://forums.odforce.net/topic/21855-viscosity-by-attribute-how/ http://forums.odforce.net/topic/23904-melting-flip/ Also in the help, you have an example for variable viscosity. Since these are particles you are dealing with, you could try and get some tendrils using POP nodes and plug them into the particle velocity input of your flip solver (2nd input).
  4. That is a pretty low res fluid you are trying to mesh. If you are just doing this as just a test, run your simulation out at a particle separation of something like .05 (should give you about 680k particles) and then set your particle fluid surface separation to be the same value. That will already help out alot...If you still want more sharper peaks, put a peak SOP after your particle fluid surface and put it at a value of something like -.06.
  5. So you have a file SOP in your file that is used to bring in your cannon geometry. You didn't upload the cannon geo with your file so when someone else downloads and opens your file, the whole network doesn't work because it is missing that geometry. To get around that, you need to lock your file SOP so that the geometry gets saved inside your file. To lock your file SOP, you need to click the lock flag on the node. It is right beside your bypass flag...click that and re-upload if you are still having issues with the pump.
  6. Here is a simple setup that deletes the points based on the active attribute. isolate_active_RB.hip
  7. Was the pump working before the crash? Hard to debug exactly what is going on in your file since you didn't lock your cannon file node before uploading the scene.
  8. I am confused on what exactly is the problem here? From looking at your file, the vdb reshape is working correctly and it is grouping the points inside the pig. I assume that is what you want because that is what the grains masterclass is doing with this (which you are creating this from). Using Houdini 16.0.542
  9. Should just be Xform Time Samples yeah? Render Properties -- Rendering -- Xform Time Samples.
  10. Lock you ship geo and your surface geo and then upload the file. If you do that, you won't have to worry about uploading everything. The geo will get saved in your hip file on the frame you locked it on.
  11. You have multiple people in this thread trying to help you but, you keep responding with that doesn't work. Show us what your material network looks like. Post up your rendered results so far. Put up a .hip file of what you have so far. That part in your OP you have circled is just a velocity (aeration) pass.The thread that @Federico posted should help you with that and it even has hip files in there for you. Have you checked them out? Have you tried to implement what is in those threads in your own file yet? If so and it still isn't working, show us what isn't working for you.
  12. The term you are looking for is flowmap and you don't necessarily need to do a sim to create one. You can do a complete sops based approach to do it but, you can do a flip sim to create one though if you really need to: https://github.com/sideeffects/GameDevelopmentToolset Has an example of how to do that but, I have a feeling it will become alot easier with H16.
  13. In regards to exporting Pyro FX to a sequence of images to use as sprites in UE4, I suggest giving this a watch: https://www.udemy.com/game-effects-using-houdini-ue4 Should help you a bit with getting a setup done and it has some hip files in there to dissect.
  14. Do you have enough particles in those areas that look sparse? How many particles are you dealing with in a particle separation of .02? Did you mess with any of the other parameters in your particle fluid surface SOP? Have you tried putting a bounding box around a specific problem and deleting all the particles except for in that box and tried meshing that? Could just be GL that is messing with you. Seriously a ton of factors to look into and I don't have an updated file from you to help debug so hopefully those questions give you a start.
  15. You need to fix your collision object. Attached is a fixed file. stick_RB.hipnc
  16. I'm gonna assume you are talking to me (Ryan) when you say Rob Reseeding is supposed to maintain particle count but you should always be double checking your particle counts to be sure. Reducing your particle separation from .03 to .02 could be a pretty drastic change. Again, double check your particle counts to see how big of a change it is. Sometimes it could be something as big as a 10mil point change. I'm not sure what you mean about the particle fluid surface not detecting the resolution? If you used to shelf to set this up (which you did in the file you posted earlier in this thread), the fluid compress particle separation and the particle fluid surface are both channel referenced to use whatever particle separation you use on flip object. If that isn't the case, then you probably broke that link when testing out some things. As for viewing the amount of particles, @Diego A Grimaldi is correct that you can just middle click on your DOP IO node to do this. If you want to do it in the flip simulation, you can just middle mouse click on any of the nodes and it will tell you how many points you have in the flip object (I usually just do it on the flipfluidobject itself though). Be careful with Diegos suggestion of the viewport particle count display. If you have that up in your viewport, anytime you change frame, it is going to cook your simulation because it is going to try and read that frames particle count. So only keep it on if you are doing a flipbook or going frame by frame manually.
  17. For doing a simulation like this with a workstation like yours, you need to be a bit smarter when doing flip simulations. Just by looking at your file, I can see many areas that can be improved on to help with simulation times and your meshing process. Here are some of my findings so far: - At a particle separation of 0.025, how many particles is that at frame 48? I am going to say that it is alot. You need to me more conscious of how many particles you are dealing with in your flip simulations. The particle separation is going to be different for every flip simulation you ever do because it depends on the scale of your simulation. I took your file and ran 10 frames of your simulation at a particle separation 0.025. At frame 1 you had 4 million particles and at frame 10 you have 22 million. You are roughly injecting a little over 2 million particles per frame at that particle separation and you keep doing so every frame until the end of the simulation. The only time particles are getting killed are when the waterfall hits the bottom of your container. If you are going to emit particles like this every frame, you are best off maybe having some sinks around your main body of water to help regulate the number of particles. For a body of water like this, you can easily get away with regulating the number of particles to 25-30 million and have that be enough resolution for you. If you don't want to emit particles like this every frame in the large body of water, don't make it an emitter and turn on reseed particles instead. Reseeding will help regulate the amount of particles that you start out with and try to maintain that if particles are getting killed off. Read up more about it in the help and do some testing with it. - The tube emitters. I have no idea why you are even adding these into the same simulation as your body of water. Why not separate out the process and do each tube emitter separately? Sure, in the real world you would have that water fill your body of water but you have to stop thinking real world and start thinking about how to fake it. Do your emitters first, have them emit down and go a little bit into where your body of water is going to be. As soon as they are past that threshold, kill those particles. You aren't going to see them churning around inside the water in your shot. The most you are going to see is maybe some splash kicking up and some ripples (all of which you can go outside your flip simulation after it is done). If you do it like this, it gives you faster turnaround if you need to make changes to anything in your simulation. If you were to get notes on a change to the body of water and not the tube water coming out, you can just change the body of water because now you have it separated out and your tube water will look exactly the same. - As for meshing, you are trying to mesh many particles and of course you are running out of ram. Do you really need the particle fluid surface to iterate through all those particles that are under the water? Not really. You have some pretty deep areas of your flip simulation and unless something is going to be interacting with those deep areas, you can probably just delete those particles that under the surface. I believe you have some settings on the particle fluid surface to do this now but if you want more of a manual approach, take the SDF that gets written out when you simulate your flip simulation (surface), do a gradient on that sdf and use that to delete any particles based on the threshold of that gradient. That should speed up things exponentially with your meshing. If you want an alternative, give this thread a look and try out what bunker suggests: http://forums.odforce.net/topic/26814-meshing-huge-amount-of-flip-particle And I agree with @Federico on caching out your simulation to a compressed simulation first and then meshing. I don't understand why you wouldn't want to do this. If you don't cache out and you surface your simulation live, you are denying yourself the ability to even tweak your mesh. You are at the mercy of whatever you have your particle fluid surface set to. It is only beneficial to you to cache out your simulation first.
  18. You can still use the method in that video. Used it recently and it worked fine.You have to use packed geo and select the rbd packed object in dops before pressing the shelf button for exporting that comes with the whole package. That was the only way I could get it to export. Whether or not it is the best way, I am not sure. I haven't used Laidlaws FBX exporter but, the interface looks a bit cleaner so it may be worth a shot. Also, I think h16 may come with more game development friendly tools so I would be on the lookout for that in the next couple of weeks.
  19. Unfortunately I don't have access to Houdini 12.5 anymore but, I opened this in 15 and didn't see any issues. I am uploading the file that worked for me. I did some tweaking in here and cleaned up some stuff. Also turned your rbd resolution down on some of the objects to something a little more manageable.. SOLUCION_RB.hip edit: took out a huge chunk of text because I just got schooled in a part of flip that was unbeknownst to know me. The more you know.
  20. You need to check off collision guide if you want to run the simulation in the viewport. When you have Collision Guide turned on, houdini calculates that mesh you are seeing in the viewport per frame. I DLed your file and turned that off and everything seems to play fine (after putting the switch you have in there back to 0).
  21. Did you copy and paste some things from another file?
  22. I am unsure what you mean by it isn't working? Benny Yangs asset exports out an .fga file. Is it not exporting that format for you? Does it error out trying to export that? If it does export, are you having trouble importing inside Unreal? Too many questions that need to be answered. If you are having issues importing fga files into Unreal: https://wiki.unrealengine.com/Creating_Vector_Fields_(Tutorial)#Importing_an_.FGA_File_into_UE4
  23. No reason why the saved version of the bgeo and the live version vdb creation shouldn't work. Whenever you run into stuff like this and you know it should be working, why not go back to the basics and create a simple scene to test it out? If the simple scene doesn't work for you then upload that here. It is really hard to debug FLIP simulation issues by just looking at a screenshot. Out of all the times I have done FLIP simulations, I have never used collision guide either. I am guessing the resurgence of this is from the recent Jeff Wagner webinar. Its not awful if you want to go that route, I just don't see the point. If I want to know what my collision is going to look like, I take a look at it on my static object. That gives me the real representation that I am looking for.
  24. No, I would have your main sim dop network separate from the spray/foam/etc dop network (basically the way you have it now). If you could upload a sample file of it not working, that would help trying to figure out what is going on.
  25. If you are running the foam out from the same flip solver and dop network and it is colliding, no reason why the spray shouldn't collide also. Just did a quick test on my end and it works just fine.