Some but not all transparent animated texture broken about opentomb HOT 5 CLOSED

Special shout-out to TR5,10, which manages to feature both in the same area. E.g. coords 45190, 30012, -10496, rotation 60, 0, 0

from opentomb.

I must note that before animated textures were broken, there was a special script command UVRotate, which resembled TR4/5 script command with the same name. When such command was present in level script, it forced UV rotation animating method on particular animation texture sequences. So what we see here is classic animation sequences are working, while UV-rotated ones are broken. They are just two different types.

What may give you some clues is, recently TeslaRus made a code which kind of converted UV-rotated ones to classic mode, by generating pre-calculated frames with different texture coordinates. He did this to simplify code, because dealing with UV coordinates on the fly could be tricky with shader code (as I remember that). It is done in TR_GenAnimTextures function.

What is more weird is that UVRotate type works on entity polygons! As example, see TR4's first level, where you have a big waterfall and pool ("your average priceless seaweed" et cetera). Both types are working there.

from opentomb.

BTW, @TeslaRus actually has fixed that issue in his branch. Somebody need to port it to master.

from opentomb.

To port this changes, first are needed port / review animation textures applying. I.E. I apply animation to the transparency textures BEFORE adding to BSP tree, so I can split any polygons as I want, without animation textures broking (+it works faster: less textures coordinates transformation, but information about lighting are loosed (it is fixable)). I did not touch opaque textures. + I change anim sequences structures (UV animation type refactoring).
About fixing: not at all working... library.tr4: water surfaces (not streams) is frozen (sequences count = 0 in level data, anim_textures count = 1). May be in Core Design was "default textures animations"...

from opentomb.

Closing this, as it's directly related to #17.

from opentomb.