-
Notifications
You must be signed in to change notification settings - Fork 250
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 byte boundary issue #279
Conversation
Testing now. |
I can confirm this fixes the problem I was seeing. Thanks! |
This also fixes #277, which was also offset related. |
@lilleyse were you going to do more work here, or is this OK to merge? I know this module is still alpha, so not sure if we're doing unit tests yet or not. |
Yeah I should add a unit test, I'll update soon. |
Awesome, thanks. I have a feeling this will fix quite a few issues I've ran into recently. |
Added test. |
Thanks @lilleyse! The new test fails in master and passes with this fix. |
@lilleyse w.r.t the glTF spec does Cesium need a fix? The intent of the spec is to allow creating "pointers" with typed arrays instead of copying buffers. |
Yeah Cesium would need a fix because nothing was wrong with the previous output. Cesium would need to adjust the byte offset of where it creates the index buffer's typed array. Does the gltf spec allow an accessor to exist on a non-aligned byte offset? That would be a more serious issue, and require a copy. |
Please submit an issue to Cesium.
|
@lilleyse @pjcozzi The intent is that no copy is needed. |
Ok that is good to know. Thanks for pointing me there @lexaknyazev. |
Closed CesiumGS/cesium#5309 |
There was an issue related to byte offsets when loading models converted here into Cesium. Before an index accessor might look like:
Which is valid since
accessor_2
is still 4-byte aligned whenbufferView_1
itself has the correct offset from the centralbuffer
.However since Cesium creates a typed array from the buffer view, and not the buffer as a whole,
accessor_2
would begin on byte 2 of aUint32Array
, causing the indices to be incorrect.The fix here forces the first accessor of each target to start with a
byteOffset
of 0 to prevent situations like this.@mramato can you test this?