ThreeJS RGBELoader加载HDR文件时出现‘unsupported type: 1009’错误求助
Let’s work through fixing this issue—I’ve run into similar hiccups after Three.js version upgrades, and this error boils down to a mismatch between how the updated RGBELoader expects to handle HDR data and your current code setup.
Core Fix: Adjust the Data Type
The main problem here is using THREE.UnsignedByteType with RGBELoader. HDR files store high dynamic range information using floating-point values, and UnsignedByteType (an 8-bit integer format) can’t properly interpret that data.
You have two simple, effective fixes:
- Remove the
setDataTypecall entirely—RGBELoader will default to a compatible floating-point type (usuallyTHREE.HalfFloatType) - Explicitly set the data type to
THREE.HalfFloatType(recommended for consistent behavior across versions)
Here’s the updated code:
// (资产加载器中获取资源路径及.hdr文件url的前置代码) if (type == 'hdr') { new RGBELoader() .setDataType(THREE.HalfFloatType) // Replace UnsignedByteType with this .setPath( _BASE_ASSET_URL ) .load( url, function ( loadedItem ) { scope.assets[name] = loadedItem }) }
Why This Happened
After the version upgrade, RGBELoader added stricter validation for HDR file headers. The "unsupported type: 1009" refers to a header flag that signals the HDR file uses a floating-point format, but your code was telling the loader to expect 8-bit unsigned integers—so it couldn’t parse the file correctly.
Additional Troubleshooting Steps
If the core fix doesn’t resolve the issue, try these checks:
- Verify your HDR file isn’t corrupted: Re-export it from your 3D tool or test with a known-working HDR file to rule out file damage
- Check Three.js release notes for RGBELoader changes: Sometimes upgrades introduce new required configuration options
- Avoid
UnsignedByteTypefor HDR: If you absolutely need an 8-bit format, you’ll have to tone-map the HDR to LDR first (but this defeats the purpose of using HDR for dynamic range)
内容的提问来源于stack exchange,提问作者curmudgeonyprogrammer

