Bug with texture UVs or offsets

[fenomas]

Hi,

 

Latest builds have some kind of bug (or at least breaking change) related to texture offsets.

 

Reproduce:

 

1. Clone this repo (or other projects relying on texture uv offsets)

 

2. Run the local demo per instructions:

cd babylon-atlasnpm installnpm test

(Demo should work normally)

 

3. Replace /example/babylon.js with the latest version of dist/preview release/babylon.max.js

 

(Demo breaks)

 

 

The breaking commit is 6303307. The dist build from before that commit works fine.

 

[GameMonetize]

Hello, actually the commit fixed a BIG bug in texture uv offsets

Can you reproduce your bug in the repo?

[fenomas]

Like I said, bug or breaking change, as a user I can't distinguish. All I know is that setting UV offsets produces a different result now, so code that worked no longer works.

 

Can you reproduce your bug in the repo?

 

What do you mean?

[GameMonetize]

My question is: do you think that results produced are wrong? If yes can you try to create a PG to showcase it ?

 

I *think* the results produced now are correct and were wrong before...but I can be wrong

[GameMonetize]

Here is a test PG:

http://www.babylonjs-playground.com/#2HVWTZ#1

[fenomas]

I don't know which version is correct, because I don't know what the intended behavior is.

 

That is, I got my sprite handling to work with the old version, but it was not very intuitive. Presumably I can rewrite my code to work with the new version, and it may or may not be more intuitive. But unless there's a unit test I can't tell you which is "right", that depends on your intent.

 

So to be clear this is intentionally a breaking change, right?

[GameMonetize]

It is a bug fixing so indirectly a breaking changes. You know that I HATE breaking changes but the behavior of uvScale/offset was wrong so it was a no brainer

 

I can help you fix your code if you want.

 

So here is a basic texture applied to a plane:

var ground = BABYLON.Mesh.CreateGround("ground1", 6, 6, 2, scene);var mat = new BABYLON.StandardMaterial("mat", scene);mat.diffuseTexture = new BABYLON.Texture("textures/misc.jpg", scene);mat.specularColor = BABYLON.Color3.Black();	ground.material = mat;

And the associated render:

 

Now let's add some offsets:

var mat = new BABYLON.StandardMaterial("mat", scene);mat.diffuseTexture = new BABYLON.Texture("textures/misc.jpg", scene);mat.diffuseTexture.uOffset = 0.6;

 

As you can see the texture "moved" to the right by a factor of 60%

 

And now le'ts add some scaling:

var mat = new BABYLON.StandardMaterial("mat", scene);mat.diffuseTexture = new BABYLON.Texture("textures/misc.jpg", scene);mat.diffuseTexture.uOffset = 0.6;mat.diffuseTexture.vScale = 10;

 

 

The issue with previous version was that scaling was wrongly computed resulting (sometimes) in wrong rendering.

 

Hope this helps

 

 

 

[fenomas]

I'm glad this makes sense to you! But to me as a user any scale/translate operation is equivalent to another, except for where the transformation's origin is, and which operation is done first. So without knowing what you're intending for those things I have no way of knowing what you think is correct. 

 

Put it this way - here is a pseudocode declaration of a texture atlas:

var texture_atlas_size = {  w: 444,  h: 333}var sprite = {  x: 123,  y: 234,  w: 34,  h: 45}

If you can tell me what you intend to be the correct code to display that sprite in a texture, then I can tell you if the current implementation is correct. 

[GameMonetize]

so it should be:

uOffset = 123/444

vOffset = 234/333

 

uScale = 34/444

vScale = 45/333

[fenomas]

Okay, current implementation is wrong then. 

 

 

For the current build:

 

vOffset = 1 - (234+45)/333

 

 

Again stuff like this would be easier with a unit test.

[GameMonetize]

What do you mean? How do you get vOffset = 1 - (234+45)/333? Do you think there is a bug in sprite manager? or texture matrix generation?

ok I understood

 

Please provide a playground else this discussion will remain sterile  

[GameMonetize]

Just one thought: did you load the texture with invertY on or off?

http://doc.babylonjs.com/classes/2.2/Texture#new-texture-classes-2-2-texture-url-scene-nomipmap-inverty-samplingmode-onload-onerror-buffer-deletebuffer-

 

Because your vOffset looks like the opposite of mine

[GameMonetize]

Ok so here is a small sample:

 

I would like to get this one:

 

