Breaking changes when migrating from 3.* to 4.*?

I migrated my project from bjs 3.3.0-rc.3 to 4.0.0-alpha.18. I don’t remember the old GUI version, but I updated it as well.

Technically it runs, but it seems the migration introduced some bugs -

  • Mesh animations are a bit messed up and have some crazy behaviors.
  • GUI bugs:
    • Parts of removed controls remain rendered on the screen.
    • Transparency has weird flashes and renders a big black box around the control.
    • Text controls sizes are no longer computed accurately.

Here’s the project after the migration:
https://tengugaming.com/game.php?id=creaturesOfTheDeep&beta=true

Here’s the legacy version where everything works as it should:
https://tengugaming.com/game.php?id=creaturesOfTheDeep

A few cosmetics aside, I haven’t changed any logic after the migration.

Here’s a screenshot demonstrating all 3 GUI bugs mentioned above:

Thanks for trying out the latest version and reporting your issues :slight_smile: ,

For the gui issues, this is likely a bug in the invalidateRect gui optimizations, if you could share a code snippet or playground you believe repro’s the issue it would be helpful for me to look at. In the meanwhile you can try

advancedTexture.useInvalidateRectOptimization = false;

which should give you back the original behavior. (let me know if this still doesn’t fix the problem)

For mesh animations, maybe @bghgary might know what could cause this.

1 Like

For mesh animations, maybe @bghgary might know what could cause this.

Are these glTF assets? @royibernthal Can you provide a playground with a repro?

Hey @royibernthal glad to see you back man!!

Would you mind to try to create some repro for us. We added a big optimization to GUI as @trevordev mentioned and we could use some repro of your issues in the PG :slight_smile:

1 Like

@trevordev Setting useInvalidateRectOptimization = false indeed solved most of the issues. It seems however that the text control size issue (resizeToFit) still remains.

I’ll try to send a repro of that and the invalidateRect issues as soon as I can :slight_smile:

EDIT: After some more testing, there’s no bug with resizeToFit after all.

@bghgary These are .babylon files created by Blender Exporter.

It seems the issue occurs when applying my shader, and it’s affected by the position. See “Repro Settings” in the PG.

Rotate the camera (e.g. using your mouse) to see how the models become distorted.

Looking at the log, I noticed the following errors:

You can also compare it to the stable version and see that it doesn’t happen there.

PG: https://www.babylonjs-playground.com/#3B5YN6#10
Stable: https://www.babylonjs-playground.com/indexStable.html#3B5YN6#10

@Deltakosh Hey man it’s good to be back :slight_smile:

I’ll try to repro everything as soon as I can.

I tried to repro the GUI issue in a PG, no luck so far. Is the namespaces version in the PG really identical to the es6 modules version? Is there some PG where I can experiment with the latter?

Also, any idea what’s going on in the meshes / shader repro I mentioned in my previous reply?

1 Like

As you know we need to get a repro in the Playground to quickly help you (at least for the meshes/shader issue)

If you do not repro the GUI error, can you make sure to use the very latest 4.0 alpha for both core and gui?

I did repro the meshes/shader issue in a PG :slight_smile:

It seems the issue occurs when applying my shader, and it’s affected by the position. See “Repro Settings” in the PG.

Rotate the camera (e.g. using your mouse) to see how the models become distorted.

Looking at the log, I noticed the following errors:

You can also compare it to the stable version and see that it doesn’t happen there.

PG: https://www.babylonjs-playground.com/#3B5YN6#10
Stable: https://www.babylonjs-playground.com/indexStable.html#3B5YN6#10

I just installed the core and gui packages again to make sure they’re the latest, still getting the same version (4.0.0-alpha.18). I compiled again just in case, the bugs persist.

Personally I do not mind setting useInvalidateRectOptimization = false in my project and calling it a day.

With that said, I would still like to help you find those bugs, I don’t mind giving you access to the source code (privately of course).

Otherwise, let me know if you have any other ideas of how I can help you find the bugs more efficiently.
Do you have any suspicion at all as to what’s happening? Something that can maybe give me a better direction on what to repro?

the latest is this one:


I’ll check the shader issue asap!

1 Like

Oh wait you are using your own shaders? This is why :slight_smile: shaders evolved a lot

Why do you need your own shader?

1 Like

Package - weird, I’ll try to uninstall then install again later today when I get home and see if I can get that latest version.

Shader - yeah, I need my own custom underwater effect :slight_smile:
Is migration required for it to work in the new version? Shouldn’t bjs be backward compatible or is this an intended breaking change?

Shaders are not part of that contract. Only public API are concerned by the backward compatibility or we will be lock forever with identical renderings.

1 Like

ok actually I know why :slight_smile:
This is because of the new bone texture system
This is a new feature of 4.0. Instead of using uniforms which are limited we are now using textures to store bone data.
But no worries , I got you covered :slight_smile:
Babylon.js Playground (see line #515)

Got it, thanks :slight_smile:
Does this new feature improve performance by any chance?

I tried to uninstall both core and gui then install them again - same version (alpha.18). I tried to install @latest - same version. @next - doesn’t exist. What am I missing?

EDIT: I get the same thing when creating a completely new isolated project as well. Are you sure it’s possible to fetch alpha.27 via npm?

it should improve but just a bit. It is mostly done to reduce the need for uniforms (especially on low end devices)

@preview is the way to get it

Got it.

GUI bugs are solved in the @preview version. How do I get rid of that unmute button?

1 Like

You cannot get rid of it as browsers are forcing us to get a suer action before being able to play a sound.

You can obviously change the CSS used to move the icon of course (or start the sound after having your user clicking somewhere)

They are, but they’re not forcing us to have that kind of icon.

I’d like to worry about the user action to enable audiocontext myself and not have an extra piece of GUI forced on me.

Why not have an optional flag for that icon?

If set to false - audiocontext will start whenever clicking anywhere on the page like in bjs 3.* (which is sufficient user action) instead of on the unmute icon.

In my opinion, it shouldn’t be limited to clicking on the icon itself even when it is displayed, unless there are some technicalities I’m not aware of.

This is already possible then:

BABYLON.Engine.audioEngine.useCustomUnlockedButton = true;

Perfect.

I just noticed another GUI issue which didn’t happen in bjs 3.*. This one is not affected by useInvalidateRectOptimization.

It seems that when listening to onPointerUpObservable in text fields (and possibly in other cases), the events are not fired until the mouse leaves the canvas area.

With buttons I don’t seem to have that issue.

PG:
https://www.babylonjs-playground.com/#XCPP9Y#910

Click on the counter, and see that it only updates when the mouse leaves the canvas.