Question about scene description files (.txt)


in OptiX_Apps project you have used two types of files:

  1. system_rtigo3_single_gpu.txt
  2. scene_rtigo3_models.txt

These files contain relevant parameters like camera and material properties. Except scene_rtigo3_instances.txt, none of the scene_ files contain any .obj. So, I think the vertex positions are embedded in the scene_ files.

Normally .obj/.fbx/.gltf file formats are imported with Assimp library for further rendering. I checked the data structure with both scene graph and Universal Scene Description data structure, but they are different.

  • What are these files (format) called?
  • How to generate these data structures? For example, in Blender or any 3D model creator is there any option to export the scene as .txt format?
  • Except loading the data in OptiX_Apps example, can I visualize these in any 3D viewer software?


Hi @_Bi2022,

These are ad-hoc formats defined by this project. You can find the source code for the “system_” file in Application::loadSystemDescription (apps/rtigo3/src/Application.cpp), and for the “scene_” file in Application::loadSceneDescription. Assimp is used to load the models that are referenced by these files, so you can export models to any format supported by Assimp, and then manually add a reference to your model in your scene description. To view the models in external DCC software, load the model files directly, rather than trying to load the .txt files.


1 Like

Is there any advantage of importing files in this way? For example, we can also import 3D models directly in this way,

auto teapot = make_shared<TriangleMesh>("resources/model/teapot.obj");

The system and scene description text files are just something I came up with to allow simple and repeatable settings for an application. In the end, it’s all just demo code.

The system description is simply meant to avoid adding all these individual control parameters to the executable command line options which would have been really messy to use.

The scene description is also just a simple way to build more complex scenes from either the runtime generated shapes at arbitrary geometric complexity (for the plane, sphere and torus), as well as loading triangle meshes from supported standard file formats using ASSIMP. It’s just meant to make the examples more useful and interesting.

For example I can create scenes which will exceed any graphics memory amount and thereby check if things work when sharing the data via CUDA peer-to-peer across two GPUs using NVLINK. It’s rather difficult to find real world scenes exceeding 48 GB in a usable model.

Both descriptions together allowed the verification of the correctness and performance of the renderer implementation, as well as showing some typical renderer features like instancing, texturing, etc.

If you have a way to load your models differently, nobody keeps you from using that method inside your own application. In the end, it’s just a matter of how you get your triangles into OptiX and the code doing that can be found inside my examples.

In my case, the scene description also loads an OBJ model like that. It’s effectively model assimp "cow.obj" inside the scene description which tells the application to load the given OBJ file with the std::shared_ptr<sg::Group> Application::createASSIMP(std::string const& filename) function which returns a subgraph of potentially multiple triangle meshes inside the loaded file which gets added to scene’s host side scene graph root node.
The device side render graph is flattened from that to a two-level IAS->GAS layout for better performance.
The material assignments looks for material reference names matching the material names inside assimp. For OBJ files without accompanying MTL file (like for the cow.obj), ASSIMP returns a material with the name DefaultMaterial which can be defined inside the scene description. All materials for which no reference name is found will retry assigning the material with the name default. If that is also not found, the scene loader fails.

Note that the OBJ and MTL file formats are more involved than you might think. Many OBJ files are partitioned into groups (and smoothing groups which affect the normal vector generation) with different materials. There are multiple ways to transport that over to an OptiX render graph.

I’m using different geometry acceleration structures (GAS) per triangle mesh (group inside the OBJ) which can be instanced. It would also be possible to implement each OBJ as a single GAS with multiple shader binding table entries and material assignments per face in OptiX. I kept it simple inside these examples.

1 Like

I upped the scene description game a little with the most recent two examples I just added to the github repository.

Now the scene description of the rtigo9 and rtigo10 examples allows overriding the camera and tonemapper settings inside the scene description file, but the bigger change was to allow defining emissive materials and lights inside the scene description now.

Previously the environment light and a single hardcoded parallelogram light were toggled inside the system description file. Now you can define arbitrary many lights of different types inside the scene. Still only one environment light of course.

Please read the and the new scene_rtigo9_demo.txt inside the data folder.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.