55 replies to this topic

[helium]

could anyone show me a very basic example about a solver in SOP context?

Thanks,

[Macha]

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?

[Marc]

lisux, on 21 July 2010 - 03:37 PM, said:

SOP solver should be faster because then you have to do all the data handling by yourself, I mean all the internal representation of your geo and sim state. This means you can optimize it and make it lighter than DOPs.
I haven´t implement any solver never but this is what I guess after talkign with people which has done stuff lik this before.

Yeah, exactly right. If we take the bullet solver we built in to SOPs as an example, it has the advantage of doing only one thing (for the moment anyway ), and that's rigid body sims. So you have a very clearly defined set of inputs and a very clearly defined set of outputs. With that in mind you can optimise the heck out of it. DOPs is by its nature a very flexible toolkit which allows you to build completely new behaviours into it just by using its nodes. This does come at a performance price though.

So while it is possible to build a black box type solver in DOPs... it does kind of go against what DOPs was designed to be and so it's much easier just to code it as a SOP solution.

M

[edward]

Marc, on 21 July 2010 - 12:54 AM, said:

Not to mention that if you implement your own solver in SOPs then anyone with an escape license can use it.

An Escape license can use DOPs, it just can't create DOPs.

[edward]

CiaranM, on 20 July 2010 - 07:25 AM, said:

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,

Quote

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

[symek]

Macha, on 21 July 2010 - 08:50 PM, said:

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, 22 July 2010 - 12:25 AM.

[lisux]

edward, on 21 July 2010 - 11:21 PM, said:

<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]

Ratman, on 21 July 2010 - 07:48 AM, said:

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.wor.../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, 17 August 2010 - 03:03 PM.

[symek]

kubabuk, on 17 August 2010 - 01:45 PM, said:

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

View on Vimeo.

j