SOP Solver cause to Recalculates SDF every frame

[slayerk]

I setup simplest scene with rbd object and multiple solver (with rbd solver connected to it). when i connect to multiple solver SOP Solver that cause to recalculate rbd's SDF every frame (option "deforming geometry" not set). also if SOP Solver is empty. it's dramatically slow down the simulation.

if i simply modifing some geometry attributes (like Cd) it's not logical to recalculate SDF (especially if object has vey complex form and high divisions).

[bhaveshpandey]

also if SOP Solver is empty. it's dramatically slow down the simulation.

Hi, a sop solver on its own won't do anything ie.if its empty or not referencing any sopnet

It shouldn't actually do it.Could you post the file, it would be simpler that way.

Edited March 21, 2011 by bhaveshpandey

[Macha]

I think a sopsolver always calculates the sdf of whatever is in there. If you put a plain box in, it will calculate its sdf, overwriting anything else in the network.

I wonder if there is a way to add the solver in such a way that something is piped in from the top (rather than multisolver) and then do something with the Set Never option. There's some hint in the docs about that but I don't fully understand how it could work in this case.

Edited March 21, 2011 by Macha

[slayerk]

topic on sesi forum without solution:

http://www.sidefx.com/index.php?option=com_forum&Itemid=172&page=viewtopic&t=6756

scene file:

test_sop_solver.hip

Edited March 21, 2011 by slayerk

[Hazoc]

Never mind:D I've no idea.

Edited March 21, 2011 by Hazoc

[SpencerL]

It is the RBD Object which is responsible for the SDF calculation. If you crack open the RBD Object > rbdconfigureobject, there is a SDF Representation DOP which is the culprit.

If you just need to run a sop solver which doesn't need an SDF, you could create your object from scratch with an Empty Object DOP followed by a SOP Geometry DOP to reference the geometry you want to modify.

[slayerk]

It is the RBD Object which is responsible for the SDF calculation. If you crack open the RBD Object > rbdconfigureobject, there is a SDF Representation DOP which is the culprit.

If you just need to run a sop solver which doesn't need an SDF, you could create your object from scratch with an Empty Object DOP followed by a SOP Geometry DOP to reference the geometry you want to modify.

ok. i describe my task. i'm have rbd object -> voronoy configure object. in other words geometry of source rbd object changing over time. my task is to calculate per-point velocity.

my idea is:

Multiple solver with 3 solvers.

1st solver - SOP Solver: saves P in oldP attribute

2st slver - Rigid body Solver: calculates new Position of points

3rd solver - SOP Solver: calculates per-point velocity = (P-OldP)/TimeInc.

How to organize this setup without slow down the calculations.

[Macha]

ok. i describe my task. i'm have rbd object -> voronoy configure object. in other words geometry of source rbd object changing over time. my task is to calculate per-point velocity.

Hm? But it is already there in $OBJ>Geometry>blabla_attributes, or do I misunderstand something?

[Macha]

To come back to the original problem however, I think I know why it updates SDF. The Data Name of the SOP Solver specifies what data is updated. By default that is Geometry, but it can be any other data as well, you can even make your own just by renaming it with a random string.

Geometry however contains the SDF data (Volume) as a sub entry so I suspect everything in the Geometry Data gets updated and modified.

Perhaps there is some way of excluding this with a pattern or an expression like ! or ^ but I have not found one. Or there could be another way of decoupling the Geometry and the Volume data.

Edited March 22, 2011 by Macha

[SpencerL]

To come back to the original problem however, I think I know why it updates SDF. The Data Name of the SOP Solver specifies what data is updated. By default that is Geometry, but it can be any other data as well, you can even make your own just by renaming it with a random string.

Geometry however contains the SDF data (Volume) as a sub entry so I suspect everything in the Geometry Data gets updated and modified.

Perhaps there is some way of excluding this with a pattern or an expression like ! or ^ but I have not found one. Or there could be another way of decoupling the Geometry and the Volume data.

Can you just crack open the rbd object > rbdconfigureobject and remove/bypass the SDF representation dop? I must be missing something here?

[Macha]

Can you just crack open the rbd object > rbdconfigureobject and remove/bypass the SDF representation dop? I must be missing something here?

I suppose that's possible, but more often than not you need the sdf later on. Of course, it may be possible to make a copy of it. There must be a cleaner method, I think.

Maybe we can just rename it and it will appear in another place. I don't know how that affects other sim setups. I'll give it a go tomorrow.

