I’m not sure what you mean exactly with the statement under 1.
If that means your scene structure becomes
Group (root) -> Group (per file) -> Transform -> GeometryGroup (file contents) -> GeometryInstance -> Geometry
then the second level Group node is not necessary and leaving it away will speed up the runtime performance due to faster traversal through a shallower OptiX scene hierarchy.
The optimal layout if you want to move all whole models (one per file) individually would be this:
Group (root) -> Transform -> GeometryGroup (file contents) -> GeometryInstance -> Geometry
Similar if you want to move each of multiple objects inside each file individually, just many more Transforms then.
Means you should try to make your OptiX scene representation as shallow as possible. You normally never need more than a two-level BVH, which this is already: Group (root) -> Transform -> GeometryGroup because all OptiX nodes with “Group” in the name hold an acceleration structure.
For example, if your application scene graph has a deep transform hierarchy, like a kinematic skeleton structure, the application should flatten the transforms to get such a two-level BVH.
(Actually the same is true for a rasterizer and that’s why our own scene graph implementation in the nvpro-pipeline (open source on github) is going to great lengths to concatenate the application side transformations before generating the matrices for the render backend scene representation, plus some clever tricks to speed up validation and update of these concatenated matrices on any application side scene changes.)
If you watch my GTC 2018 OptiX Introduction talk listed here:
that explains the minimal and most efficient OptiX scene graph layouts in slides 7, 8 and 10.