Possible new issue with mesh in VideoDome

Bugs
1

Today, a video played in a mesh in VideoDome stopped working. Instead of playing inside the mesh it started playing outside the mesh. I may be importing the wrong code. In the index.html file, what is the correct code for src = “???” to support VideoDome?

It is also possible that a new preview may break the code for AdvancedDynamicTexture.

2

I just saw the note above about running npm install. That may explain my results.

But… Is it not possible to run using correct script tags to import the correct babylon.js code in the index.html file, and then just put the createscene code in a simple .js file following the instructions in the documentation?

I just quickly read through the full documentation file below.

Is all this machinery necessary to develop Babylon applications? That could be a deal-breaker for people looking to Babylon as a straightforward way to program in webXR. If it is not ALL necessary, it needs to be clear how to develop “simple” applications; exactly where the line is between “simple” applications and those that need more; and exactly what more is needed, depending on the application. (One definition of “simple” might be a program that does not require any use of npm ; slightly “more” might require using npm without actually knowing npm, for example, by following a set of just a few completely explicit steps.)

3

I believe those are the instructions for the engine itself if you need to run a local fork or want to contribute.

For just utilizing Babylon, there is no difference between embedding the full script and using the npm modules except you are going to end up with better bundle sizes with the later due to tree shaking and all that.

If you are interested in the module way, this is a much simpler starter repo I saw posted here: GitHub - RaananW/babylonjs-webpack-es6: Babylon.js basic scene with typescript, webpack, es6 modules, editorconfig, eslint, hot loading and more. Will even make coffee if you ask nicely. though you might prefer one without typescript

I would say give it a whirl because more and more libraries are moving towards the module world

4

This doc is only to develop Babylon itself :slight_smile: not for using it. Would you have a playground with your VideoDome issue or a repro ?

5

https://www.qporitxr.com/2022-01-XR/62-01-01-ego/

A few days ago this played with the 3D EGO test files inside the mesh which now shows as a grey box.

I will try to restructure it to test/play in playground.

6

seems to still work in Chrome

image
image1649×939 43 KB

7

I am working with VideoDome at the the moment too, and so I hope you do not mind, but I took the liberty of creating a playground that replicates your test.

I believe the issue is BJS version related. I believe @qporit expects the video to play on the mesh. Which it does seem to do when using 5.x. Screenshot:

screenshot_22-3-17_16-18

However, if you use the same PG and switch the version to 4.2, it no longer plays within the mesh and plays on the background.

8

And looking in to it more, seems the custom mesh parameter wasn’t implemented until in the 5.0.0-alpha releases.

So, I believe is as expected if you are using v4.2.

2 Likes
9

Answer: In the index.html file I had an inconsistent set of statements. (some used cdn code, others preview code).

A new version of the code broke some things and trying to fix that broke some other things.

I downloaded a working sample.zip from PLAYGROUND to extract the index.HTML code and that fixed everything.

DOCUMENTATION FEATURE REQUEST: For those of us – including the people for whom I am writing this program – that would like to use BABYLON without going into github or packages or builds or extracting code from PLAYGROUND downloads, I would like to request simple conversational documentation that tells exactly what is needed in the index file to support any particular feature of BABYLON. For example, the documentation for using mesh with VideoDome would say that you need a gui preview for v 5 ; and version 4 does not work. Something that requires a particular version of a physics package would then say what is needed in the index file. Note that for backward compatibility, (or “current” compatibility for that matter) having the index file correct is as important as having .js files correct.

10

So a simple thing is all the version NEEDS to be the same :slight_smile:

Basically if you use 4.2 of core you need 4.2 of GUI and so on. A feature introduced after 4.2 will only be available in 5+ but something great would be to be able to flag code with the version it comes from not sure how but this could help at least ensure where it starts to be available.