Jump to content
Solitude

More ICE Awesomeness

Recommended Posts

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 by cabra

Share this post


Link to post
Share on other sites

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

It's not funny at all :huh:

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

It's not funny at all :huh:

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!! :P

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 by hoknamahn

Share this post


Link to post
Share on other sites

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 by Vinz9

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
Guest xionmark

I say we just skip particles and go directly to Superstrings :)

He says while stepping onto the event horizon ...

B)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Sorry folks :blink: , 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 by Macha

Share this post


Link to post
Share on other sites

Sorry folks :blink: , 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.

Share this post


Link to post
Share on other sites

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

Thanks,

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?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

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

×