UPBGE 0.2 - Textureblock "LOD Bias" mipmapping setting affects UV Editor "sprite animation" coordinates

UPBGE / upbge

UPBGE, the best integrated game engine in Blender

https://upbge.org

Other

1.44k stars 180 forks source link

UPBGE 0.2 - Textureblock "LOD Bias" mipmapping setting affects UV Editor "sprite animation" coordinates #1353

Open rpaladin opened 3 years ago

rpaladin commented 3 years ago

Whenever I try changing the LOD bias for my sprite texture, the animation sprite's UV location changes equally - makes animated 2D pixel sprites almost impossible.

Edit. Oh, & another thing - when quitting embedded/standalone player the UV location is also not reset to the value it was on init. For instance it started at [0,0] but when you quit the player while the UV location was at [4,4] it stays at [4,4] instead of reverting to the init value of [0,0].

lordloki commented 3 years ago

Could you add a little blend to test? Thanks in advance

rpaladin commented 3 years ago

Could you add a little blend to test? Thanks in advance

Sure. 2 things btw.

For some reason I can't remake the UV init bug I thought existed - my bad?
The UV location continues to chance when 'LOD bias' is changed, but not just for that value, but also when changing the camera view in the 3D view-port, not to mention when moving the animation timeline ...

Blend file. Anim.zip

lordloki commented 3 years ago

For me it works when you select start:0 and end:7

This way LOD bias blur the image while this one is animated.

PD: The init bug exists

rpaladin commented 3 years ago

The animated texture function working wasn't the problem that I found unusable. I found the 'LOD Bias' (Custom mipmapping setting) option disrupts the texture UV process - makes my animation play off to the side for example.

I would like to animate a 'static' UV location, not a random 'dynamic' UV location :D

lordloki commented 3 years ago

Really, i dont know where is the issue. I compared with respect to upbge 0.2.4 and it is the same:

https://user-images.githubusercontent.com/1015605/102942723-62f6a500-44b6-11eb-8937-d18138a6ef5d.mp4

rpaladin commented 3 years ago

Think of it this way. In pixel 2D games, you can't see the 'mesh' itself - only the 2D texture. So whenever the 2D texture scales, you see it visually scale - this shouldn't happen ... I realize most 2D games don't normally use mipmapping, but maybe you want to use 2D textures for pixel use in 3D. Like me ^^ I propose maybe some 'automatic scaling' perhaps whenever you tweak the mipmapping size. That way you'll get a blur, but at the same pixel size as when it was set to original mipmapping (LOD Bias 0.0).

rpaladin commented 3 years ago

@Feral3d has now come across the 'mipmapping effecting sprite-animation' problem and wondering if there is a possible fix. This is the exact problem I was trying to describe earlier, but Feral has done a better job explaining it, my apologies if I was unclear earlier in this thread. https://discord.com/channels/481036814539292672/719227472171761724/794233149420732456