ES6 version incoming


#1

We are planing to ship and merge our ES6 work in 2 weeks. As it is about 500 commits and 1400 files https://github.com/BabylonJS/Babylon.js/compare/master...libToModules?expand=1 changed, it is not a small change :slight_smile:

This is for the best as you will be able without custom workload build to drop you package size from 2.2Mb to 940k on a 360 viewer :slight_smile: by relying on tree shaking.

With that in mind, could you please either all make your in progress PRs now or hold them for after the merge ?

Also we ll be monitoring a lot the forum after the merge as it might introduce some new issues. We have been testing carefully the new version but due to the size of the changes, we might have let one or two bugs in.

We ll ping you again once it has been merged on master to start the real test phase :slight_smile:


#2

Cool project! Ballsy. Thanks!

:slight_smile: We’ll freeze dev when you reach 3 hours until merge.

What’s that you say? Too tight? heh.

Curious… is a version number going to change? Probably so, eh?

(Wingnut shakes a nearby tree, and an acorn falls/lands on his head. He thinks the sky is falling, and runs-off to tell the king.) :wink: (obscure ref to children’s story “Chicken Lickin’”)


#3

Yup it is for version 4.0.0 so major update :slight_smile:


#4

@sebavan Not meaning to nag, but when you are talking about “in two weeks”, do you have some particular date in mind? Can’t wait to try it out!


#5

I have a dry run with @Deltakosh on tuesday where we might merge if everything looks good.

So should be really soon :slight_smile:


#6

Congratulations on this milestone! Now an alpha release and the testing can begin :slight_smile:


#7

The code has been merged and we should push our new packages on thursday after letting the UMD version living for a bit to identify any big issues.


#8

Wow - this is so exciting!! I think that I first asked April 2017 when somebody mentioned 3.0 was getting big, but this is such a massive change (BJS 3.0 is packing on the pounds! - Questions & Answers - HTML5 Game Devs Forum). I don’t use “BABYLON.” in any of my code, so I’m looking forward to see the file size differences. Congratulations :slight_smile:


#9

From Deltakosh tweet, you can see the tiny PR about that here :sweat_smile:


#10

Hi guys. I have some issues with PG “latest” version.

https://playground.babylonjs.com/#5W5B6W#14 — Lines 4 and 785 never run.

https://www.babylonjs-playground.com/#1PVBTF#104 — Lines 4 and 785 never run.

These OimoJS joint-work playgrounds… USE TO “hijack-in” the OimoJSPlugin and PhysicsImpostor over-ride code at top of playground. They appear to be broken or something changed.

Could be Wingnut screw-up, too, of course. Firefox 60.3.0 ESR (extended support release).


For Internet Explorer 11.0.9600.etc (these PG’s not tested in my IE… before now)…

IE console for #14 playground: (failed to render)…