Here are the coordinates (remember that with textures, the origin is at the left  bottom:

 

So the code to get it is the following:

mat.diffuseTexture = new BABYLON.Texture("textures/player.png", scene, false);	mat.diffuseTexture.uOffset = 1233 / 1408;mat.diffuseTexture.vOffset = 60 / 192;mat.diffuseTexture.uScale = 51 / 1408; // Note this is the width and not the coordinate: 1284 - 1233mat.diffuseTexture.vScale = 66 / 192; // Note this is the height:126 - 60

with this result:

 

and the playground:

http://www.babylonjs-playground.com/#4DVSK

[fenomas]

Here are the coordinates (remember that with textures, the origin is at the left  bottom:

 

That's why I said any transformation is as good as another unless you know the intent.

 

Texture atlases measure from the upper left. If the sprite you're using came from an atlas its declaration would be:

frame: {  x: 1233,  y: 66,  w: 51,  h: 66}

and the code to display it (in today's build) would be:

  uOffset = x / texturew;  vOffset = 1 - (y+h) / textureh;  uScale = w / texturew;  vScale = h / textureh;

http://www.babylonjs-playground.com/#4DVSK#1

 

If that's your intention then the current implementation is right. Like I said, without documentation or unit tests it's not really possible for anyone else to talk about correctness without knowing your intention.

[GameMonetize]

Code = intention here (I mean, there is no secret, code is open, my intention is coded inside)

 

Babylon.js is a community project. I cannot do everything by myself. Please update the doc with whatever you may find useful. This is why the project is open sourced. To work together to provide a better framework

[GameMonetize]

Perhaps just adding this image in the documentation could help?

[GameMonetize]

Actually I did it:)

http://doc.babylonjs.com/tutorials/04._Materials

[fenomas]

Code = intention here (I mean, there is no secret, code is open, my intention is coded inside)

 

Well, code only = intention if it's correct.     In this case you were asking if the code was correct, so that's why I asked about intention.

 

 

Chatter aside, it would be really useful if the playground had a way to specify using BJS 2.2 or 2.1. I would like to have reported this issue with a PG, but I had no way to check that the code would have worked under 2.2 for comparison.

[Dad72]

VOffset or VScale, V = Vertical, thus automatically by from bottom to top.

[adam]

Chatter aside, it would be really useful if the playground had a way to specify using BJS 2.2 or 2.1. I would like to have reported this issue with a PG, but I had no way to check that the code would have worked under 2.2 for comparison.

 

I was thinking something similar today.  A dropdown for babylonjs versions would be awesome.

[GameMonetize]

It is a good idea. I'll add it to my LOOONNNNG todo list

 

 

 

In this case you were asking if the code was correct, so that's why I asked about intention.

Tha'ts true  

[Vousk-prod.]

Oh my fracking god!!! That particular change have broken every materials of every projects I'm working on! Fine tuned speculars, bumps, reflections, everything is affected

I'm not using offsets and scales to address sprites in spritesheets, I'm using them to produce materials as realistic as possible thanks to multiple UVs and textures layers usage.

 

I'm happy to see that a bug was fixed, but manually redoing hundreds of materials in a lot of materials libraries would be an endless and painfull job... I'm sure there is a smart way to do that, based on how things have changed!

 

Please DK, would you mind providing us a quick explanation on what the bug was, what have changed and which parts of standardMaterial were affected by the fix (UVscales and offsets, every texture slots, something else ?).

I tried to find the incriminated commit but didn't managed to spot it.

 

Do you think it's possible to deduce from your changes a brief "converting rule to follow" to be able for us to properly fix materials without requiring to refine each one visually ? That would be very nice.

[GameMonetize]

Only UV scale and offset changed.

 

The simplest way for you could be to force this (use the old formula):

BABYLON.Texture.prototype._prepareRowForTextureGeneration = function(x, y, z, t) {  x -= this.uOffset + 0.5;  y -= this.vOffset + 0.5;  z -= 0.5;  BABYLON.Vector3.TransformCoordinatesFromFloatsToRef(x, y, z, this._rowGenerationMatrix, t);  t.x *= this.uScale;  t.y *= this.vScale;  t.x += 0.5;  t.y += 0.5;  t.z += 0.5;}

For the record here is the new version:

x *= this.uScale;y *= this.vScale;x -= 0.5 * this.uScale;y -= 0.5 * this.vScale;z -= 0.5;Vector3.TransformCoordinatesFromFloatsToRef(x, y, z, this._rowGenerationMatrix, t);t.x += 0.5 * this.uScale + this.uOffset;t.y += 0.5 * this.vScale + this.vOffset;t.z += 0.5;

So globally, now scaling is done BEFORE translation which was not the case before

 

Now: scaling x rotation x translation

Before: translation x rotation x scaling

[Vousk-prod.]

Thank you so much DK!!!

[GameMonetize]

Does it make sense ? Do you disagree with the changes?