Search Issue Tracker
Fixed
Fixed in 2022.3.29f1, 6000.0.0b16, 7000.0.0a1
Votes
5
Found in
2022.2.6f1
2023.1.0b3
2023.2.0a3
2023.3.0a3
6000.0.0b15
Issue ID
UUM-2314
Regression
Yes
[CopyTexture][AsyncLoadInEditor] CopyTexture doesn't copy in Editor when 'Load texture data on demand' is enabled
Original issue: [Texture3D Atlas Import Pipeline] 3D Textures are corrupted when 'Load texture data on demand' is enabled
Reproduction steps:
1. Open the attached 'BugReportTexture3D' project
2. Go to the 'Project Settings -> Editor' and make sure the 'Load Texture data on demand' option is enabled
3. Reimport the 'Wall_Gray', 'Wall_Blue', 'Wall_Brown_Stone' and 'New Texture3D Atlas' assets
4. Observe the 'New Texture3D Atlas'
Expected result: The texture is Blue and Gray
Actual result: Textures are not displayed on the 'New Texture3D Atlas'
Reproducible with: 2022.1.0b11, 2022.2.0a7
Could not test with: 2019.4.36f1, 2020.3.30f1, 2021.2.14f1 (no 'Load Texture data on demand' option is available)
Additional notes: this isn't limited to the Texture3D pipeline, even doing a copy to a Texture2D in that same scripted importer fails
Comments (1)
-
Peter77
Mar 04, 2022 15:50
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- After converting a Built-in project to URP render texture related errors are spammed that can lead to Game view being rendered on top of Scene view
- UI Builder slider value lags and stutters when sliding/modifying certain property values
- "Reset UI Builder Layout" functionality inconsistently changes Canva Size when "Match Game View" is enabled/disabled
- Texture Import Warnings are obscured by other Terrain Layer options in the Inspector
- Burst Inspector middle divider is jittering when resized with the Burst Inspector window docked
Resolution Note (fix version 7000.0.0a1):
Issues with CopyTexture not copying CPU data in Editor when "Load texture data on demand" is enabled, have been addressed. Note that we have addressed this issue despite this actually being undefined behavior (since a non-readable texture is only guaranteed to copy GPU-side data)