[jak3] texture animations catch-all

[Hat-Kid]

Most texture animations have been added and work, but a couple of issues still remain:

• hanga-sprite: Despite move_to_pool being set for this anim, it's not showing up in-game, but it does display properly in the ImGUI debug window.
  
• factoryc-alpha: Some conveyors do not have the animation for some reason. We were missing TIE support for texture animations.
  
• This spot in Spargus seems to use texture animations, but it looks like it maps to the fora-water-dest texture/slot, which comes from foresta-water. Because the texture is not initialized, the texture shows up black on first load, but it does show up after loading foresta.
  
  
• hfrag texture anim is not handled yet. Probably needs some special casing.
• darkjak-highres: Eye texture slot animates, but the model still uses the default eye texture.

[TomChapple]

Warning

I have very little experience here so it is likely I may be misinterpreting something.

On the topic of "hanga-sprite", I'm curious if "glider-ring-dest" should contain "glider-ring-dest2" within its texture data in that ImGui screenshot.

Looking at the dynamic data, "glider-ring-dest" refers to "glider-ring-dest2" in the first element (layer?). Each layer is interpolated, so it makes sense to me that it is pulling from this other animated texture. I'm tempted to compare this to the part "group-forest-ring", but there are some minor differences that look like it will act differently. Nevertheless, I haven't found a function call that will warp me to "foresta-ring-chase" to compare them.

[TomChapple]

Well I have something, but I'm not sure how relevant it is. Changing the source texture for layer 0 of "glider-ring-dest" to match the destination texture of "gilder-ring-dest2" (currently hardcoded) results in the animated texture being visible in-game as seen below.

I got this effect with the following snippet:

diff --git a/game/graphics/opengl_renderer/TextureAnimator.cpp b/game/graphics/opengl_renderer/TextureAnimator.cpp
index 9025a6d..beb4a93 100644
--- a/game/graphics/opengl_renderer/TextureAnimator.cpp
+++ b/game/graphics/opengl_renderer/TextureAnimator.cpp
@@ -2526,8 +2526,15 @@ void TextureAnimator::run_fixed_animation(FixedAnim& anim, float time) {
           (time - layer_def.start_time) / (layer_def.end_time - layer_def.start_time),
           &interpolated_values, layer_dyn.start_vals, layer_dyn.end_vals);
 
+      // Force to 936
+      auto stex = anim.src_textures.at(layer_idx);
+      if (anim.def.tex_name == "glider-ring-dest" && layer_idx == 0) {
+        stex = 936;
+        lg::debug("forcing glider-ring-dest layer #0 source texture to {}", stex);
+      }
+
       // shader setup
-      set_up_opengl_for_fixed(layer_def, anim.src_textures.at(layer_idx));
+      set_up_opengl_for_fixed(layer_def, stex);
 
       set_draw_data_from_interpolated(&draw_data, interpolated_values, anim.fbt->width(),
                                       anim.fbt->height());

However, it can probably be seen that the hue is no where near as blue as it should be. Not only that, but the animation is awfully still in comparison with the original game. It's animated, but it is as if the intensities of the keyframes are incorrect in some regard. The "splash-foam" looks static for the most part.

The ID of the destination texture for "glider-ring-dest2" was 936 in my case, but I'm not sure if it changes depending on different loading patterns.

I have a feeling that something is intended to happen between writing to the destination texture in "glider-ring-dest2" and using the source texture in "glider-ring-dest", maybe some other form of interpolation to change the hues and intensities. But other than that, I hope this helps with any diagnosis!

[TomChapple]

I have been doing some thinking about the difference in hue from the little test I did and the vanilla game. When I look back at TextureAnimator, I didn't see any configuration for manipulating the texture's colour. The "gilder-ring-dest2" definitely takes advantage of this, even setting the blue component to about twice its usual value.

Has blending animated textures with colour been implemented? If it isn't, that would explain why the hue is off. I totally expect that I have missed it somewhere.

[TomChapple]

I was able to discover how colour blending is implemented, so I have answered my own question. I didn't realise that the static data was defined again in TextureAnimatorDefs.cpp but the dynamic data (including the colour) was loaded in from DMA. At least I now have a point of reference to go from.

[water111]

Hey @TomChapple - sorry I totally missed these comments!

Thanks for taking a look through our somewhat questionable TextureAnimator.cpp. I think we have this working now, and your ideas were all correct.

Changing the source texture for layer 0 of "glider-ring-dest" to match the destination texture of "gilder-ring-dest2" (currently hardcoded) results in the animated texture being visible in-game as seen below.

Yep - this was basically the issue. The glider-ring-dest layer 0 referenced the output of animation glider-ring-dest2, but the texture animator didn't support this case. Instead, it just gave you the non-animated texture named glider-ring-dest2. I've got a fix for that here: #3732

I have a feeling that something is intended to happen between writing to the destination texture in "glider-ring-dest2" and using the source texture in "glider-ring-dest", maybe some other form of interpolation to change the hues and intensities.

Right again. The final layer in the original game code sets :func-id 'set-alpha-texture-anim-layer-func instead of the normal default-texture-anim-layer-func. The set-alpha version will modify the glider-ring-dest2 to set the alpha channel to 128. This was missing from the definition in TextureAnimatorDefs.cpp, so the alpha ended up being a much smaller value, making the ring look washed out. When glider-ring uses glider-ring-dest2, it ends up multiplying the RGBA of glider-ring-dest2 by the texture's alpha, so if the alpha is wrong, the colors end up wrong.

[TomChapple]

That's awesome to see that working now! It's all good about the comments, they were only there to avoid retreading ground if possible (though I was definitely aware that they may have been obvious to frequent contributors). Seeing that ''set-alpha-texture-anim-layer-func change the alpha channel further is definitely interesting, though!

Thanks for responding, I definitely want to look at this a bit more in the future and your response is very encouraging to do so! I should try and get my dev environment setup again at some point, but Nix is definitely a different beast to what I'm used to.

[Hat-Kid]

Fixed in #3732, #3734 and #3735