Fix misuse of read and skipBytes#2557
Conversation
|
This patch may (still) actually cause an issue with GLTF loader. Essentially requiring the "full skip" and erroring on EOF can cause failure. From an asset I'm working with: int end = count * stride + byteOffset; //1839200, when the actual byte array backing it is only 1839188 long
stream.skipBytes(byteOffset);
while (index < end) {
//Index is 1839136, reads the last value
for (int i = 0; i < numComponents; i++) {
buffer.put(readAsFloat(stream, format));
}
if (dataLength < stride) {
//Tries to skip 52 bytes; but 1839136+52=1839200 > 1839188
stream.skipBytes(stride - dataLength);
//Throws EOFException here
}
index += stride; //Would set index to 1839200 and skip loop
}(I'd add the asset as example since it messes up so much, but it's Unreal licensed.) |
|
🖼️ Screenshot tests have failed. The purpose of these tests is to ensure that changes introduced in this PR don't break visual features. They are visual unit tests. 📄 Where to find the report:
✅ If you did mean to change things: ✨ If you are creating entirely new tests: Note; it is very important that the committed reference images are created on the build pipeline, locally created images are not reliable. Similarly tests will fail locally but you can look at the report to check they are "visually similar". See https://github.com/jMonkeyEngine/jmonkeyengine/blob/master/jme3-screenshot-tests/README.md for more information Contact @richardTingle (aka richtea) for guidance if required |
00f18ca to
b29ff63
Compare
Fixes #2555 across the entire engine.
This PR fixes the implementation of
LittleEndien.readFully()and introduces two new utility methods inByteUtils:readFullyskipFullyBoth ensure that the requested number of bytes are reliably read or skipped, even if the underlying stream does not return the full amount in a single call.
The changes are not yet fully tested, but they are part of the codebase I am actively working with. Additional testing and verification from others would be greatly appreciated.