More ICE Awesomeness

[cabra]

Em. had my attention for 39 seconds.

I'm getting old and nothing amazing achievement!

and instantly are now convinced that there is something you can not and that's not true.(You're not creative), is also possible to do with paper and pencil..

Imagine the demolition of a bridge (in the imagination).

chers.

please do not defile the sanctuary with autodesk trash. ji ji.

Edited July 21, 2010 by cabra

[symek]

ok Symek...eagerly awating for your Houdini version of this tool how long will it take, a week, a week and a half?

It's not funny at all

[Marc]

But I am sure you can make fluid solver complitelly in SOPs where you sacrify flexibility to get total control of data management and get speed.

I have a feeling I've mentioned this before, but anyway.. stop me if you've heard this . DD's and Sony's fluid solvers were implemented as SOP based systems. As well as the bullet solver implementation we made for the Tangshan movie. I'm guessing R&H's fluid solver is also SOP's based. DOP's adds such an overhead, to processing time, programming time etc. Not to mention that if you implement your own solver in SOPs then anyone with an escape license can use it. It's a win win (sorta).

M

[Netvudu]

It's not funny at all

come on, you can´t blame me for trying...

ok, you can, but you can´t REALLY blame me for trying. I want me one o´those Lagoa thingies!!

[lisux]

I say we just skip particles and go directly to Superstrings

That's all right for cloth/plastic like materials.

But what about sand, massive particle based simulations with friction between particles. These are not superstrings.

Anyway Edward would be very intersting to have solvers able to do these kind of simulations in a decent time.

[hoknamahn]

That's all right for cloth/plastic like materials.

But what about sand, massive particle based simulations with friction between particles. These are not superstrings.

Anyway Edward would be very intersting to have solvers able to do these kind of simulations in a decent time.

Well, if superstrings or quantum field theories don't help then just use another one - the theory of everything. Should help.

By the way, even if your solver can process millions of particles represented as a plain data (it really can do it easily) you still have to feed those particles into Houdini land and even SOPs (in fact GDP) will be a big bottleneck.

Edited July 21, 2010 by hoknamahn

[Vinz9]

I have a feeling I've mentioned this before, but anyway.. stop me if you've heard this . DD's and Sony's fluid solvers were implemented as SOP based systems. As well as the bullet solver implementation we made for the Tangshan movie. I'm guessing R&H's fluid solver is also SOP's based. DOP's adds such an overhead, to processing time, programming time etc. Not to mention that if you implement your own solver in SOPs then anyone with an escape license can use it. It's a win win (sorta).

M

Hi, I thought you could only do iterative stuff like a solver in Pops or Dops (or sops in dops with the sop solver but I don't think it's what you're talking about). I know the maya API but not the HDK, so it must be possible to have a SOP which resets on a starting frame and then do some calculations iteratively then.

But I guess then it has to be a black box operator.

Would it be possible to do this with a python SOP (not for speed but to quickly tests things) or only with the HDK ? Will check on my own when I have time but I'd be grateful for a quick answer!

Thanks

Vincent

edit : just did a little test, with a python sop just as with a vex sop it seems there's no easy way to create a variable whose value would be kept and incremented between frames. so it has to be be with HDK.

Edited July 21, 2010 by Vinz9

[goldleaf]

This is way cool. Awesome job Thiago.

You can access time through Python in SOPs via hou.frame(), but something like this would definitely benefit from the speed you'd gain by using the HDK.

[petz]

Hi, I thought you could only do iterative stuff like a solver in Pops or Dops (or sops in dops with the sop solver but I don't think it's what you're talking about). I know the maya API but not the HDK, so it must be possible to have a SOP which resets on a starting frame and then do some calculations iteratively then.

But I guess then it has to be a black box operator.

Would it be possible to do this with a python SOP (not for speed but to quickly tests things) or only with the HDK ? Will check on my own when I have time but I'd be grateful for a quick answer!

Thanks

Vincent

edit : just did a little test, with a python sop just as with a vex sop it seems there's no easy way to create a variable whose value would be kept and incremented between frames. so it has to be be with HDK.

you don´t need the hdk but as goldleaf said, it would be much faster.

attached is a quick python hack that should do what you want.

petz

particles.hip

[lisux]

Hi, I thought you could only do iterative stuff like a solver in Pops or Dops (or sops in dops with the sop solver but I don't think it's what you're talking about). I know the maya API but not the HDK, so it must be possible to have a SOP which resets on a starting frame and then do some calculations iteratively then.

But I guess then it has to be a black box operator.

You can definitile do it in HDK.

And yes, the counterpart of doing everything in the SOP land is that is a kind of a blackbox.

But I think that having fast ans simple solvers in SOPs will make our lives a lot easier. I love to have ParticleSOP, and all the crazyness you can do with expressions, point attributes, etc ...

For some stuff is a good solution. The same can be done for RBD, cloth, fluids, etc ....

Just imagine having a new version of the SpringSOP with a fast solver whith the same inputs as in the particle SOP. You can probably do 80% of your colth sims there. And you can build a lightweight, blackbox solution in SOP, and a heavy flexible solution in DOPs.

This will be a really really good feature for Houdini.

[Guest xionmark]

I say we just skip particles and go directly to Superstrings

He says while stepping onto the event horizon ...

[AdamJ]

Given a choice of yet another solver I'd rather have the devs spend the time optimizing the heck out of DOPS. If you add the SOP based workflow you're basically adding/duplicating another environment to do the same thing.. dynamics. Choice is good but I'd rather have one workflow that works really well as opposed to two that 'sort of' work.

You can definitile do it in HDK.

And yes, the counterpart of doing everything in the SOP land is that is a kind of a blackbox.

But I think that having fast ans simple solvers in SOPs will make our lives a lot easier. I love to have ParticleSOP, and all the crazyness you can do with expressions, point attributes, etc ...

For some stuff is a good solution. The same can be done for RBD, cloth, fluids, etc ....

Just imagine having a new version of the SpringSOP with a fast solver whith the same inputs as in the particle SOP. You can probably do 80% of your colth sims there. And you can build a lightweight, blackbox solution in SOP, and a heavy flexible solution in DOPs.

This will be a really really good feature for Houdini.

[Ratman]

By the way, even if your solver can process millions of particles represented as a plain data (it really can do it easily) you still have to feed those particles into Houdini land and even SOPs (in fact GDP) will be a big bottleneck.

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

[Vinz9]

you don´t need the hdk but as goldleaf said, it would be much faster.

attached is a quick python hack that should do what you want.

petz

Thanks, clever

[Macha]

Sorry folks , but I think it's time to parade my ignorance on the matter. But I'd really like to know more:

Do you say dops are inherently slower than sops? Is that because it is history aware and needs to keep previous stuff in memory? Why would a sop solver be faster and better, and if so, why do we use dops?

Edited July 21, 2010 by Macha

[lisux]

Sorry folks , but I think it's time to parade my ignorance on the matter. But I'd really like to know more:

Do you say dops are inherently slower than sops? Is that because it is history aware and needs to keep previous stuff in memory? Why would a sop solver be faster and better, and if so, why do we use dops?

AFAIK DOPs is moving a lot of data all the time, and creating some of the internal geometry representations, like the SDFs is not as fast as it should be. But basucally is all the data handling which makes things slower. But having all of these data is also a good point for flexibility.

Is like having a layer of stuff over SOPs.

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.

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

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]

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.