55 replies to this topic

[lisux]

edward, on 20 July 2010 - 06:45 PM, said:

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]

lisux, on 21 July 2010 - 01:28 AM, said:

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, 21 July 2010 - 02:04 AM.

[Vinz9]

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

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, 21 July 2010 - 05:02 AM.

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

Vinz9, on 21 July 2010 - 03:46 AM, said:

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

Attached Files

•  particles.hip   102.23K   144 downloads

[lisux]

Vinz9, on 21 July 2010 - 03:46 AM, said:

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.

[xionmark]

edward, on 20 July 2010 - 06:45 PM, said:

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.

lisux, on 21 July 2010 - 06:25 AM, said:

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]

hoknamahn, on 21 July 2010 - 01:57 AM, said:

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]

petz, on 21 July 2010 - 06:17 AM, said:

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 by Macha, 21 July 2010 - 03:28 PM.

[lisux]

Macha, on 21 July 2010 - 03:28 PM, said:

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.