In D10197#276986, @Sybren A. Stüvel (sybren) wrote:

If I understand things well, this is how this feature works:

• use_proxies=true turns off the loading of Alembic data in Blender, and disables the evaluation of cache file datablock ID Properties and animation.
• The existence of the mesh cache sequence modifier is used as a signal to Cycles that the object actually has data from Alembic. This I feel is quite a hack, also in the light of the upcoming USD importer (D10700), which also uses the CacheFile to load its data.

@Will (Skoffin) Please create a new bug report, with example .blend file and any other associated file and exact steps to reproduce the problem.

I received your files, I am going to try and see if I can reproduce any errors. The C:\Users\Admin\AppData\Local\Temp\blender.crash.txt is missing from the archive, and it would also be useful to know if you can reproduce the issue with a more recent version of Blender downloadable here https://builder.blender.org/download/.

Setting as planned changes, as there is a bug in it (the device in SessionParams should now be a pointer), also it depends on D8750.

I can verify that this happens in the alpha builds available on https://builder.blender.org/download/.

You can send me the file through wetransfer since it is a bit large (my email address would be kevin dot dietrich at mailoo dot org). This is not standard procedure but I'd like to see if I can reproduce it.

Could you reduce the amount of objects in the file to reduce its size, such that the crash still appears? Or produce a different file that is also crashing? There is nothing much we can do without a file to reproduce.

@AiSatan (AiSatan) please open another bug report for this other issue.

This only seems to happen in 2.93.

I cannot reproduce in master (release or debug build), and I am having trouble compiling 2.92 because of the libraries change (is there a branch in SVN I can access still with the right libraries?).

• add some comments to clarify meanings and behaviors
• rename force_modifier to always_add_modifier
• do not pass an under-construction Depsgraph around
• split bounding box mesh generation into a separate routine

• pass default_radius to the CacheFile

Since the Mesh Sequence Modifier converts Curves to Meshes it's not really possible to test this since the radius is not taken into account when the conversion happens (?). If I recall correctly, Curves in Blender would need constructive modifiers to properly import them from Alembic (and USD)? Otherwise, I don't know how to test this outside of Cycles with D10197 (it was split from this patch). I may have lost such knowledge.

I guess that you are using Cycles Network rendering feature? If so the feature is experimental and this is more of a todo than a bug. Otherwise I am not sure if any network issue can be solved from our end. We do not make debug builds AFAIK.

I am getting a crash in nvcc when compiling the kernels for this file, not sure yet if it is related to your problem though.

No activity for more than a week. As per the tracker policy we assume the issue is gone and can be closed.

Please file a proper bug report, there is no explanation as to what the problem is, nor an example file to reproduce it.

Can you provide an example file that demonstrates your issue, and more information about your system (e.g. GPU driver)?

The stacktrace is rather strange, however without a file to reproduce the issue there is nothing much we can do. Can you try to reproduce the crash in a simple file of your own?

• fix wrong detection of delta compression support in multi-bvh

• pack BVH data directly in DeviceScene for OptiX and Embree so we can use chunks
• compute maximum change to decide if we can do deltas at all

I cannot seem to be able to reproduce the issue you are describing. However, I have committed a fix for another issue that looks like yours (rB72370b92be0db6c7726e1b74e73c393ed1d00538), could you try again with a build containing the fix? Either wait about 24 hours for the fix to be in an alpha build, or if you can compile Blender by yourself, you can pull the source to build with the aforementioned fix.

Could you attach a simple example .blend file that demonstrates the issue?

I tested this patch with cases from T85440, T83915, and the behaviors that I observed and talked about in D9555 (deleting an object that is not the last added results in the last one disappearing as well, or crashes, depending on the device) when I first noticed the issue, and everything appears to work properly.

For subdivision I think the attributes would need to be subdivided by the subdivision surface modifier (it it's not done already, I don't remember seeing them handled there) as the Blender exporter always accesses a subdivided mesh. Ideally we should have T68891 and not worry about any subdivision modifier, which can stay a modelling feature (and similarly for the subdivision node in the geometry nodes). This is something that I started looking into.

Potentially use different types for integer and bool attributes, currently they just become floats in cycles. This wastes memory in some cases, but I'm not sure how Cycles handles other geometry types internally, or if everything should just be floats.

This is actually a bug in the device update where we do not properly detect if attributes were added or removed so the kernel's attribute map is not updated.

Typically infinite update loops are caused by some property always being modified. Cycles detects this at the high level through Scene.need_data_update and Scene.need_reset. Those will check the managers which could have been tagged for an update after some object, geometry, etc., was modified. The synchronization routine between Blender and Cycles is always called after some time to account for user edits or viewport camera changes.

• skip particles modifier when checking for a mesh cache modifier, to easily ignore hair particles when using proxies
• pass a depsgraph to dependsOnTime
• review logic to check for proxies
• modify UI texts and comments

Since this only appears to be an issue in master, it could be caused by my device update refactor. I already had a similar bug in the same function. The fact that there is a crash tells me that the data between Blender and Cycles is properly synchronized, but a data update is missing in Cycles (the "object_flag" device array is looked up with a out of bound index). If Cycles did not receive an update from Blender, the scene would still render as it last was.

Accidentally included code from D10196, trying again.

Display bounding boxes in the viewport, this is done by returning a box
shape mesh from the modifier evaluation. The box derives from Blender
Objects' bouding box evaluation, which should come from the last read of
the Archive from the modifier.

@Daniel Salazar (zanqdo) please open a new bug report, this looks nothing alike the issue from this report

Alright then, closing this ticket since there was no bug.

Seems like this was fixed by rB61d1fd7e2f8b972b903fa6684114a13f652fd507, please try a newer version of Blender.

I cannot reproduce a crash neither in a release build, neither in a debug build, however I can see OptiX failing at the end of path tracing so I guess that's it.

This crash appears to have been fixed by rB61d1fd7e2f8b972b903fa6684114a13f652fd507.

• Update with latest master
• Fix compilation of Cycles standalone

Rendering bounding boxes in the viewport instead of the actual geometries is something that I initially thought about doing, but I did not do it for some reason I do not remember. I think can look into it again.

It is possible to not expose Camera.width, Camera.height, and Camera.resolution, but for that to work properly we need to use Camera.full_width and Camera.full_height in Camera.compute_auto_viewplane() so the aspect ratio is not computed with outdated values when resizing the window. Width, height, and resolution can then stay private and for internal use only.