DOM7011: The code on this page disabled back and forward caching. For more information, see: http://go.microsoft.com/fwlink/?LinkID=291337
File: playground.babylonjs.com
HTML1300: Navigation occurred.
File: playground.babylonjs.com
SCRIPT1046: Multiple definitions of a property not allowed in strict mode
File: Oimo.js, Line: 1, Column: 32942
SCRIPT1002: Syntax error
File: gltf_validator.js, Line: 8456, Column: 42
SCRIPT1002: Syntax error
File: babylonx.cloner.js, Line: 5, Column: 5
SCRIPT1002: Syntax error
File: babylonx.CompoundShader.js, Line: 5, Column: 5
SEC7118: XMLHttpRequest for https://raw.githubusercontent.com/BabylonJS/Documentation/master/examples/list.json required Cross Origin Resource Sharing (CORS).
File: playground.babylonjs.com
SEC7118: XMLHttpRequest for https://snippet.babylonjs.com/5W5B6W/14 required Cross Origin Resource Sharing (CORS).
File: playground.babylonjs.com
SyntaxError: Syntax error
   {
      [functions]: ,
      __proto__: { },
      description: "Syntax error",
      message: "Syntax error",
      name: "SyntaxError",
      number: -2146827286,
      stack: "SyntaxError: Syntax error
   at Anonymous function (https://playground.babylonjs.com/js/index.js:556:25)
   at getRunCode (https://playground.babylonjs.com/js/index.js:7:5)
   at compileAndRun (https://playground.babylonjs.com/js/index.js:523:17)
   at xmlHttp.onreadystatechange (https://playground.babylonjs.com/js/index.js:1128:37)"
   }

IE console for #104 playground: (failed to render)

DOM7011: The code on this page disabled back and forward caching. For more information, see: http://go.microsoft.com/fwlink/?LinkID=291337
File: playground.babylonjs.com
HTML1300: Navigation occurred.
File: www.babylonjs-playground.com
DOM7011: The code on this page disabled back and forward caching. For more information, see: http://go.microsoft.com/fwlink/?LinkID=291337
File: playground.babylonjs.com
SCRIPT1046: Multiple definitions of a property not allowed in strict mode
File: Oimo.js, Line: 1, Column: 32942
SCRIPT1002: Syntax error
File: gltf_validator.js, Line: 8456, Column: 42
SCRIPT1002: Syntax error
File: babylonx.cloner.js, Line: 5, Column: 5
SCRIPT1002: Syntax error
File: babylonx.CompoundShader.js, Line: 5, Column: 5
SEC7118: XMLHttpRequest for https://raw.githubusercontent.com/BabylonJS/Documentation/master/examples/list.json required Cross Origin Resource Sharing (CORS).
File: www.babylonjs-playground.com
SEC7118: XMLHttpRequest for https://snippet.babylonjs.com/1PVBTF/104 required Cross Origin Resource Sharing (CORS).
File: www.babylonjs-playground.com
Babylon.js v4.0.0-alpha.17 - WebGL1
ReferenceError: 'OIMO' is undefined
   {
      [functions]: ,
      __proto__: { },
      description: "'OIMO' is undefined",
      message: "'OIMO' is undefined",
      name: "ReferenceError",
      number: -2146823279,
      stack: "ReferenceError: 'OIMO' is undefined
   at e (https://preview.babylonjs.com/babylon.js:16:1507690)
   at createScene (eval code:1213:2)
   at eval code (eval code:1:1)
   at Anonymous function (https://www.babylonjs-playground.com/js/index.js:565:25)
   at getRunCode (https://www.babylonjs-playground.com/js/index.js:7:5)
   at compileAndRun (https://www.babylonjs-playground.com/js/index.js:523:17)
   at xmlHttp.onreadystatechange (https://www.babylonjs-playground.com/js/index.js:1128:37)"
   }

ALL Firefox tests WORK FINE in “stable” mode (BJS 3.3). Hijacks active.
ALL IE tests fail in both “latest” and “stable” - no scene render.

I can do my work… in stable version… minor inconvenience. But, I thought I had better report all unusual stuff seen. ES6-related? Perhaps I need to post this in bugs or q&a? thx for info/work.


ES6 version merged
#11

Thanks @Wingnut, so it seems some of the OIMO and other libs in use is not compatible with IE since before the merge, I doubt we should invest on this area too much.

About the Object Hijacking you are trying to do, as the code is now using webpack, it works in its own BABYLON context, not necessarily something you can override (imports should not be easily overridable). This was already the case in GUI for instance. Let me see if I can find something easy to allow this.


#12

@sebavan thanks a lot, I used to check out your branch every now and than, you’ve done wonderful work there, can’t wait to try it out. :slight_smile: will let you know when I’m done.


#13

@Wingnut as a workaround, just instantiate your own objects: https://playground.babylonjs.com/#5W5B6W#16

vs the BABYLON. ones.

To add the rational behind it, Webpack defines export as property via
if(!webpack_require.o(exports, name)) {
Object.defineProperty(exports, name, { enumerable: true, get: getter });
}

The property is not configurable so not overridable. It is for the best cause hijacking at this level would not hijack the current one in dependant modules and would probably end up in unexpected runtime behaviors.

You could still nevertheless modify the prototype at will, the only none overridable part would be the constructor hence the use of your own objects instead of spoofing the BABYLON. ones.


#14

Lots of demos and projects were made with Oimo. Please reconsider. It was the default physics engine for a LONNNNG time.


#15

I ll try to track down the IE issue but it looks like OIMO is not compatible with IE so unfortunately it is not totally in our hand:

I would have love it to be an issue in our code :slight_smile: that would have been much easier.


#16

I think we can hack it, right? I have already seen occurrences of BJSOimo running around (not sure what the story is, on that)… but… we can adjust Oimo however we wish, I think. Active dev on it… ended, I think.

To me, Oimo is as important for backward compat… as any other backward-compat concern we might have. @deltakosh is also trying to wash his hands of Oimo. Were things talked-about? Decisions made?

Can we see the discussion, if indeed a “Future of Oimo in BJS” discussion took place?

(sorry for screwing up the ES6 topic. perhaps we should wander-off somewhere else) :slight_smile:


#17

Agree on a new topic for this an let see if @trevordev can fix it for IE :slight_smile:


#18

Please keep in mind that all experiments not relying on our API are not covered by our “back compat” policy. So if you hijack something, this could be break in the future


#19

Yeah, I understand that, even though I often forget that. :slight_smile:

Hijack code into playground… that is ONE subject… and I use it heavily for troubleshooting core issues. Don’t need to, but handy.

Now, if you mean hijacking our own version of Oimo and maybe renaming it and glue-coding it into backward compat… that is ANOTHER thing. That is a DIFFERENT kind of “hijacking” heheh

But, weirdly, Deltakosh’s comments… apply to BOTH kinds of hijacking.

How did he DO that? haha. New thread, same topic: The Future of OimoJS in BJS

Something “feels good” about BJS Inc… just blatantly “running-with” its own version of Oimo. hmm. See the new thread… for more, and to pummel Wingnut as bloody as you wish. heh


#20

There is no back compat issue per se as OIMO seems to not be compatible with ie since at least 2 years :slight_smile:

I am looking at how to integrate support for it in the next release.