If I go to the Type Properties, Input/Putput tab, I can see that the first Input is labeled as “parent”. Even if I rename it there, it seems that it still acts as parent and my whole OTL geo inherits the transformations of the first input. So far, I have been avoiding using it, but I'm very curious, if there is a possibility to unmap it? What would you do In case that you reaaaaally do need every one of the inputs… (joke aside, but this is for the sake of SCIENCE)) :idea:

You can place a target Null Object inside the asset and set that as your parent object target.

Then you can use whatever constraints from the four inputs to drive the position of that final null by selecting the null inside using the Output Transform parameter.

See the example file where four inputs to a subnet are fed in to a Blend CHOP which drives a null set to the Output Transform.

Thanks for the tip Jeff, this seems a nice setup for a parent switcher asset :idea:
Still, what I meant with my initial question was, to use the whole subnet for example as a “fracture tool” - 1st input= user defined GEO, 2nd input = user defined fracture curves. If I use the first input as geo input AND the geo has some object level transforms, they get translated into the whole OTL network and I'm getting unexpected results ( stupid offset, mhm). I would really like to know if it is possible to bypass the “parent” behavior of the first input, so the OTLs I create are more user friendly and intuitive

Doh! I completely misread your initial request…

Can you see if setting the Output Transform to “No Object” on the top level Subnet node works for you? That way no input transforms are applied to any of your subnet contents.

jeff
Doh! I completely misread your initial request…

Can you see if setting the Output Transform to “No Object” on the top level Subnet node works for you? That way no input transforms are applied to any of your subnet contents.

I tried using no object and all other other input possibilities for the Output Transform, but I still do get the inherited transformations of the first-input object (Tried it in a clean simple scene, so it seems like this “output transform” is either bugged or doing something else in generall).

Please post an example file so we can have a look.

Oh, I should have done this already, sorry. Hope this helps, thanks!

just disconnect your some-nodes-placeholder node from 1 subnet input inside of your Object Level OTL so it will not inherit transform

you will still be able to sample objects connected to your OTL with opinputpath() expression for example and therefore bringing their geometry via Object Merge to your Geometry Object if needed

just keep in mind that usually you want to keep Geometry based tools in SOP level where inputs pass geometry instead of Object Level where they pass transforms

You are so right tamte, I should really not connect it like that Maybe the problem is about this (This time I connect properly, as you pointed out):

-if I use the second input, I could choose if I want the geometry to be transformed “into this object” ( object merge in OTL) or “none” so the geometry gets placed on world 0,0,0.
-if I use the first input, it seems like the “none” option doesn't work (it does basically what “into this object” does).

I did some testing right now and this happens only if you create OTL directly from the SOP network. If you first create a subnet, and then turn this subnet into an OTL, the object merge transform works as it should. Is this working as intended?
Are there some good learning materials about production level structuring of OTLs and expected functionalities? Thanks in advance!