Here is my plate in Houdini, seen from a matchmoved camera. The pyramidal trackers are from Syntheyes (matchmove software):
Here is a mesh I generated from the plate itself, using PhotoScan:
This mesh bears no relationship to the trackers at all, so I need to position it into place so that it matches my camera. Right, now I'm doing this by eyeballing, which is obviously crazy tedious and also imprecise.
Syntheyes offers a mechanism by which I can import this mesh into the matchmove scene, and associate a given tracker with a point on the surface of this mesh, which constrains that bit of the mesh to that tracker. Ostensibly, I can do this for several points on the mesh to leverage the trackers to move the mesh into place. But I figure Houdini could surely do this as well, and I'm curious how.
Found 206 posts.
Search results Show results as topic list.
Technical Discussion » Best-fitting a mesh to some points
- dhemberg
- 207 posts
- Offline
Technical Discussion » Best-fitting a mesh to some points
- dhemberg
- 207 posts
- Offline
Hello!
I'm interested in best-fitting a mesh to a series of points in 3d space (using only translation/rotation/scaling of the mesh, rather than warping it).
To elaborate: I have some data generated by matchmove software: a camera, and several trackers that exist in 3d space. The trackers indicate the position of various features in the plate for my shot. I also have a mesh – generated using photogrammetry techniques – that I would like to position in my scene. I'd like to use the trackers as indicators for where this mesh should be positioned.
I *think* what I'd like to do is associate (constrain?) some of the points on my mesh to their corresponding trackers in my matchmove data (e.g. “This feature of this mesh should be constrained to this tracker.”). This, at least, is the trategy described in most matchmove software literature I see.
What tools or techniques should I explore for accomplishing this in Houdini?
Thanks!
–a
I'm interested in best-fitting a mesh to a series of points in 3d space (using only translation/rotation/scaling of the mesh, rather than warping it).
To elaborate: I have some data generated by matchmove software: a camera, and several trackers that exist in 3d space. The trackers indicate the position of various features in the plate for my shot. I also have a mesh – generated using photogrammetry techniques – that I would like to position in my scene. I'd like to use the trackers as indicators for where this mesh should be positioned.
I *think* what I'd like to do is associate (constrain?) some of the points on my mesh to their corresponding trackers in my matchmove data (e.g. “This feature of this mesh should be constrained to this tracker.”). This, at least, is the trategy described in most matchmove software literature I see.
What tools or techniques should I explore for accomplishing this in Houdini?
Thanks!
–a
Technical Discussion » Distance-From-Camera adaptive divisions
- dhemberg
- 207 posts
- Offline
Hi there;
A studio I worked at a while back had a pretty awesome tool we used when creating water meshes; it created what's called an “annulus”, basically a arc-shaped mesh originating from a camera, with the left and right edges of the arc fitting to the FOV of the camera, and the near and far edges of the arc relative to the camera's near/far clipping planes (these were overridable by the user as needed). The most awesome feature of this thing, though, was that it didn't create divisions in the mesh uniformly, but rather exponentially. Basically it was like a really interactive, low-res version of render-time tessellation. It was useful to get fine wave detail close to camera, but less detail further away.
I can't quite figure out how to do something similar in Houdini (and I really wish this was just a native node in it, as part of the Ocean kit). I know I can put down an over-tessellated grid, then polyreduce it back, but heaps of other TDs on these forums have pointed out the inefficiency of working like this. I'm curious if anyone has landed on a more elegant option that simulates this behavior?
A studio I worked at a while back had a pretty awesome tool we used when creating water meshes; it created what's called an “annulus”, basically a arc-shaped mesh originating from a camera, with the left and right edges of the arc fitting to the FOV of the camera, and the near and far edges of the arc relative to the camera's near/far clipping planes (these were overridable by the user as needed). The most awesome feature of this thing, though, was that it didn't create divisions in the mesh uniformly, but rather exponentially. Basically it was like a really interactive, low-res version of render-time tessellation. It was useful to get fine wave detail close to camera, but less detail further away.
I can't quite figure out how to do something similar in Houdini (and I really wish this was just a native node in it, as part of the Ocean kit). I know I can put down an over-tessellated grid, then polyreduce it back, but heaps of other TDs on these forums have pointed out the inefficiency of working like this. I'm curious if anyone has landed on a more elegant option that simulates this behavior?
Technical Discussion » Seeking "Wrecking ball" (Wire/RDB Constraint) example
- dhemberg
- 207 posts
- Offline
Thanks again for these examples, I'm starting to wrap my head around this.
How do I constrain hero geometry to what's clearly proxy geo in your example? The wrecking ball proxy, for example, spins around independent of the chains as if it's on a gimbal. Physically, though, I'd need to fasten the chains to the ball such that it didn't spin freely. This would mean:
–The points where the chains connect to the ball need to maintain a constant relationship to each other (they cannot slip around the surface of the ball)
–The ball hero geo needs to be constrained to the proxy, with proper rotations
Thank you!
How do I constrain hero geometry to what's clearly proxy geo in your example? The wrecking ball proxy, for example, spins around independent of the chains as if it's on a gimbal. Physically, though, I'd need to fasten the chains to the ball such that it didn't spin freely. This would mean:
–The points where the chains connect to the ball need to maintain a constant relationship to each other (they cannot slip around the surface of the ball)
–The ball hero geo needs to be constrained to the proxy, with proper rotations
Thank you!
Technical Discussion » Seeking "Wrecking ball" (Wire/RDB Constraint) example
- dhemberg
- 207 posts
- Offline
Cool! Thank you for this!
I realize in describing this that ‘chain’ is misleading (the thing I'm actually trying to simulate are braided steel cables, not specifically-individual links). That's why I've been asking about the wire solver specifically. But I suppose it should be easy enough to create some curves that follow the chain links you're creating here, though I'm curious if this is a ‘heavy hammer’ solution for the case of braided cable/rope rather than individual links?
Regardless, thanks for these very helpful illustrations of setting this up, super-useful for me to learn!
I realize in describing this that ‘chain’ is misleading (the thing I'm actually trying to simulate are braided steel cables, not specifically-individual links). That's why I've been asking about the wire solver specifically. But I suppose it should be easy enough to create some curves that follow the chain links you're creating here, though I'm curious if this is a ‘heavy hammer’ solution for the case of braided cable/rope rather than individual links?
Regardless, thanks for these very helpful illustrations of setting this up, super-useful for me to learn!
Technical Discussion » Seeking "Wrecking ball" (Wire/RDB Constraint) example
- dhemberg
- 207 posts
- Offline
Thank you sir, this is awesome. A followup question, for clarity:
Suppose I want my wrecking ball to begin up in the air, above the constraint points illustrated in your GIF above. So, when the ball first ‘settles’, the two ‘chains’ holding it go slack, then tighten as the ball falls.
It seems, from the examples you note above, that the order of operations here is:
–set up the ball first, using (probably) spring constraints.
–figure out where I want to ‘connect’ the ends of the chain that will ultimately suspend the ball, both on the surface of the ball itself and from the points from which the chains originate.
–Create curves connecting the ball to it's anchor points.
–setup a wire sim on these curves.
Or, worded more simply, the ball/constraints drive the simulation of the wires suspending it…is that right?
I guess that's my ultimate question: in the case of a wrecking ball, does the ball drive the wire sim of the chain(s) suspending it, or are the chains simulated first, and the ball simulated off the resulting wire sim? Other analogous examples might be a yoyo, or any rope with a weight on it. In Houdini DOP parlance, this situation seems to be two separate sims (the constrained ‘weight’, and the wire sim of the suspending rope/chain), and I'm having a hard time imagining which drives which.
Thanks!
Suppose I want my wrecking ball to begin up in the air, above the constraint points illustrated in your GIF above. So, when the ball first ‘settles’, the two ‘chains’ holding it go slack, then tighten as the ball falls.
It seems, from the examples you note above, that the order of operations here is:
–set up the ball first, using (probably) spring constraints.
–figure out where I want to ‘connect’ the ends of the chain that will ultimately suspend the ball, both on the surface of the ball itself and from the points from which the chains originate.
–Create curves connecting the ball to it's anchor points.
–setup a wire sim on these curves.
Or, worded more simply, the ball/constraints drive the simulation of the wires suspending it…is that right?
I guess that's my ultimate question: in the case of a wrecking ball, does the ball drive the wire sim of the chain(s) suspending it, or are the chains simulated first, and the ball simulated off the resulting wire sim? Other analogous examples might be a yoyo, or any rope with a weight on it. In Houdini DOP parlance, this situation seems to be two separate sims (the constrained ‘weight’, and the wire sim of the suspending rope/chain), and I'm having a hard time imagining which drives which.
Thanks!
Technical Discussion » Seeking "Wrecking ball" (Wire/RDB Constraint) example
- dhemberg
- 207 posts
- Offline
Hi there! I'm in search of an example of how to set up a ‘wrecking ball’ effect in Houdini. The thing I'd like to do is have a single object suspended by TWO wires. The ‘far’ end of the wires will be animated.
It's not clear to me, based on what I've found so far, whether I first set up my ‘ball’ with some kind of flexible (spring?) constraint, then attach wires and let them sort of go along for the ride (which seems backwards to me), or whether there's a way for me to pin my ball to the ends of the wires, and have it be properly suspended from them both.
Might anyone be able to point me to any examples demonstrating something like this?
Thank you!
It's not clear to me, based on what I've found so far, whether I first set up my ‘ball’ with some kind of flexible (spring?) constraint, then attach wires and let them sort of go along for the ride (which seems backwards to me), or whether there's a way for me to pin my ball to the ends of the wires, and have it be properly suspended from them both.
Might anyone be able to point me to any examples demonstrating something like this?
Thank you!
Houdini Learning Materials » Configuring Renderman for Houdini
- dhemberg
- 207 posts
- Offline
Hi there;
I too am trying to get up and running with RIS. I had it working fine in 15.5, but now I can't produce a non-black image in H16. The renderer is indeed running, and I can see an alpha, and I get no error messages. I have an integrator set, lights created, shaders assigned, but no color data being produced.
Might anyone be able to share a HIP that should produce an image?
I too am trying to get up and running with RIS. I had it working fine in 15.5, but now I can't produce a non-black image in H16. The renderer is indeed running, and I can see an alpha, and I get no error messages. I have an integrator set, lights created, shaders assigned, but no color data being produced.
Might anyone be able to share a HIP that should produce an image?
Technical Discussion » Extinctive volume in H16
- dhemberg
- 207 posts
- Offline
Hi there;
I'm working on an effect that involves the rendering of a fluid with a heterogenous volume. An example of such a volume is attached below. We can see that the various liquids (which are separated by density) also have various amounts of scatter (“cloudiness”) vs extinction (sometimes people call this “transmission”)… e.g. some liquids might be like wine or tea (in that you can see through them, but they heavily-tint the refraction result), while others are more like orange juice or milk (in that they're cloudy).
The way I think I'd like to approach this is by using multiple volumes, each with their own volume shader. These volumes will overlap, to help create the ‘bleeding’ of one volume into another.
The Subsurface lobe in the Classic shader excellently exposes Extinction/Scatter/Emission/Phase parameters, but there's no out-of-the-box solution for this in a volume context. So, I'm trying to build it myself.
I notice that if I set the Density Scale signature of the VolumeShaderCore node to “vector”, I get a RGB parameter that I can use to simulate extinction, which is awesome. If I set “smoke color” (which is effectively “scatter”) to zero, I am able to render a volume that seems to behave a bit like wine or ink in water. It's not QUITE right, in that–because it's being used to drive volume opacity–it can't be pushed over 1, so it's not QUITE what I'm after, but it does get me close.
Where I'm having trouble, however, is refracting this extinction-only volume inside a glass. No matter what I do, the volume seems to only render black/grey, rather than a color. I'm attaching a second image that illustrates this: you can see part of my volume (the cyan bit, a result of setting Density Scale to (1, 0, 0)) visible to primary rays is kinda-sorta working, but the bit of the volume inside the glass bubble renders black.
I assumed this was due to a shadowing or caustics issue, but I've tried all manner of exploring caustic lights, full-on path tracing, turning off shadows on my light entirely, etc…nothing seems to make a difference.
I'm curious if this post might get within earshot of the shader writers at SideFX such that they may be able to offer some advice or, even better, a standalone node that replicates the Subsurface Extinction/Scatter/Emission/Phase controls for a volume shader. Alternatively, if anyone has some ideas about how I may do this, I'd love to hear.
I'm working on an effect that involves the rendering of a fluid with a heterogenous volume. An example of such a volume is attached below. We can see that the various liquids (which are separated by density) also have various amounts of scatter (“cloudiness”) vs extinction (sometimes people call this “transmission”)… e.g. some liquids might be like wine or tea (in that you can see through them, but they heavily-tint the refraction result), while others are more like orange juice or milk (in that they're cloudy).
The way I think I'd like to approach this is by using multiple volumes, each with their own volume shader. These volumes will overlap, to help create the ‘bleeding’ of one volume into another.
The Subsurface lobe in the Classic shader excellently exposes Extinction/Scatter/Emission/Phase parameters, but there's no out-of-the-box solution for this in a volume context. So, I'm trying to build it myself.
I notice that if I set the Density Scale signature of the VolumeShaderCore node to “vector”, I get a RGB parameter that I can use to simulate extinction, which is awesome. If I set “smoke color” (which is effectively “scatter”) to zero, I am able to render a volume that seems to behave a bit like wine or ink in water. It's not QUITE right, in that–because it's being used to drive volume opacity–it can't be pushed over 1, so it's not QUITE what I'm after, but it does get me close.
Where I'm having trouble, however, is refracting this extinction-only volume inside a glass. No matter what I do, the volume seems to only render black/grey, rather than a color. I'm attaching a second image that illustrates this: you can see part of my volume (the cyan bit, a result of setting Density Scale to (1, 0, 0)) visible to primary rays is kinda-sorta working, but the bit of the volume inside the glass bubble renders black.
I assumed this was due to a shadowing or caustics issue, but I've tried all manner of exploring caustic lights, full-on path tracing, turning off shadows on my light entirely, etc…nothing seems to make a difference.
I'm curious if this post might get within earshot of the shader writers at SideFX such that they may be able to offer some advice or, even better, a standalone node that replicates the Subsurface Extinction/Scatter/Emission/Phase controls for a volume shader. Alternatively, if anyone has some ideas about how I may do this, I'd love to hear.
Technical Discussion » Preventing volume loss in long FLIP sim
- dhemberg
- 207 posts
- Offline
Hey sir;
Ah, I indeed see that. I guess I was hung up on 1) the fact that a magnitude of 9.8 gave me some nice shaping when using sourceVolume colliders, and 2) I tried to model this whole thing in a reasonable space (a few meters), thinking that using real-world values would yield results that looked appropriate to scale. The latter is, unfortunately, a habit I repeatedly have to shake doing water stuff, I've noticed.
In any case, mostly I wanted to confirm I wasn't still doing anything ‘wrong’, and that this force magnitude knob was indeed the right one to be turning. Lowering it an order of magnitude does indeed give me lots of nice splashing, which looks totally great. This sim is also running fast enough for me to iterate in a more artistic way now, which is great. And, the best bit is, I've learned more about the FLIP solver in the past week with your help than I managed to over the course of several years working in a large studio. So, a thousand thanks for all your superb help! I truly appreciate it so much!
–a
Ah, I indeed see that. I guess I was hung up on 1) the fact that a magnitude of 9.8 gave me some nice shaping when using sourceVolume colliders, and 2) I tried to model this whole thing in a reasonable space (a few meters), thinking that using real-world values would yield results that looked appropriate to scale. The latter is, unfortunately, a habit I repeatedly have to shake doing water stuff, I've noticed.
In any case, mostly I wanted to confirm I wasn't still doing anything ‘wrong’, and that this force magnitude knob was indeed the right one to be turning. Lowering it an order of magnitude does indeed give me lots of nice splashing, which looks totally great. This sim is also running fast enough for me to iterate in a more artistic way now, which is great. And, the best bit is, I've learned more about the FLIP solver in the past week with your help than I managed to over the course of several years working in a large studio. So, a thousand thanks for all your superb help! I truly appreciate it so much!
–a
Technical Discussion » Preventing volume loss in long FLIP sim
- dhemberg
- 207 posts
- Offline
Hi @jlait;
I've spent today playing with varying stickOnCollision values (including disabling it completely) as well as switching back to the splashy kernel for the flipSolver. While I can still seem to get some very lovely vorticular motion, I can't seem to get any ‘loft’ or splashes happening; it's as if the particles are aggressively constrained to the original surface at the start of the sim.
I've tried a few things to change this: I tried eliminating the gasEqualizeVolume, but this doesn't seem to get me any splashes happening. I've tried lower the magnitude of my popVOP force, but this just makes things move slower overall, rather than seeing any berming or splashing.
You made a comment about the scaling of obj-level colliders; I've indeed avoided that, but I DO animate them by way of a few stacked upstream transform nodes; could this be problematic?
I've gone so far as replacing my gear geometry with a much-cruder block shape, which I feel should definitely offer some large splashing, but still I see only vorticular stuff. Might you have any further advice about what might be happening? The water doesn't seem to be being ‘pushed’ the way I would expect it to, especially looking at some of the in-help examples for flip sims.
https://www.dropbox.com/s/fzgt9pha5a61845/waterWheel_08.hiplc?dl=0 [www.dropbox.com]
Attached, in comparison, is the level of berming/swell I was getting back when I started this adventure; it looked great, but lost volume over time, which is what sent me down this path to begin with.
cheers;
–a
I've spent today playing with varying stickOnCollision values (including disabling it completely) as well as switching back to the splashy kernel for the flipSolver. While I can still seem to get some very lovely vorticular motion, I can't seem to get any ‘loft’ or splashes happening; it's as if the particles are aggressively constrained to the original surface at the start of the sim.
I've tried a few things to change this: I tried eliminating the gasEqualizeVolume, but this doesn't seem to get me any splashes happening. I've tried lower the magnitude of my popVOP force, but this just makes things move slower overall, rather than seeing any berming or splashing.
You made a comment about the scaling of obj-level colliders; I've indeed avoided that, but I DO animate them by way of a few stacked upstream transform nodes; could this be problematic?
I've gone so far as replacing my gear geometry with a much-cruder block shape, which I feel should definitely offer some large splashing, but still I see only vorticular stuff. Might you have any further advice about what might be happening? The water doesn't seem to be being ‘pushed’ the way I would expect it to, especially looking at some of the in-help examples for flip sims.
https://www.dropbox.com/s/fzgt9pha5a61845/waterWheel_08.hiplc?dl=0 [www.dropbox.com]
Attached, in comparison, is the level of berming/swell I was getting back when I started this adventure; it looked great, but lost volume over time, which is what sent me down this path to begin with.
cheers;
–a
Edited by dhemberg - 2017年5月31日 22:54:26
Technical Discussion » Preventing volume loss in long FLIP sim
- dhemberg
- 207 posts
- Offline
Hi again;
I reran my sim last night using all your recommended optimizations and adjustments, including breaking the colliders into their own groups, rotating them at the obj level, and bringing them in individually without marking them as deforming objects. My sim is about 700 frames in and seems to be remaining incredibly stable, with zero leakage and minimal volume loss. Thank you for this!
I notice that in previous versions, the central spokes/cogs caused some nice turbulence and berming around those parts (which is why I include them). With your corrections, the sim seems somehow ‘calmer’; there's less turbulence and almost no berming, which makes the sim overall less interesting. I tried increasing velocityScale to 1.5 under the volumeMotion tab of the solver, but this didn't seem to have much effect. I presume I must be getting collider velocities despite not using deforming geometry with trail sops to manually generate their velocity, right? Would the less-energetic sim be the result of switching to APIC? I'm wondering if it's possible to preserve the relative stability while still getting some nice splashing happening?
Thanks!
–a
I reran my sim last night using all your recommended optimizations and adjustments, including breaking the colliders into their own groups, rotating them at the obj level, and bringing them in individually without marking them as deforming objects. My sim is about 700 frames in and seems to be remaining incredibly stable, with zero leakage and minimal volume loss. Thank you for this!
I notice that in previous versions, the central spokes/cogs caused some nice turbulence and berming around those parts (which is why I include them). With your corrections, the sim seems somehow ‘calmer’; there's less turbulence and almost no berming, which makes the sim overall less interesting. I tried increasing velocityScale to 1.5 under the volumeMotion tab of the solver, but this didn't seem to have much effect. I presume I must be getting collider velocities despite not using deforming geometry with trail sops to manually generate their velocity, right? Would the less-energetic sim be the result of switching to APIC? I'm wondering if it's possible to preserve the relative stability while still getting some nice splashing happening?
Thanks!
–a
Technical Discussion » Preventing volume loss in long FLIP sim
- dhemberg
- 207 posts
- Offline
Oh, also: When using the “deforming objects” shelf tool, the flip solver's collision detection method is left at the default value of “particle”. Because I was advised, in previous versions of Houdini, to use the Source Volume method of collisions, I changed it to “move outside volume” for the scene I sent you.
Can you say which is preferable if I'm using this Static Object method of colliders? I'm a little hazy on what exactly is happening (there's a VDB generated by the collisionSource node, but also some geometry; you advise above that I might statically-create a VDB, and then rotate it, which would mean the vdb wouldn't have any velocity field, so presumably this new method involves calculating a velocity field independently of a collision SDF, true?)
All of this is to ask: if I leave the solver set to using “particle” as the collision detection method, “kill unmoveable particles” seems to be greyed out. Why?
Thanks!
–a
Can you say which is preferable if I'm using this Static Object method of colliders? I'm a little hazy on what exactly is happening (there's a VDB generated by the collisionSource node, but also some geometry; you advise above that I might statically-create a VDB, and then rotate it, which would mean the vdb wouldn't have any velocity field, so presumably this new method involves calculating a velocity field independently of a collision SDF, true?)
All of this is to ask: if I leave the solver set to using “particle” as the collision detection method, “kill unmoveable particles” seems to be greyed out. Why?
Thanks!
–a
Technical Discussion » Preventing volume loss in long FLIP sim
- dhemberg
- 207 posts
- Offline
This is so, so awesome sir, I can't thank you enough for your thoroughness. May I ask one followup question?:
You know, I thought to try this, but then stopped myself thinking that rotating a VDB volume might be somehow bad, or at any rate would involve re-rasterizing the collision geometry into the solver space. Is that not true? Or, do you suspect that the performance gain offset any quality loss in doing this? I'm not at all opposed to doing it (and, indeed, would love knowing that this is a trick I can rely on in the future).
jlait
7) Collisions. In this case you have multiple rigid bodies that you've put into a single collider, forcing VDB creation every frame and risking something odd going on. For example, the VDB rasterization may pop between frames giving some spurious motion. Instead, if you could express them as separate objects and bring them in as non-deforming but rotating objects, it would be a help. This also means you don't have to worry about the extra points as the objects won't be moving locally. I understand this may not scale to other setups, however.
You know, I thought to try this, but then stopped myself thinking that rotating a VDB volume might be somehow bad, or at any rate would involve re-rasterizing the collision geometry into the solver space. Is that not true? Or, do you suspect that the performance gain offset any quality loss in doing this? I'm not at all opposed to doing it (and, indeed, would love knowing that this is a trick I can rely on in the future).
Edited by dhemberg - 2017年5月30日 13:09:38
Technical Discussion » Preventing volume loss in long FLIP sim
- dhemberg
- 207 posts
- Offline
Hi Jlait;
Thanks so much for your patience and tenacity helping me here. I fear that my attempt to get you a good test scene has misdirected your troubleshooting efforts; the substepping thing is one I'm aware of, and exploring the CollisionSource node this weekend taught me about scattering points to gain velocity fidelity (a nice trick, I'm happy to have learned that). To avoid wasting more of your time, I've made a ZIP file that contains my actual production HIP file, a bgeo of some source geometry I'm using, and an example AVI file that shows my sim failing. To avoid weighing down this forum, I've placed the file here:
https://www.dropbox.com/s/es232y5uyydt2k3/flipProblem_production_1.zip?dl=0 [www.dropbox.com]
(this file includes a “_fbx” matchmoved camera which can be ignored…the meat is in “wheel_master”)
To the best of my knowledge, I've followed your advice throughout this thread:
–scattered points on collision geo to enhance velocity fidelity
–no $F dependencies
–use popVOP for my radial gravity force I'm trying to use
–no sourceVolumes, but rather using staticSolver for collisions
If you open this HIP and play it, you'll see that within 100 frames from sim start (which is fr 235), the sim becomes unusably unstable. This instability is much more exacerbated from where I started with this file, so I'm curious what you find that you may be able to advise me on repairing here.
Edit: To add more clues here: in the above-mentioned file, I have my min/max substeps on my flip solver set to 1/1, and substeps on my DOPnetwork itself also set to 1. I did a second test where I reset min/max substeps on the FLIP solver to their default values of 1/2, and set substeps on the DOPnet to 4. This produces the velocity discontinuity boundary artifacts that I mentioned earlier, as noted in the attached image.
Edit 2: I notice that when I compare the CollisionGuide as generated by the static solver to the collisionGuide as generated by the actual FLIP object, the two seem to be different (though they seem to have similar grid sizes). This seems either problematic or misleading: is the collision geometry being rendered onto two different grids (and, if so, wouldn't that inherently degrade accuracy)?
Thanks!
–a
Thanks so much for your patience and tenacity helping me here. I fear that my attempt to get you a good test scene has misdirected your troubleshooting efforts; the substepping thing is one I'm aware of, and exploring the CollisionSource node this weekend taught me about scattering points to gain velocity fidelity (a nice trick, I'm happy to have learned that). To avoid wasting more of your time, I've made a ZIP file that contains my actual production HIP file, a bgeo of some source geometry I'm using, and an example AVI file that shows my sim failing. To avoid weighing down this forum, I've placed the file here:
https://www.dropbox.com/s/es232y5uyydt2k3/flipProblem_production_1.zip?dl=0 [www.dropbox.com]
(this file includes a “_fbx” matchmoved camera which can be ignored…the meat is in “wheel_master”)
To the best of my knowledge, I've followed your advice throughout this thread:
–scattered points on collision geo to enhance velocity fidelity
–no $F dependencies
–use popVOP for my radial gravity force I'm trying to use
–no sourceVolumes, but rather using staticSolver for collisions
If you open this HIP and play it, you'll see that within 100 frames from sim start (which is fr 235), the sim becomes unusably unstable. This instability is much more exacerbated from where I started with this file, so I'm curious what you find that you may be able to advise me on repairing here.
Edit: To add more clues here: in the above-mentioned file, I have my min/max substeps on my flip solver set to 1/1, and substeps on my DOPnetwork itself also set to 1. I did a second test where I reset min/max substeps on the FLIP solver to their default values of 1/2, and set substeps on the DOPnet to 4. This produces the velocity discontinuity boundary artifacts that I mentioned earlier, as noted in the attached image.
Edit 2: I notice that when I compare the CollisionGuide as generated by the static solver to the collisionGuide as generated by the actual FLIP object, the two seem to be different (though they seem to have similar grid sizes). This seems either problematic or misleading: is the collision geometry being rendered onto two different grids (and, if so, wouldn't that inherently degrade accuracy)?
Thanks!
–a
Edited by dhemberg - 2017年5月30日 08:04:17
Technical Discussion » Preventing volume loss in long FLIP sim
- dhemberg
- 207 posts
- Offline
Spending the weekend converting my setup over to using that created by the shelf tools you mention (and fairly extensively trying to debug the very different and even more unstable behavior doing so led to), I think I must conclude this advice does't seem to be moving me in the right direction. The Deforming Object shelf tool, as you say, eschews Source Volume colliders in favor of Static Objects and the Collision Source macro. The latter of which is quite interesting, and through it I learned some new techniques, but the Static Object setup in my DOP sim now produces odd discontinuities in the collision velocity field for reasons that aren't clear to me. Source Volumes seem to produce drastically smoother and more stable collision velocity fields, with no visible discontinuities. It feels like the Static Object is extrapolating velocities in an odd way into empty cells.
Edited by dhemberg - 2017年5月29日 07:33:27
Technical Discussion » Preventing volume loss in long FLIP sim
- dhemberg
- 207 posts
- Offline
Another, even simpler test case for this problem. Note, if viewing though the ‘holes’ in the Y axis, the ‘popping’ velocity instabilities and slow drain of the particles through the collider SDF and into the origin. I can't see this behavior with the Gravity force.
Technical Discussion » Preventing volume loss in long FLIP sim
- dhemberg
- 207 posts
- Offline
Hi sir;
Thank you for this. Indeed, I had things wired up this way before sending that last note, but saw no discernible difference in my sim, so I assumed I'd done something wrong, and added the (redundant) popSolver.
I've taken the liberty of tearing apart my scene and simplifying it to something quite a bit, well, simpler, and with no incoming dependencies. It demonstrates the oddness I'm seeing. Note that I'm gotten rid of the asymmetry you noted in the VOP, and things are still unstable. Could this be due to the fact that my collider is rotating, rather than exhibiting linear motion? The more I tear things apart and try to debug, the more confused I get at what I felt should be a relatively straightforward sim.
Thank you for this. Indeed, I had things wired up this way before sending that last note, but saw no discernible difference in my sim, so I assumed I'd done something wrong, and added the (redundant) popSolver.
I've taken the liberty of tearing apart my scene and simplifying it to something quite a bit, well, simpler, and with no incoming dependencies. It demonstrates the oddness I'm seeing. Note that I'm gotten rid of the asymmetry you noted in the VOP, and things are still unstable. Could this be due to the fact that my collider is rotating, rather than exhibiting linear motion? The more I tear things apart and try to debug, the more confused I get at what I felt should be a relatively straightforward sim.
Technical Discussion » Preventing volume loss in long FLIP sim
- dhemberg
- 207 posts
- Offline
Hi sir, thanks once again. I'm trying this as you advise, and while it seems to replicate the overall force effects of my VOPforce, it also produces ballistic pockets of velocity. In the event that you have a moment to verify I'm not doing anything totally insane, I'm attaching a culled version of my HIP file here. The full version unfortunately relies on some rather sizable cached geometry, which I'd be happy to share but which I presume isn't appropriate to do so using the forum mechanism (perhaps Dropbox or something would be better?)
Technical Discussion » Preventing volume loss in long FLIP sim
- dhemberg
- 207 posts
- Offline
Actually, investigating further, it appears that my collider might not be the problem, but rather a VOP force I'm using to impart forces on my flip sim. This VOP force outputs a Force, and is dependent on P of the incoming geometry. I'm using it in place of the default Gravity force. Is this an objectionable way to work? What would be the ideal way to create a custom force for pushing around FLIP particles?
-
- Quick Links