The Issue

It appears that some renderers also rely on a block's collision shape when calculating lighting in render threads. This means that MultipartBlock.getCollisionShape suffers from the same concurrency issue that MultipartBlock.getCullingShape had in #37.

This issue was encountered in LibMultiPart version 0.7.3-pre.1.

I my specific encounter with this issue, I was using Frex's Pastel renderer. Side note: this is using a version of Frex that is built from the github repo (6.0.247), as the currently released version of Frex (6.0.242) has a bug in its Pastel renderer that causes it to crash.

Full Crash Report

Here is a link to the full crash report on pastebin:
https://pastebin.com/XE0F2YL1

Proposed Fix

The simplest fix here would likely be just to include culling shape in the PartModelData that's currently used for culling-shape and key access in render threads.

Related Issues

This issue reflects the same problem as in #37, just for the part container's collision shape instead of the culling shape.

Looks like I'm also encountering the same issue with MultipartBlock.getOutlineShape as well.

Here is the pastebin link for that: https://pastebin.com/pVexzTup

Funnily enough, all of the concurrency issues I've encountered with this block seem to be caused by ambient-occlusion calculations in render threads.

Huh, I guess I'll just add both shapes to the render thread data object.

I got the chance to work on this myself and decided to submit a pr for it.

Sorry! I got sidetracked. Either way, thanks for the PR!