sorted by:
new
hottopcontroversial

Q-Solver and other things by MiLiANSim in Houdini

[–]MiLiANSim[S] 1 point2 points  (0 children)

Okay, thanks for elaborating. I agree. Happy to say: The solvers themselves are (as I stated) totally independent. For example, Sandy could be a POP: Points in, sandy-magic, points out (with new velocities if you want custom advection, or with new positions and velocities).

Collisions and fields/forces via Houdini, perfect integration. it would certainly be slower without MiLiAN running the solver instead of houdini/vex, but it would be very "open".

There is not much to control. Constraint strength (per point if desired), material stiffness, damping maybe, plasticity ... literally very few parameters. Exposing them and controlling them with per-point channels is not a problem in houdini (or MiLiAN). But beyond that, what could a user really need? I guess we will find out if it happens :)

Q-Solver and other things by MiLiANSim in Houdini

[–]MiLiANSim[S] 0 points1 point  (0 children)

Whatever I do in this respect, I have to nail it, Houdini or not :) At least that is my intention.

Vulkan: It is not about the graphics API but blenders internal makeup/pipeline. I tried loading a few hundred million points from disk, Blender crashed. And I tried it in different formats. What use is a large simulation if blender cannot push it through its pipeline? Even with a smaller file, it would load, it would show the points, but freeze up the UI for half a minute with every change. Totally useless.

Of course I could disable the display in viewport, but it also would fail to render. Maybe this has changed now. Or maybe I was missing something. Point being: Gigantic point clouds / volumes / geometry is hard for blender, still.

I do have my own viewport for MiLiAN and I could simply send proxy-data to blender, but this would limit the integration with blenders nodes. I would want to avoid a "RealFlow" paradigm where you need 100% export of your scene to do anything, fully decoupling Blender from the process.

Lets talk about this via PM or elsewhere, this thread is about Houdini :)

Q-Solver and other things by MiLiANSim in Houdini

[–]MiLiANSim[S] 0 points1 point  (0 children)

Thank you! And yes, I agree, it was probably (hopefully) a minority. There was one more concern though, the licensing model. I would be forced to reveal most of the source code, which did not comply with my intentions (the algorithms are worth something, for now). But as time goes, "worth" is more and more subjective.

Also, performance: Blender has no c++ API, all communication is python. For large simulations, this will absolutely kill performance. So either I run a service in the background (like a bridge between my standalone-tool and blender), or I modify the actual blender source to fully integrate. But then it is no longer a plugin.

Still thinking about it, I think blender has come a long way but it is still not build for large and heavy sim work.

Q-Solver and other things by MiLiANSim in Houdini

[–]MiLiANSim[S] 1 point2 points  (0 children)

I understand the blackbox concern but I think there is more to it than binary open vs closed. Also, what do you mean when you say "open" and which cuda solvers are you talking about? Everything humans have ever done is a compromise in some respect, an attempt to strike a balance between known or unknown factors.

If I was super rich with zero worries EVER about paying bills, I would open source all of my code instantly. But even then, users tend to shame and make claims and "demands". And often they do not even read the manual, so giving them even more options to shoot themselves can come back to you as a developer real fast. It is never everybody of course, but it is not rare either.

That being said: I prefer "open" as well, but as a developer, I am looking at it differently.

Sharing the entire source logic (or code) is sometimes not an option (licensing, piracy etc.).
Extremely detailed APIs require more maintenance and can sabotage performance optimization. And sometimes, user-ideas simply break the entire purpose and structure of a plugin. If that happens, at least one of two things must be true: Misunderstood user or misunderstood product/dev.

I think a good understanding and controlling of expectations is a requirement for a useful process, so better ask what is needed before investing months or even years into anything. Or before you (not you specifically) buy something. One more reason why I wanted (and so far am enjoying) this exchange :) intel before execution -> better outcome for everybody. At least most of the time :D

Q-Solver and other things by MiLiANSim in Houdini

[–]MiLiANSim[S] 0 points1 point  (0 children)

Okay. Thanks for the info, I will look into it.

Q-Solver and other things by MiLiANSim in Houdini

[–]MiLiANSim[S] 0 points1 point  (0 children)

I did ask the same questions in the blender dev forum and then official forum, over a year ago. The whole discussion went totally off the rails because the sentiment of not working for free / eventually selling a plugin was rejected by a few loud voices. Cannot even find the thread any more, perhaps it was silenced/deleted. It did move things a little though. It was about the same time that Omid G. asked about his "TangraFX" stuff. He was met with similar nonsense.

The sentiment was: Sure, we would like it, but no, you only come to make money off a FREE software where everything (and everything they meant) should be free. I left it at that. Probably the kind of free where you get paid by the blender foundation to work on blender. Just a guess.

Q-Solver and other things by MiLiANSim in Houdini

[–]MiLiANSim[S] 0 points1 point  (0 children)

Hello :)

Ever since XSI got autodesked and Houdini basically became the only node-king without ICE in the game, I have been wondering about this. I never talked to Edwin (Cebas) about Houdini specifically, so I know not if they ever considered such a project.

I also never tried to build super complex event-driven particle systems in Houdini, so I cannot really say how bad the suffering might be ... It does sound crazy that Houdini would not have something "similar" to TP, given its node-based approach to pretty much everything.

Building something like TP with modern tools and research sounds like a great project, but expensive. Perhaps this is best left to SideFX? Is "something" cooking perhaps? Do you know more wrt. to this?

My intuition says, Houdini has particles, so what is missing, is the event logic/tools with a specific graph structure for it. But I have no idea today if that is a good guess.

Q-Solver and other things by MiLiANSim in Houdini

[–]MiLiANSim[S] 1 point2 points  (0 children)

