- User Since
- Feb 21 2019, 1:26 PM (169 w, 1 d)
Sounds good, changed default volume precision to half and added the missing typenames.
Has the added benefit that there is now a nice correlation in the enum values between VDB_PRECISION_HALF/FULL/MINI_FLOAT from the fluid data block and VOLUME_PRECISION_HALF/FULL/VARIABLE.
Since VolumeRender.precision already existed, existing files will have that set to zero (as it was never set to something else). I therefore defined VOLUME_PRECISION_VARIABLE as zero, so that the default for all files is to use variable bit quantization now. This could be changed to VOLUME_PRECISION_FULL being zero instead, so that existing files will use full precision like before and only new files will use variable bit quantization (because _DNA_DEFAULT_VolumeRender sets it to VOLUME_PRECISION_VARIABLE now).
Fixed build failure with Clang/GCC
Moved precision property into volume render data block.
Thu, May 19
I wasn't entirely sure how, since there are no other Cycles settings in Volume and VolumeRender data blocks currently, other volume related settings are either in the material (e.g. material.cycles.volume_step_rate) or global render settings (e.g. scene.cycles.volume_step_rate). So not sure if it makes more sense to add to Volume/VolumeRender data block add add a new UI panel, or add it to the material and leverage the existing panel.
Tue, May 17
Reworked to use the new quantization data types in NanoVDB (nanovdb::Fp16, nanovdb::FpN), now that NanoVDB was updated.
Sat, May 7
Fri, May 6
This was happening because of different intersection precision and self intersection and was fixed by rBae440703411486c9219fa0ff54e471eea64afb58.
Thu, May 5
Changed error reporting to use last error from optixTaskExecute.
Wed, May 4
Apr 20 2022
This turned out to be a driver issue that has been fixed in 512.15+.
Apr 19 2022
It depends on what the USD exporter exported and assumes the Hydra viewport sets this render setting (or the user has to manually):
The Blender USD exporter currently exports USD with "metersPerUnit" set to 1, so assuming the app (Houdini does this for example) or user set the "stageMetersPerUnit" render setting to 1 (since it defaults to 0.01), this change should have no effect.
The Blender USD exporter from the "universal-scene-description" branch on the other hand has an option to convert to centimeters, in which case transforms are scaled by 100 and the USD has the "metersPerUnit" metadata set to 0.01. There those transforms need to be scaled with that 0.01 again to get back to the original values, which is what this change does. This way light radius and intensity should work as expected, as USD does not scale them by the transform and the Blender USD exporter dumps them to USD as is.
Apr 13 2022
Apr 12 2022
A few more necessary changes I had missed mentioning the first time around, with these it now builds successfully on Windows too.
Apr 8 2022
Awesome! There is a bit more necessary to get it running with Houdini on Windows it seems. I posted some suggestions to D14594 that made it work for me.
Apr 5 2022
Apr 4 2022
It's doable, I have a prototype lying around that needs some clean up. It instantiates the Cycles Hydra render delegate (with an existing Cycles session: https://developer.blender.org/diffusion/B/browse/master/intern/cycles/hydra/render_delegate.h$17), loads the USD stage and pushes it into the render delegate to sync. That takes care of setting up the Cycles scene and can then render as usual.
Does require a USD build with Hydra though of course, so if we want to make building the Cycles standalone with USD support using the precompiled libraries only possible, would need to update the precompiled USD to also include the Hydra component.
Apr 1 2022
Mar 25 2022
Mar 24 2022
Right, the build process could use some improvement. Setting USD_ROOT, TBB_ROOT(_DIR), OPENVDB_ROOT(_DIR) etc. works for the moment though (most importantly USD_ROOT and OPENVDB_ROOT, the others are used in mostly ABI compatible ways, so doesn't matter as much if linking against the different version in the precompiled libraries). Can also just disable OpenVDB support to not worry about it at all with WITH_OPENVDB=0. To get a USD build working that was built with Python, currently have to set a USD_PYTHON_LIBRARIES CMake variable with the additional libs to link (e.g. USD_PYTHON_LIBRARIES=boost_python37-vc141-mt-x64-1_68;python37 on Windows for Python 3.7).
Mar 23 2022
Mar 22 2022
Reverted unnecessary changes to "FindUSD.cmake" in favor of using "USD_ROOT" to specifc location
Mar 21 2022
Fixed Windows build to use existing WITH_WINDOWS_FIND_MODULES CMake option.
Mar 14 2022
Mar 10 2022
Thanks for taking care of doing the patch!
Mar 1 2022
Good idea, though would need a bit of refactoring. Probably something like (pseudo code):
This is not Windows specific and is related to how tiling and multi GPU is currently implemented in Cycles X:
Feb 24 2022
Like I said, you need at least 511.79 on Windows, 511.65 is too old.
Feb 23 2022
I was able to get rid of the artifacts with just this patch and a driver that has the driver-side fixes (they made it into the last r510 release, so need at least Windows 511.79 or Linux 510.54):
Feb 18 2022
Sure! But good point with the driver requirements ... Maybe better to reimplement the helper function or just copy those contents of "optix_denoiser_tiling.h" into the code and fix it (that particular file is under BSD 3-clause license, so no problem).
Yeah, this looks like a duplicate of T93710. That hasn't been fully fixed yet (the driver part is fixed in the last r510 drivers, but the same integer overflow problem is also present in the optixUtilDenoiserInvokeTiled helper function, which needs a SDK update to fix or will have to copy the function implementation into Cycles source code).
Feb 8 2022
Feb 1 2022
Jan 31 2022
Are there any news or is there help needed for this?
Jan 26 2022
Jan 10 2022
Jan 7 2022
Thanks! Closing as this was now committed in rBefe3d60a2c8306aefd41bc304548da35b67c252c.
Ah, didn't see D13763, in that case probably easier if you just land that one instead of this one =)
Thanks! Will commit in a sec.
Jan 6 2022
Was looking at the same thing and problem appeared to be the reports_lock field actually: The SpinLock type was typedef'd to volatile unsigned int, since the bf_editor_render project does not define WITH_TBB (which otherwise causes SpinLock to be typedef'd to uint32_t and is actually what should have been used here). And when VC++ 2017 sees a volatile in a type definition it no longer considers it trivial, hence why the check failed.
Jan 5 2022
Jan 4 2022
Fixed temporal denoising mode not actually getting enabled (since first frame is denoised with the normal denoiser still and it failed to switch on the second frame onwards). Whoops.
Jan 3 2022
Rebased and removed motion pass addition (hadn't realized what this entails). It's certainly fair to just note that both Denoising Data and Vector passes need to be enabled for the operator to work. If this is not the case it will report an error now ("Could not find a render layer containing denoising data and motion vector passes").
Dec 13 2021
Dec 10 2021
Dec 9 2021
So the problem here is a traditional case of integer overflow. What is happening is that for denoising, Cycles loads the entire huge image into a GPU buffer. Since rB17665494186816cebb9e8304199e40f9ee033990 this now theoretically works with the OptiX denoiser by splitting up this image buffer into smaller tiles that are denoised separately. But there is a catch: the width, height and rowStrideInBytes values passed to the denoiser are 32-bit integers and unfortunately there is code to calculate the size of the entire image by multiplying height (or a y coordinate close to that) and rowStrideInBytes. In this case the result is larger than what a 32-bit integer can hold and therefore overflows, causing the denoiser to read/write data at bogus locations, which shows up as artifacts. rowStrideInBytes is affected by the width of the image and how many render passes are active, hence why the problem goes away if you reduce the width or disable enough render passes (including hidden render passes that one does not select in the GUI, e.g. enabling auto tiling adds a hidden render pass, adaptive sampling adds two hidden render passes). To fix this the calculation will need to be done in 64-bit (by casting to 64-bit before multiplying).
Dec 8 2021
Dec 7 2021
The OPTIX_ERROR_INVALID_VALUE you are seeing is happening because of an out of memory (you can verify this is the log, with "--debug-cycles"). Likely this is the case because BVH builds are happening in parallel, which quickly exhausts available memory because of temporary build memory required (and has some additional known quirks when memory pooling is active), rather than serialized which does not suffer from that problem. That was fixed before (and is in 2.93), but the fix got lost in the Cycles X merge (and thus is not in 3.0), hence why 3.0 behaves differently. The rest of the pooled memory implementation has not changed.
I think this is not enough to continue investigating currently, without being able to reproduce. And since it's not happening with buildbot builds either it's probably not as critical. So I'd lean towards closing for now and reopen later again if it becomes a bigger problem.
Dec 6 2021
Dec 3 2021
Would be interesting to know what happens on 495.44, since @Philipp Oeser (lichtwerk) didn't reproduce there, and it's a newer stable release from the same branch as 495.29.05 (which is considered a beta driver).