A node such as Instancer Lop has a dedicated inner sop context. It keeps the path of the inner node short and has clean logic. I think it is a very good design. On the contrary, the Sop Create lop, the most important node is only a hda. Why not give it a dedicated sop context like Geo Object node for performance and logic?
And the sop import and sop create node can be merged into one node like Instancer if we have a dedicated sop context.
A lot of tools start as HDAs which is good for prototyping and proof of concept during dev stage
But most importantly invaluable source for learning
Whatever is rewritten as a blackbox c++ node may gain speed, but also forbids studios and individuals to learn and customize such tools
Ideal scenario is low level tools being highly performant c++ nodes and higher level complex nodes being HDAs which hopefully would also be performant if every building block is
The path not being as clean is usually not a problem
If you look inside, it makes sense why it's made the way it is and there should be no reason to recreate the same functionality in a monolithic node
Sopcreate is intermediate development stage of an asset. Like in obj context where sop asset often end up with file cache and OUT null then loaded into clean dedicated obj node through file or object merge sop. In solaris SOPcreate should end up with Usd export SOP then be loaded into scene through Reference or Stage manager LOP to speed up scene and avoid any unwanted changes.
By using Solaris some time, I find the most problem is the viewport. The background usd prims disappear often or have refresh problem when diving into sop context. Maybe a dedicated sop context in lop could solve this.
There is an RFE for SOP-containing LOPs that would allow them to specify which LOP to display as a guide in the background. The default is to display the LOP that contains the SOPnet. Other options might include the parent LOP's input, the display LOP, or none.
malexander There is an RFE for SOP-containing LOPs that would allow them to specify which LOP to display as a guide in the background. The default is to display the LOP that contains the SOPnet. Other options might include the parent LOP's input, the display LOP, or none.
And it is better to link viewport camera between Sop view and Lop view when lop as background. Avoid switching view point when moving inside and outside sopnet.
malexander There is an RFE for SOP-containing LOPs that would allow them to specify which LOP to display as a guide in the background. The default is to display the LOP that contains the SOPnet. Other options might include the parent LOP's input, the display LOP, or none.
And it is better to link viewport camera between Sop view and Lop view when lop as background. Avoid switching view point when moving inside and outside sopnet.
It is supposed to do this, but sometimes it fails when switching contexts.
