-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
🪅 Fix blosc loading #73
Conversation
That investigation can easily happen async an decoupled from this PR. As the code got fixed before merging. |
src/reader.rs
Outdated
@@ -229,6 +229,9 @@ impl<R: Read + Seek> VdbReader<R> { | |||
gd: &GridDescriptor, | |||
count: usize, | |||
) -> Result<Vec<T>, ParseError> { | |||
if count == 0 { | |||
return Ok(vec![T::zeroed(); count]); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ya that didn't make sense. I am constructing an empty vec now.
I'm sorry, at the time of merging I didnt know you were still reviewing. |
For a while we have not been able to load blosc encoded files. But that time is no more. After a significant debugging session I found out that OpenVDB does hit this check https://github.com/AcademySoftwareFoundation/openvdb/blob/master/openvdb/openvdb/io/Compression.h#L308 and does an early out if count == 0. We didnt do this check resulting in us reading
num_compressed_bytes
from the reader, reading garbage and offsetting the reader incorrectly.I validated the results against one frame of each of JangaFX's free download models, specifically the ones listed below:
![image](https://private-user-images.githubusercontent.com/31817802/393622860-49eaf3f2-e9ab-4f1c-96f7-8d1b3edbb84f.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MzkxODAxNjQsIm5iZiI6MTczOTE3OTg2NCwicGF0aCI6Ii8zMTgxNzgwMi8zOTM2MjI4NjAtNDllYWYzZjItZTlhYi00ZjFjLTk2ZjctOGQxYjNlZGJiODRmLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNTAyMTAlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjUwMjEwVDA5MzEwNFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTgxOWM2ZWY3MDVjOTZhMWEzZmY5ODc4ZTk3MTMzY2ZlZWRmNzAwYTE5NGE2ZDZkZTcxYjlhYTAzMjdmYzkwNWEmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.HsK28HWp3J1_evEoUbHM8-dVOXlt9Ep0bw9f2LtnzIo)
All these models now load correctly. yay.
The main problematic files remaining are specific exports I made myself with Houdini. These models use f32 for the voxel values, unlike Embergen, which uses f16.
This PR fixes #33