SOP Inport Warning

   4512   5   2
User Avatar
Member
2162 posts
Joined: Sept. 2015
Offline
So I've just moved to 19.5 from 18.5

I've noticed that although on the surface the SOP import node seems to have not changed,
Either internally it has or SideFX decided to add this warning because it was creating confusion/issues with people attempting to do certain work flows with unexpected results?

The tick box comments for 'Copy Contents into Editable Layer' seems to explain why, as it also makes the warning go away.
I suspect it's just one of those types of warnings that are not important but a 'good' reminder to have, not unlike sop merge nodes with different attributes coming into the mix.

I only use LOPs for ease of use in setting up lighting/material and like to do all my work in SOPs before bringing it in for rendering.

But I am curious as to why now for this 'warning'.

The SOP import warning is:

The layer imported from SOPs has no save path set.
The SOP node's layer will be output to a file path generated from its Houdini path.
User Avatar
Member
75 posts
Joined: Dec. 2017
Offline
BabaJ
So I've just moved to 19.5 from 18.5

I've noticed that although on the surface the SOP import node seems to have not changed,
Either internally it has or SideFX decided to add this warning because it was creating confusion/issues with people attempting to do certain work flows with unexpected results?

The tick box comments for 'Copy Contents into Editable Layer' seems to explain why, as it also makes the warning go away.
I suspect it's just one of those types of warnings that are not important but a 'good' reminder to have, not unlike sop merge nodes with different attributes coming into the mix.

I only use LOPs for ease of use in setting up lighting/material and like to do all my work in SOPs before bringing it in for rendering.

But I am curious as to why now for this 'warning'.

The SOP import warning is:

The layer imported from SOPs has no save path set.
The SOP node's layer will be output to a file path generated from its Houdini path.

As the warning literally means, you have not set a storage path for this layer, Houdini will automatically set the default storage path.

You can set save path directly on sop import, or equivalently use config layer.



When you don't set save layers, Houdini treats them as anonymous layers stored in memory.

If you're just using LOP as a tool for lighting rendering and look development, rather than exporting USD files and working with USD pipelines, you don't need to worry about this,Just ignore these warnings and set up lights and materials.

But I have to remind you that LOP is a tool set built entirely on USD, and if you use it as a black box, you may encounter significant performance issue,which is very common in heavy FX work.

Attachments:
save_path_1.jpg (29.3 KB)
save_path_2.jpg (23.9 KB)

User Avatar
Member
2162 posts
Joined: Sept. 2015
Offline
and if you use it as a black box, you may encounter significant performance issue,which is very common in heavy FX work.

Ok...thanks, that's really good to know if in the future I do sims where I am trying to max out/make use of as much resources as I can.

But that makes me curious then...

"When you don't set save layers, Houdini treats them as anonymous layers stored in memory."

So, then does that mean if I do have a 'save layer' for the sop import, that it will access that saved data and put in memory the usd form of that data only; Otherwise if as you say when being treated as an anonymous layer, it has to hold both the sop data before it's conversion and also the data in usd form at the same time for other downstream operations in LOPs, which is why it can balloon memory usage in such cases? Or something like that?
User Avatar
Staff
4565 posts
Joined: July 2005
Offline
All layers created within a LOP network exist only in memory. USD data imported from SOPs may be copied to a USD layer, or it may point to the SOP node as if it were a "file" (which is not anonymous), but in either case this SOP data is (like all SOP data) in memory until you save it to disk. Because USD and SOPs are both good at sharing blocks of data, it really shouldn't matter much which approach you use when referring to SOP data.

Having a "save path" set for the SOP Import is a totally separate issue and has zero performance implications. It only matters when using a USD ROP, and only insofar as it changes the path of the USD file where the SOP data will be written to disk. This is why we put the warning on these nodes... You can do a huge amount of work in a live LOP network graph, and have absolutely no idea that anything is "wrong" until you write the USD files to disk, at which point you end up with USD files saved in a bunch of locations that you never explicitly chose. If you are never going to save USD files to disk, then you can ignore this warning completely with no ill effects.
User Avatar
Staff
4565 posts
Joined: July 2005
Offline
You might be able to get a better understanding of how LOPs authors USD data here: https://www.sidefx.com/docs/houdini/solaris/about_lops.html [www.sidefx.com]
User Avatar
Member
75 posts
Joined: Dec. 2017
Offline
BabaJ
and if you use it as a black box, you may encounter significant performance issue,which is very common in heavy FX work.

Ok...thanks, that's really good to know if in the future I do sims where I am trying to max out/make use of as much resources as I can.

But that makes me curious then...

"When you don't set save layers, Houdini treats them as anonymous layers stored in memory."

So, then does that mean if I do have a 'save layer' for the sop import, that it will access that saved data and put in memory the usd form of that data only; Otherwise if as you say when being treated as an anonymous layer, it has to hold both the sop data before it's conversion and also the data in usd form at the same time for other downstream operations in LOPs, which is why it can balloon memory usage in such cases? Or something like that?

I find my statement confusing, I'm not saying that your current approach will have performance issues, but that inappropriate use of USD can cause problems when you're dealing with some complex scenarios.

For example, a large number of unnecessary time sample properties or some kind of primitive can be represented by instancer.
  • Quick Links