Jump to content
Solitude

More ICE Awesomeness

Recommended Posts

Also, his original version of SPH used only factory nodes AFAIK. Who knows how much of this relies on custom stuff?

<shrugs> But from this CG Talk post,

ThE_JacO[/url]]...(and of course they are C++ written against the ICE API)...

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
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 :)

Share this post


Link to post
Share on other sites

This is the part a lot of people don't seem to be not processing right.

Dude, you broke my parser! :lol:

Share this post


Link to post
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? 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

Share this post


Link to post
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

Share this post


Link to post
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 ;)

Share this post


Link to post
Share on other sites

some nice looking lagoa interaction about a minute into this emPolygonizer vid

j

Share this post


Link to post
Share on other sites

I didn´t like this latest video that much...too much blobbyness around... <_<

Edited by Netvudu

Share this post


Link to post
Share on other sites

yeah emPolygonizer stuff is rather blobby, but i was referring more the to lagoa interaction in the video

j

Share this post


Link to post
Share on other sites

i'll Love to see that kind of speed and interactivity in Houdini.

Share this post


Link to post
Share on other sites

Softimage 2011.5 with Lagoa... and View Cube yeaaaah ;).

A brief reading about Lagoa and its creator:

LINK

*Ops... sorry, looks like the article is gone.... strange :unsure:

Edited by Andz

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×