LoadLEV() Texture and Animated Texture loading#39
Open
Blounard wants to merge 2 commits intomateusfavarin:mainfrom
Open
LoadLEV() Texture and Animated Texture loading#39Blounard wants to merge 2 commits intomateusfavarin:mainfrom
Blounard wants to merge 2 commits intomateusfavarin:mainfrom
Conversation
Modify LoadLEV() to implement the loading of textures and animated textures
Improved the texture parsing to try to be closer to what CTR does. It no longer assumes that textures and animTextures are all in order after MeshInfo and before Quadblocks. Instead it parses quadblock exclusively, and determines if a texture is animated or not with PointerMap, and only header.offAnimText
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Modify LoadLEV() to implement the loading of textures and animated textures.
What should work : Loading a .lev file, with a .vrm file of the same name in the same folder will create the required .png files and .obj file for textures and animated textures.
Those textures can be edited, and the track can be re-saved afterward.
Work for the renderer, and work for re saving .lev files.
Create 1 material per texture file used, it allow for some quick modifications of some quadblocks attribute if they share the same texture file.
The extracted texture should always be cropped accordingly to all the quadblock UVs, so it should always be possible to regenerate the .vrm file afterward without hitting the VRAM size limit.
What does not work : Some custom tracks created with some older version of CTE won't be correctly extracted. 1 example is Drive Thru Danger, saphi edition, some quadblocks have raw UV stored in the .lev that goes outside of the actual texture range (by 1 pixel). I believe it's because older version of CTE had a different code in Texture::Serialize, with a "hack" to fix a "off by 1" pixel issue. Therefore, the texture extracted are bigger than the original, because the code try to extract from a wider range in the VRAM page. This can prevent the VRAM to be re generated, because the re created textures are bigger than the originals.
I haven't found a fix to that, but it's probably only an issue for track created with CTE 0.26 or older.
I confirmed with Boxic that DTD .lev and .vrm files re created with CTE v0.30 with the same presets are correctly opened, without UV issues.
What can't be implemented without some massive rework : Vanilla track are poorly loaded with this function because all 4 faces of each quadblock can point to different textures files (from different VRAM pages). It means vanilla quadblocks need several material, or material needs several textures to be correctly represented. Currently CTE has 1 material per quad, and 1 texture per material, so this isn't possible. (Currently, if you load a vanilla track with this PR, the texture of 1 of the face will be used for all 4, so it's messy)