omg thanks! I hate that lol
Thanks for your great help!
3 Likes
Wow, what a thread. Makes me wonder if we need a whole forum section just for this 
I was pinged a few times here, so consolidating my answers
- Audio engine is coming!! The audio engine was built as an independent, tree-shakable, side-effects-free module so it can, technically, be ported as is. although I am planning to make a few adjustments.
- WebXR! That’s an interesting topic. No official WebGPU support or WebXR. I will still build and prepare for the specs update (will use the probably-stale webgpu specs available on github). I hope one day the browsers will updated it. If Babylon-lite will ever get a webgl flavor webxr will be ready as well.
- Version update in the code - great catch!! Will fix that very soon.
Gosh, I love Babylon lite
4 Likes
Lite specific section for upcoming questions would be nice, or some more visible tagging system!
Would be nice to also see what you guys are working on in bigger picture. For example I am very dependant on the null engine (for server side) and input system/device source manager, and will only start porting my game after those two are integrated! So it would be beneficial for me to see if those features are being actively developed or if I have to wait months for them!
Of course I am waiting for things like audio and particles as well, but I can live without them for a while. 
1 Like
Had to comment on that. I have yet to see you once with a Beer. can’t wait to share one with you 
1 Like
Babylon Lite 1.3.0 preserves glTF node names on public transform nodes, but generated renderable meshes are named gltf_mesh_0, gltf_mesh_1, and so on. The original glTF mesh.name is not retained on the public mesh object, so we cannot recover it through official APIs. A named parent transform may still provide the model’s original node-level label.
Is it possible to retain the original glTF mesh.name or it is intentional?
on it!!!
@cx20 I think I fixed all but I will wait for the cx20 badge of approval 
I believe KHR_animation_pointer is mostly working now.
There are a few points of concern:
- Animations play faster than expected on high-refresh-rate displays (240Hz).
- The animation in MorphStressTest behaves differently than intended.
- Some animations for the AnimateAllTheThings model are not supported.
(https://cx20.github.io/gltf-test/tutorialModels/AnimateAllTheThings/glTF/AnimateAllTheThings.gltf)
It will definitely be difficult to test my RO2 scenes on lite since there’s no node builder and that’s how I’m mapping unreal2k4 materials to babylon. I’ll have to precompile things and then also do some weird things to get BATs animations working (i’m having trouble getting BATs to behave even on 8.X). I hit frame and memory limit issues converting from skeletal to BATs animations, so I’m doing something wrong while trying to share the animation textures. BATs is the ONLY way I’ll be able to support more than 5 players with a character model that has 100+ bones, and 300+ animation sequences. Initial testing says I can have 30 players in full resolution playing random animations and still have 30~60 FPS depending on how many animation loops restart within the same few micro seconds (I cheat this also by fluctuating the animation duration to minimize the overlap chance). Anyway… Maybe Lite can prove to be enough of a frame uplift to motivate me to finish my web RTC client with C++ server. The frame work is there and works… but until the frames are reasonable, it’s just a dream.
Hopefully I can have some time away from my other projects to work on this more. I want to experiment!
nme is supported in lite. you can build in nme and use the json in lite.
1 Like
can you point me out which one is not animated in https://cx20.github.io/gltf-test/tutorialModels/AnimateAllTheThings/glTF/AnimateAllTheThings.gltf ?
In my test it behaves exactly like bjs
1 Like
For the 240hz problem, were you looking at the lab scenes? because for testing purpose they are using discrete time per frame with scene.fixedDeltaMs=16.
In a real world case animation should adapt to screen refresh rate
1 Like
for morphstresstest, it was actually something @PatrickRyan reported too (a hard limit to 4 morph).
Fixed here: feat: morph targets via storage buffers + StandardMaterial morph support by deltakosh · Pull Request #278 · BabylonJS/Babylon-Lite · GitHub
1 Like
So could this be the incarnation of “BabylonX” ? I remember a while ago there was an open discussion on making the next gen of BabylonJS but had no goal of being backwards compatible and people suggested it could be Babylon X for the 10th version.
Either way I love it!
2 Likes
What concerned me was the spotlight animation.
The following shows the execution results from the Babylon.js Sandbox.
In this version, the spotlight is animated, but it appeared not to be animated in Babylon Lite.
I now understand that the code is intentional.
I confirmed that by commenting out the setting, the animation runs at the same speed even in environments with different frame rates.
//scene.fixedDeltaMs
1 Like
oh ok great! I think I did not yet added light animation so this is why. PR is coming
1 Like
Please check out this other announcement thread! Babylon Lite Compat - Announcements - Babylon.js
1 Like
I discovered other glTF models that fail the tests.
I believe it is best to ensure they pass the tests in order to improve robustness.