Nope, that is not at all how splitting a big GAS into multiple GAS works. What you did now is building a single GAS with two build-inputs. You only called optixAccelBuild once.
That will neither reduce the size of the GAS, nor will it work inside the optixTriangle example, because that has only one SBT hit record, but with your two build inputs you need two now because of this:
inputs[0].triangleArray.numSbtRecords = (uint32_t)1;
inputs[1].triangleArray.numSbtRecords = (uint32_t)1;
That’s all fine and dandy for two build inputs but that isn’t at all what you want or what the optixTriangle example supports.
Please take a step back and read all linked threads I posted first! Really, I mean it. I explained what you need inside them.
Let’s look at the overall render graph you need first.
There needs to be a top-level IAS and that needs to have multiple GAS referenced in its OptixInstance structures. Looks like this:
IAS
/ | \
GAS_0 ... GAS_N
You need one optixAccelBuild for each of these GAS_0 to GAS_N with only one build input describing the triangles in that one GAS.
Then there is one optixAccelBuild for the single IAS which in this case has N+1 OptixInstances which each reference one of the GAS.
If the triangles are all defined in world space, the matrices on the OptixInstance are all the identity.
The OptixTraversableHandle of the IAS is your top-level traversable argument used inside the optixTrace call inside the device code, so that handle needs to be put into your launch parameter structure to have it accessible.
The optixTriangle example doesn’t support that because it’s using the traversableGraphFlags OPTIX_TRAVERSABLE_GRAPH_FLAG_ALLOW_SINGLE_GAS
but the above render graph requires OPTIX_TRAVERSABLE_GRAPH_FLAG_ALLOW_SINGLE_LEVEL_INSTANCING.
Again, there are different ways how you can access the triangle data inside the device code and depending on what you choose, there need to be different amounts of SBT hit records.
Please read this first:
https://forums.developer.nvidia.com/t/passing-per-vertex-attribute-data-into-a-shader-program/279321/2
I would strongly recommend you use the second method for this case!
For the simple case of building GAS and putting them under an IAS, have a look at my simpler introductory example code.
This creates different GAS at runtime and places them under an IAS:
https://github.com/NVIDIA/OptiX_Apps/blob/master/apps/intro_runtime/src/Application.cpp#L1361
The individual create<Shape> functions there generate the (interleaved) vertex attributes and build a single GAS for each:
https://github.com/NVIDIA/OptiX_Apps/blob/master/apps/intro_runtime/src/Application.cpp#L1361
The IAS traversable handle m_root is finally put into the launch parameters.
Note that the intro examples are using one SBT hit record per OptixInstance inside the IAS. That is not necessary when you architect the SBT more like the rtigo12 example.