Edited March 22, 2011 by Macha

[slayerk]

To come back to the original problem however, I think I know why it updates SDF. The Data Name of the SOP Solver specifies what data is updated. By default that is Geometry, but it can be any other data as well, you can even make your own just by renaming it with a random string.

Geometry however contains the SDF data (Volume) as a sub entry so I suspect everything in the Geometry Data gets updated and modified.

Perhaps there is some way of excluding this with a pattern or an expression like ! or ^ but I have not found one. Or there could be another way of decoupling the Geometry and the Volume data.

intresting information! thanks.

[Macha]

Inside the Rbd Configure DOP I rewired the volume.

I think this removes recalculating sdf in the sopsolver. Not really sure but it appears to be so, or caching is playing a trick on me.

It still bounces and behaves seemingly OK.

volumesopsolver.hip

Edited March 23, 2011 by Macha

[Sifis]

Inside the Rbd Configure DOP I rewired the volume.

I think this removes recalculating sdf in the sopsolver. Not really sure but it appears to be so, or caching is playing a trick on me.

It still bounces and behaves seemingly OK.

Hey guys, while I 'm watching the od[force] forums for some time now, this is my first post, so I want to thank you all for your contributions and the wealth of knowledge you share. Ok , let's get to the point.

Macha thanks for your file. I learned a lot while I was examined it but what I found out is that when you unplugged the "file data" node from the "sop geometry" node, what you essentially did was remove the volume collision detection for the whole simulation that's why the sop solver evaluation was much faster. Also, plugging the "file data" node to the "apply data" directly doesn't make any change at all. here is an excerpt from the docs about turning off "volume collision detection":

" When this toggle is turned off, the collision detection is geometry-based rather than volume-based. In this case, the collision code will track the trajectories of moving objects over time to find out whether collisions occurred. This allows more accurate results than volume-based collision detection. "

So, There is an easier way to do this much simpler. You can turn off the "use volume collision detection" in your RBD object node but then you'll have to move any object transformations from your source object, from obj level to geometry level. You can take a look in the attached file.

volumesopsolver_02.hip

Edited March 23, 2011 by Sifis

[Hazoc]

So, There is an easier way to do this much simpler.

I thought and tried this too but wasn't really sure if it's a valid solution. For this test scene it is fine.

For example, what would happen if the sphere had to collide with smoke ? I don't think it works without the volume collisions being active.

Edited March 23, 2011 by Hazoc

[SpencerL]

if you need to have SDF's in the sim, you can also write out the SDF's before the sim using and isooffset SOP then read it in. Make sure when you write it out that its a .sim file and not a bgeo file.

[Macha]

The strange thing is that if I remove all sdf from the object and turn on volume collision it still collides.

Now I'm confused!

[Sifis]

The strange thing is that if I remove all sdf from the object and turn on volume collision it still collides.

Now I'm confused!

This is because when you remove sdf representation node from the "sop geometry" you essentially forcing it to collide in a non volume detection mode only. That's why turning "rbd configure object" usevolume toggle on or off doesn't make any change.

[Macha]

Good investigation Losif!

Sorry to keep going on about this but some things are still not clear to me and this is a good opportunity to figure them out!

I made some test with fetching and renaming and copying data and I think it should be possible to feed only Geometry data without its subdata into the sopsolver. That would provide a clean, simple solution, with sdf collision still intact, but I can't get the syntax right!

It is possible to refer to subdata for example by using Geometry/Volume. We can use a delete node and delete that data only. But the other way around, how is that possible? How do I only get Geometry without any of its subdata? That should be simple matter of a of slash or dot or other sign somewhere.

I tried to copy Geometry, rename it, delete subdata, feed into sopsolver (all works) and then get it back to Geometry but the problem seems to be that I fetch Geometry on every simulation step and something is mysterious in the way dops evaluates the network so what I end up with is data changed on one substep, replaced but then immediately overwritten by the original untouched data (I think).

Does anybody know the right syntax for excluding data? Kind of the opposite of Geometry/*

Edited March 24, 2011 by Macha

[Sifis]

It is possible to refer to subdata for example by using Geometry/Volume. We can use a delete node and delete that data only. But the other way around, how is that possible? How do I only get Geometry without any of its subdata? That should be simple matter of a of slash or dot or other sign somewhere.

I agree, I think this is the way to go but I can't find a way either. Still trying...

Edited March 24, 2011 by Sifis