Jump to content

More ICE Awesomeness


Solitude

Recommended Posts

  • Replies 55
  • Created
  • Last Reply

Top Posters In This Topic

More ignorance coming! Here:

If I understand this ICEsolverthing correctly, it is a kind of spring-mass model? Can't we build a simple version of this in pops? i.e can we loop through each point's neighbors, calculate each point's average force vector, and presto!

A chewy challenge for me, but a master could surely pull that off?

According to Jeff Lait, what it is in essence is a sph solver with explicitly defined spring constrains between particles, what could be done in dops even now... though I'm not sure how close this comes to ICE solver in that respect. Most probably I would assume that "explicitly" defining constrains should allow me to follow topology, not space proximity. It seams to be a case specially in a cloth examples in Lagoa's teaser.

All of this sounds very promising. Specially after Jeff says it's inspiring... :)

Edited by SYmek
Link to comment
Share on other sites

<shrugs> But from this CG Talk post,

Yep the quote: Using the ICE API is what really makes me think about if Houdini is capable to compete with this at the moment.

We have been waiting for more multithreading capabilities in Houdini for a long time, I honestly expected to have miltithread POPs for this new release, although seems we have to wait some time.

But the thing that we really need before anythign else is a multithread safe architecture, in terms of Houdini it means having a multithread safe HDK, which basically what ICE API means I guess. And this is the main obstacle for Houdini so far. I am pretty sure Thiago and cia has been able to write this solver in less time because they rely on the ICE API, so basically the yhave an API that gives them multithrading by free. This is a lot of work saved.

It is a fact that at this point, XSI has a superior technology.

If we get the exmaple of bulding strings constraints between particles, which also the basis of ncloth, youcan di ut actually, even without the need of HDK probably you can do it, but you will always have the problem of dealing with miltithreadong cos POP limitations.

We are dealing with the same problem right now in a huge production. I have seen some prototypes of solvers written for CUDA implemented in SOPs, just using some example code from NVIDIA and integrating them in SOP context, blazing fast, thousands of particles colliding and having almost realtime calculations.

All of this technology is there and has been there for a long time, but Houdini is still trying to catch the miltithread wave :)

Link to comment
Share on other sites

  • 4 weeks later...

I don't understand one thing. Why are we talking about SOPs alternatives, right? Isn't tbe ICE concept and architecture similar to the VOPSOP context? Both are node based and both work on points exclusively. Lagoa seems to be an additional bunch of SDK ICE operators. They are designed to do things fast "black box" comparision (similar to particleSOP node) is totally right here. But because it is the part of ICE network additional scaleability of the system can be achieved. Of course in Houdini there is also SOP level but because it is not multithreaded it can't be currently considered.

Another thing which bugs me is that houdini already has a complex and very sophisticated dynamics solvers which, sadly are too complex and too slow to work with on many short term projects. Especially when effects don't have to be so custom. On the other hand operators design to do simpler stuff such as Spiring and ParticleSOP haven't changed since ages. There are no other tools available for escape users and I guess similar to Lagoa multithreaded solutions could be very interesting alternative.

To conclude i'd like to ask VEX gurus out there whether development of similar concept could be done in VOPs too? Let me put it clear i'm thinking about VOPSOP operators? Are VOPs capable of handling similar stuff? What bottlenecks can we run into?

thanks,

kuba

Link to comment
Share on other sites

Kuba, a while ago there was this thread comparing Vex with ICE:

http://frenchdog.wordpress.com/2009/09/12/ice-vs-vop/

I wonder if we can't just have another ICE-like context. It's messy and redundant but perhaps a way to get multithreaded speed without turning all of Houdini around?

I also read somewhere that VOPs have trouble multithreading certain things like writing attributes. Not sure how true or false that is but when I use VOPs I try to avoid writing out to new attributes, or split up the network. It seemed to work on my particle crumbler, but perhaps I just imagined speed.

Edited by Macha
Link to comment
Share on other sites

I don't understand one thing. Why are we talking about SOPs alternatives, right? Isn't tbe ICE concept and architecture similar to the VOPSOP context?

There is not plain equality between vex (thus vops as such) and ice. While they share similarities, ice is more dops/vops/pops /kinematics multipurpose machinery, whereas vex modifies geometry attributes/groups in a single step. Vex is more uniform and less versatile system, it wasn't meant to be all-purpose dynamic engine. You can imagine a node driven by cvex, with similar possibilities (I dream about kinematics/skin/deform system (two/three nodes) driven by cvex), similar to what is happening now in Houdini's fur or Vex Volume Procedural, but this has less to do with vex itself.

In conclusion, it's hardly possible to develop lagoa like system in pure vex. If so, you will need to pass data between many nodes, possible geometry between sops. This introduces current limitation in that Sops context is all about GPD structure, which is how Houdini stores geometry internally. What was already mentioned in this thread is that GPD is not perfectly shaped to be multi-threaded, so to speak. I suspect this hits Houdini's performance across whole system, like in Dops/Flip solver, when it has to handle millions of particles or POPs where despite of cleverness of your vop-pop algorithm, it will slow down with a couple of millions of points.

SESI needs to fix a couple of issues internally to allow multi-threading in many areas of Houdini. This is why it's quite unlikely to have lagua-like system soon. If anytime I assume it will live in unified dops/pops context and based on OpenCL platform. I hope this is what is happening currently in sesi's secret laboratories ;)

Link to comment
Share on other sites

  • 3 weeks later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...