Hi, I'd like to request some compile guards be added to the shader source code so that, similar to how it's done in the CPP files, all SHARC and/or NRC-specific code is compile-guarded by ifdefs as guide-rails to quickly follow (and integrate) what's needed/relevant to each cache scheme and what isn't.
However, in the shaders, this isn't done. NRC and SHARC code are intermingled, willy nilly, which is confusing and not ideal when trying to debug some weird issues I'm having.
I compile my SHARC vs NRC specific UPDATE vs QUERY ray tracing passes via slang files and defines to enable each one independently, and this works fine, but I had to first basically add these compile guards around your own code first.
NRC headers, for instance, if ENABLE_NRC isn't defined, it STILL defines those function stubs, they just do nothing.
This, frankly, is a code bloat from my perspective.
Functions shouldn't be called in the first place, if they are defined away to nothingness.
So it's better to put the ifdefs around the calling code (in the shaders I mean), than in the NRC headers themselves.
That would not only simplify my life, but make debugging easier.
Here for ex, while debugging, it wasn't clear to me originally how NRC differs from SHARC, insomuch as NRC's separate "resolve" pass does what query pass does in SHARC (appending / accumulating the cached radiance into the raygen shader itself). SHARC seems better and more efficient than NRC overall, frankly, with only subtle difference in image quality. But I'm happy to keep experimenting / using both.
(line 618 doesn't need an NRC_UPDATE compile guard, it's meant to be called in both cases, update and query)
Hi, I'd like to request some compile guards be added to the shader source code so that, similar to how it's done in the CPP files, all SHARC and/or NRC-specific code is compile-guarded by ifdefs as guide-rails to quickly follow (and integrate) what's needed/relevant to each cache scheme and what isn't.
However, in the shaders, this isn't done. NRC and SHARC code are intermingled, willy nilly, which is confusing and not ideal when trying to debug some weird issues I'm having.
I compile my SHARC vs NRC specific UPDATE vs QUERY ray tracing passes via slang files and defines to enable each one independently, and this works fine, but I had to first basically add these compile guards around your own code first.
NRC headers, for instance, if ENABLE_NRC isn't defined, it STILL defines those function stubs, they just do nothing.
This, frankly, is a code bloat from my perspective.
Functions shouldn't be called in the first place, if they are defined away to nothingness.
So it's better to put the ifdefs around the calling code (in the shaders I mean), than in the NRC headers themselves.
That would not only simplify my life, but make debugging easier.
Here for ex, while debugging, it wasn't clear to me originally how NRC differs from SHARC, insomuch as NRC's separate "resolve" pass does what query pass does in SHARC (appending / accumulating the cached radiance into the raygen shader itself). SHARC seems better and more efficient than NRC overall, frankly, with only subtle difference in image quality. But I'm happy to keep experimenting / using both.
(line 618 doesn't need an NRC_UPDATE compile guard, it's meant to be called in both cases, update and query)