brianzinn

I have a playground to reproduce: https://www.pixiplayground.com/#/edit/c0vYlkl14DEuLv1969cOm What I want to do is take a photo by generating a texture from a sprite, but with these lines not commented out (it works without those lines, but not like a "mirror"): // uncomment these on line 74 and it works videoSprite.anchor.x = 1; videoSprite.scale.x = -1 I just get a blank screen texture. I have tried to revert scale/anchor before calling `app.renderer.generateTexture(videoSprite)` without success (maybe I can manually trigger a frame render?). If you are trying out the playground it will ask for video permissions - the video is just put into a texture and nothing further. Thanks.

You can also add onAnimationEnd param: scene.beginAnimation(vehicle, 0, length, false, 10, () => { heartFlight(vehicle, move_trajectory, index + 1); }); https://www.babylonjs-playground.com/#X0MDYG#2 If you added any points during the animation, they would get added to the end. You would need code to restart a completed animation or perhaps a queue push/pop as @bghgary suggests. I added some smoothing, so the speed is consistent on different length path segments. If you don't want a steady speed then you can look at slerp on total length or rebuilding animation when points are added (start at current pos) and using the built-in easing functions. cheers.

I've played around with the GamePad API for GearVR and Daydream controllers and after figuring out how to debug them the coding part was easy. The gamepad API you can check yourself what is being returned. Looks like your controller is not supported by gamepad API, based on what you are saying though. Do you get any devices returned at all when connected? Check out this post for how to debug Android devices (over USB or WiFi). Very useful for figuring out what is happening with gamepad

Look at the vertex position data to see why (ie: 852 is far from world center): console.log('pp:', mesh.getPivotPoint()) console.log(mesh.getVerticesData(BABYLON.VertexBuffer.PositionKind))

The !X is a "communication administratively prohibited" (I think ipv4) that Digital Ocean uses. Try 'tcptraceroute or traceroute -T'.

It's not because the camera is further from the player when you have more players? When you attach a sound to the mesh (ie: sound.attachToMesh(mesh)) then the sound comes from the location/distance of the mesh. I load quite a few sounds in my game attached to many meshes and have not found any issues. Any way you can reproduce as a PG otherwise?

I don't know how 3D text library looks in Unity, but you can use vectororize-text with PolygonMeshBuilder (note the webpage to demo is gone, but vectorize-text is still on github). edit: I didn't know about MeshWriter - would go with that for sure

From @mkaouri "If the iOS 11 showing the front camera, you've to make sure that faceMode constraint in artoolkit.min.js is set to 'environment' to use the back camera of your mobile."

hi @MarianG, I didn't really follow the AR.js - from my recollection it was relying on another engine renderer. If you are not specifically after AR.js, do the jsartookit examples no longer work https://github.com/mkaouri/jsartoolkit5? Also, BabylonJS 4.0 has AR via WebXR, if that meets your needs (it's very early market for browser support). I haven't been following close enough, but otherwise if you want a demo of that (like magic window) check here: https://github.com/BabylonJS/Babylon.js/issues/3899

try like this https://www.babylonjs-playground.com/#1AbIIF#10

The link from my first response was to the exact line that I thought does that (!mesh.isEnabled() ... continue;), from my understanding (https://github.com/BabylonJS/Babylon.js/blob/master/src/babylon.scene.ts#L4259) So, why does isVisible == false keep it in the rendering loop, while setEnabled(false) not? I would think the difference would be hardly noticeable. Is there somewhere else I should have referenced or a performance penalty I am not seeing? Thanks.

Have you tried dialing back some settings, like disabling webgl2 in engine options or engine.getCaps().highPrecisionShaderSupported = false; It may be possible that the BabylonJS engine needs to account for a bug in the the browser/driver as @bghgary has suggested. When I look at your first screenshot it looks like z-fighting with 2 planes - those misplaced triangles look like a face that does not belong. I've tried mesh merging and was happier with more fine grained control using meshes generated manually (from data files). I was originally inspired by some code from this project (/scripts/PlanetChunckMeshBuilder), which is efficient and produces minimum vertices (ie: skipping occluded faces) : http://svenfrankson.github.io/PlanetBuilderWeb/index.html

If you look in the inspector (ie: open PG click "inspector" button), then you can see the number of vertices/faces (ie: mesh.getTotalVertices()) - along with materials, these are in memory. To answer your question, though, I am not aware of a way to measure memory usage of a single mesh - I just go by poly count as a basic measurement. If you have materials with large textures would also have an impact. Clones vs instances will also reduce memory footprint, if you have multiple. If you need to "unhide" meshes quickly then disposing them is not a good option! You may find this useful, but they will remain in memory: https://doc.babylonjs.com/how_to/how_to_use_assetcontainer

This is what you are after: mesh2.setParent(null); That will unparent the mesh, while maintaining rotation and position in world co-ordinates (instead of local to the parent). If it doesn't work just post a PG. I've got lots of similar versions of it in my game If you have physics on your crane cargo this is where you would call .wakeUp(), too (ie: get crane cargo to fall). Cheers.

Yes. The "active" meshes are the ones that slow down your scene. Notice here where invisible (isVisible == false and visibility ==0) are not included: https://github.com/BabylonJS/Babylon.js/blob/master/src/babylon.scene.ts#L4259 If you dispose() a mesh instead of hiding it, then I would think it would give you a very marginal speed increase, but with the slow cost of re-importing. I would suggest to keep the meshes, if memory usage is not a concern. Best thing is to do a speed comparison, as empirical evidence (ie: FPS/engine.getDeltaTime()) does not always show what would seem intuitive.