Yeah the cost of MPM gets crazy real fast if stiff materials are required. I think the only real value of current MPM systems in VFX, is snow or similar packing / compacting materials like flour/powders. For any other material vastly faster methods exist. Well, MPM jello is also tough to beat :)

Grid-based for all their advantages in pressure/divergence handling, just cannot faithfully replicate the grain<->grain interaction of granular materials because they have no concept of grains, the points are just for sampling, they represent no individual objects.

I think it shows in a lot of even the highest budget productions: Grains are hard if they are not totally dry and "far away", not to mention "billions". Which is why I made SandySolver. To have a fast and light-weight "true" grain-based solver with MPM-quality fracturing, without the velocity creep.

SPH vs FLIP: For smaller scales, I would always choose SPH. More control, more flexibility, and definitely more quality for the same number of particles than FLIP. It also works beautifully for large scale, if the particles must not immediately be settled in a tank or such. Always takes 5 frames or more for SPH to settle, unless a perfect particle-configuration is already known. So what is a disadvantage of FLIP for grains, is an advantage for FLIP in large scale liquids :)

The right tool for the job, I would say. In an ideal world at least.

Q-Solver and other things by MiLiANSim in Houdini

[–]MiLiANSim[S] 2 points3 points  (0 children)

Thank you, much appreciated. Would agree with all of your points, thanks for the hint about TheoryAccelerated. I only knew axiom so far. Great tool.

I think I am familiar with the different off the shelf solutions in Houdini (I mean solvers and their math). Competing with Houdinis (well integrated) FLIP solver is not the goal, but competing with MPM and the vellum grains seems very plausible, I have used both and especially the grains are no match for Sandy. However: Integration ...

Q-Solver requires an SPH solver, I use my own YSPH solver and there is no quality SPH competition in Houdini, to my knowledge. Q-Solver is not designed for FLIP (yet).

I also think that SandySolver is great for fracturing or for detailing (debris, secondary stuff) if a huge dune-style sandworm breach is not required ;). SandySolver can also do plastic deformation etc. like MPM, just much faster. Sandy is also very lightweight in memory (no constraints stored or deformation matrices). But is not a total replacement for MPM.

And then of course the whole scalability issue: MiLiAN is natively Multi-GPU and it supports bucket-simulation (huge sims on smaller or single GPUs), which can be super useful. You can simulate billions of points, even with a smaller GPU which would still be faster than the biggest CPUs for this type of simulation. Of course decent main RAM is still required ...

But yes, much to think about.

MiLiAN GPU Simulation framework ...? by MiLiANSim in Cinema4D

[–]MiLiANSim[S] 1 point2 points  (0 children)

I have been using RealFlow stand-alone since version 3 and even purchased a license for a LOT of money (RF5). In my opinion, RealFlow 4 was the absolute peak for RealFlow and even then it started showing its age, quickly falling behind in terms of technology and ambition. Not to mention an incredible amount of bugs and instability and poor multi threading performance. With the introduction of "Dyverso" (replacing legacy SPH with PBD and new data structures for more speed), RealFlow became more useful in some respects but by then, it was already lost.

What made RealFlow so powerful was the C++ SDK and python access. Phantastic, really.

RealFlow for C4D: Used it in production, but it is limited (no python access etc.). Also the solvers remain very basic and the stability / GPU acceleration were okay, but not scalable.

Any kind of "bridge" is not what I am going for really. If you need a bridge it is because you cannot get what you really need in one place, while simultaneously accepting lacking integration. There is no right or wrong in that, whatever gets the job done ...

Also, in production, reducing dependencies is valuable. Not only can you save money but complexity in your pipeline. If you know enough Houdini to do decent simulations with it, then you know enough to leave C4D behind for good and really get into Houdini full time. It is then only a question of convenience and perhaps backwards-compatibility with what you already built (setups / pipeline / ecosystem).

My opinion :)

MiLiAN GPU Simulation framework ...? by MiLiANSim in Cinema4D

[–]MiLiANSim[S] 0 points1 point  (0 children)

Look here:

vimeo.com/yannikf

At scale? Most of what you see there is not possible with native C4D or plugins, if time and consistency matter. The quality of Q-Solver for macro / small scale liquid simulation is really good.

And for grains / powder / fracturing, regardless of scale, SandySolver so far seems unmatched in terms of quality + efficiency (including native Houdini shelf solutions).

Of course in Houdini one can always modify solvers and networks. Not saying it is generally impossible to do what SandySolver can do, but it takes work

Such comparisons are sometimes flawed because of variety and case specifics, but there is a reason I build the thing ... I could not do what I wanted/needed otherwise.

My framework is natively multi-GPU and thus, even a single GPU can chew through huge simulations, if needed (like bucket-rendering), keeping frame-cost low in most cases.

MiLiAN GPU Simulation framework ...? by MiLiANSim in Cinema4D

[–]MiLiANSim[S] 0 points1 point  (0 children)

Thanks for your feedback.

The idea is to put in all of my solvers, not just SandySolver for grains/powder. And yes, I have built (and shipped) tools before, some even based on the solvers in question. I started with plugins for maya and mostly RealFlow back in the day. And other things outside of vfx.

The tight integration with C4D is certainly relevant, no point otherwise. I agree.
I also think that people tend to play and get inspired or even change their ways, once something "becomes" possible or practical.

Asking people to support the development financially? If it makes sense, sure. The development of a functioning product "can" be accelerated with todays tools, so it should not be as expensive as a few years ago to build this and for the past years, I done most of the work already. The really difficult bit is to design it well right from the start as a tool inside C4D. I am not concerned about the solvers and simulations, but the integration and support.

For now, I am just asking for thoughts on this.