More ICE Awesomeness

[edward]

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)...

[symek]

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 July 22, 2010 by SYmek

[lisux]

<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

[hoknamahn]

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

Dude, you broke my parser!

[kubabuk]

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

[Macha]

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 August 17, 2010 by Macha

[symek]

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

[jason_slab]

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

j

[Netvudu]

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

Edited August 21, 2010 by Netvudu

[jason_slab]

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

j

[Guest Swann]

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

[Pazuzu]

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

[jason_slab]

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

lol i've been waiting for the view cube to show up in soft... lame

[infinity_spiral]

Here are two new implementation of Bullet and Voronoi fracturing that are coming to Softimage:

[curveU]

sorry if my question sounds stupid, I'm just wondering is this possible in Houdini? and when?

[Andz]

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

Edited September 16, 2010 by Andz