"Non-existent ID removed from reference set"

I’m porting some code which works on OptiX 3.9 to 4.0 and have hit an error “Non-existent ID removed from reference set” twice now. I’m just wondering if someone can tell me exactly what it means, or what coding mistakes might cause it.

It has happened in my code when setting a variable on the context (“top_object”), and when assigning a material. The full error messages are below.

Unknown error (Details: Function “_rtVariableSetObject” caught exception: Assertion failed: “iter != m_map.end() : Non-existent ID removed from reference set”, file:C:\u\workspace\rel4.0-win64-build-Release\sw\wsapps\raytracing\rtsdk\rel4.0\src\Objects\VariableReferenceSet.cpp, line: 92)"

Unknown error (Details: Function “_rtGeometryInstanceSetMaterial” caught exception: Assertion failed: “iter != m_map.end() : Non-existent ID removed from reference set”, file:C:\u\workspace\rel4.0-win64-build-Release\sw\wsapps\raytracing\rtsdk\rel4.0\src\Objects\VariableReferenceSet.cpp, line: 92)

Thank you

We have seen this error with 4.0 in another case and are looking into it. It is likely happening when you assign a Material over another Material, both of which share a common optix::Program (eg, closest hit). Does this sound familiar? If you can provide more details on the operation which is causing the failure I can help you find a workaround.

Also, if possible can you provide us with an API trace to help us better understand the problem? You can send it to optix-help@nvidia.com (details on creating a trace below).

Thanks

===============================================================================================
An OptiX API Capture (OAC) trace contains all OptiX and OptiX Prime API calls made by the application, across the whole run of the application, together with their input data and return values. Traces are most often used for sending bug reproducers to Nvidia, but can also be used to make application benchmarks and for developers to analyze and debug their applications.

To create a trace, set the environment variable OPTIX_API_CAPTURE to 1 and run the application. A directory called oac00000 will be created within the current working directory. If that directory already exists, the number will be incremented to avoid overwriting an existing trace.

Zip the trace directory and send it to Nvidia. We can only receive 10MB files by email, and the extension must be renamed to not be .zip. For larger files, use a file sharing service. We recommend contacting us and we will set up a temporary upload location.

When sending a trace to Nvidia, please put some effort into keeping it small. If the trace is for debugging, use the smallest effective dataset and shortest number of frames necessary to reproduce the bug. If the trace is to become an OptiX benchmark, the dataset will be larger, but be very precise in the number of frames recorded.

The OAC trace directory contains a trace.oac file, which is a text file containing information about your platform, followed by all OptiX API calls, with their parameters and return values. You can, for example, search for occurrences of “rtContextLaunch” in this file to see all OptiX calls that are made per frame to make sure you’re not doing redundant setup work. The “oac.buf." files in the trace directory contain binary buffer contents, both input and output. Each time a buffer is mapped its contents are stored to a new file. The "oac.ptx.” files contain PTX text of application-provided program code.

Since OAC traces contain contents of all OptiX buffers, they contain the PTX form of the application’s shaders and other user program code, as well as the geometry and texture maps given to OptiX. While Nvidia will keep these secure and never share them, you will want to make sure that sharing a trace with Nvidia meets your institution’s policies.

The basic setup is that I have a main scene with various objects and materials, being rendered without problem.

Then I create: group->transform->geometry group->sphere instance, to make a second scene in the same context, lit by a light. The sphere is for previewing the materials in the main scene, so I apply a material to the sphere instance (one already created in the main scene) and render this secondary scene. The time I render it works, and it keeps working if I setup again with the same material, but when I switch the material I get the error mentioned calling setMaterial on the instance.

I get the error when the switched material is of the same type (same programs), and when it’s a different type, it doesn’t seem to make a difference for me.

OAC file was about 15MB, so I’ve split it into ndm_oac00001.7z.001 and ndm_oac00001.7z.002, which I’ll email now.

Thank you for your reply, and let me know if I can do something further to assist.

I just got your OAC traces, thanks. It looks like we have a fix in the works – your traces will be valuable for further testing of the fix.

As a temp workaround you can, instead of replacing the Material node on your pre-existing GeometryInstance, create a new GeometryInstance, copy the Geometry and any Variables over to the new GI, and set the new Material on the new GeometryInstance. Then delete the original GeometryInstance. Sorry for the hackiness but we will get you a fix ASAP.

Thanks.

I’ll try that, thank you for the fast reply.