Leaderboard


Popular Content

Showing content with the highest reputation on 09/08/2018 in all areas

  1. 3 points
    Dad72

    Web Game Editor (MMORPG)

    Hello, I'm proud to talk about version 2 of my MMORPG editor (FR and ENG) that I renamed to "Web Game Editor" instead of "HeroonEngine" which was a name that looked too much like another existing editor. This version 2 comes with a new, more modern, community-based website. It will be possible to find a manual and video tutorials for getting started, as well as a shop and a forum (FR and ENG). The editor has undergone many improvements, new features and various fixes to make it more stable, more functional and more successful. Some things have been totally rewritten. It will come with a small Integer demo that contains two terrain and plenty of media on offer. I should hopefully release version 2 in the month and make an announcement of its release. For the moment I present it here. I have been working on this editor for years since BabylonJS was born. The editor has been renamed 4 times and rewritten 3 times totally and this name is the last change. Content and features: Here is some screenshot:
  2. 1 point
    BabarJulien

    Babylon performance Issue

    I've been doing some profiling while creating a pretty large number of objects in the scene, mainly LinesMeshes and some Planes with DynamicTextures to draw 2d Text. It seems that there are a few places where we perform O(n) search or iteration that causes creation time to grow linearly with the number of already existing objects. examples : - when adding a Mesh to the scene public getGeometryByID(id: string): Nullable<Geometry> { for (var index = 0; index < this.geometries.length; index++) { if (this.geometries[index].id === id) { return this.geometries[index]; } } return null; } => keeping up-to-date a map Id to Geometry could fix this. - when updating the world matrix for (var mesh of this.getScene().meshes) { if (!mesh.subMeshes) { continue; } for (var subMesh of mesh.subMeshes) { if (subMesh.getMaterial() !== this) { continue; } if (!subMesh._materialDefines) { continue; } func(subMesh._materialDefines); } } (first note : I'm not expert in Javascript VM JItter, but it might be worth storing this.getScene().meshes in a local variable to prevent a call to getScene at each iteration). If possible, adding the info in the Mesh whether all subMeshes have been already made dirty might prevent this code from browsing all the subMeshes several times Whe checking the callstack, I get into that code from TransformNode.computeWordMatrix which is called each time a mesh is created, and each time I manually call computeWorldMatrix in case the parenting did change (I want the world bounding box), and also each time I set DynamicTexture's hasAlpha to true (to draw 2D text). Also, I spend some time cloning LinesMesh since it does not support createInstance yet, it would be great to add this ! 😁 Please let me know if there are existing ways to prevent all those redundant computation to happen. For you info, I'm adding a lot of objects between two frames (I mean, between two calls to scene.render())
  3. 1 point
    JohnK

    Draw Calls

    This is one way http://www.babylonjs-playground.com/#4GBWI5#2
  4. 1 point
    Pave

    Destroy Sprite manually

    I am very new to phaser 3 but you can add all the sprites to a group and then loop through it and destroy the ones you want.
  5. 1 point
    samme

    Destroy Sprite manually

    GameObject#destroy GameObject#setName()
  6. 1 point
    jerome

    Web Assembly

    Quick feedback about some first tests : a big loop computing all the vertices (rotations, translations, scalings) of a modified SPS in a WASM module. For now, the results are quite ... disappointing : 1) even by using a cool language, AssemblyScript, to emit WASM bytecode at quite no porting cost from TS, the way to manage the exchanges between the JS code and the WASM module is painful. Not even speaking about the lack of a garbage collector WASM side what forces to give a particular attention to every object creation. 2) WASM, although being a bytecode usable in the browser (we could expect some features like other bytecode based languages like Java can provide) doesn't provide any math functions ! This means we have to implement by ourselves, say, all the trigonometry (sine, cosine, etc). How can we compute any 3D rotation without sine or cosine ? 3) the first global execution on the same basis than the SPS experiments is ... slower than the full stack legacy SPS ! I'll profile and tweak the WASM code soon in the hope to get something faster. But for now, it's not worth it at all... unless I'm missing something.
  7. 1 point
    Deltakosh

    How to join two walls as one?

    You can call Mesh.MergeMeshes (http://doc.babylonjs.com/how_to/how_to_merge_meshes) to merge two meshes but perhaps you could also have a look to CSG? (https://www.babylonjs-playground.com/#T6NP3F#0)
  8. 1 point
    Deltakosh

    Babylon performance Issue

    Hello Julien! These are good findings. You will feel our struggle regarding optimization soon Here for instance, if we want to optimize the getGeometryByID we need to sacrifice on memory footprint and then other users will complain that they are not using this function a lot so they do not want to pay the price you ask them to pay :). Here I will probably suggest that you override the function to make it closer to your needs directly For the getScene, this is the magic of TypeScript. Here is the code generated: Material.prototype._markAllSubMeshesAsDirty = function (func) { for (var _i = 0, _a = this.getScene().meshes; _i < _a.length; _i++) { var mesh = _a[_i]; if (!mesh.subMeshes) { continue; } for (var _b = 0, _c = mesh.subMeshes; _b < _c.length; _b++) { var subMesh = _c[_b]; if (subMesh.getMaterial() !== this) { continue; } if (!subMesh._materialDefines) { continue; } func(subMesh._materialDefines); } } }; You can see that the getScene is actually called once ComputeWorldMatrix is a complex beast. It is full of caching to make sure the cost is controlled but it needs to be called when you need it You can always call mesh.freezeWorldMatrix() to annihilate its cost Hope this helps!
  9. 1 point
    JCPalmer

    Babylon performance Issue

    I am not sure how much the getGeometryByID() change would help, because I do not even see getGeometryByID(), broken out in your profile data. I assume it is somewhere in Scene.pushGeometry(). Scene.pushGeometry(), along with the 2 functions broken out inside it, have a really high % of self time to total time. Does not leave a huge amount for getGeometryById(). The doubly nested loops are usually places which merit looking at. In another lifetime, I used a language with line level profiling, APL. Function level just kind of sucks. In this case though, the number of meshes which have multimaterials is small, so the inner loop is usually only called once. Something like this might be good from a es6 standpoint, but I have my doubts it will change performance a lot. const meshes = this.getScene().meshes; for (const mesh of meshes) { ... } In the case of LineMeshes, it is using a shaderMaterial, so that would have to be changed. Changing LinesMesh to use a StandardMaterial was talked about before. I was initially sub-classing LinesMesh for Hair, but I eventually gave up in favor of Mesh due to lack of thickness control. Do not remember what was said, but searching 'Hair LinesMesh' may be helpful.
  10. 1 point
    Do retro trains count too? 🚂
  11. 1 point
    JCPalmer

    Blender Babylon Question

    First, if you are running from file://, do not use chrome unless you set up a local server. Firefox & Edge allow from file, as long as it is the form of a relative path. 2nd, normally only the base file name ends up in the .BABYLON file. The path of source is just that. That is where .blender gets it from to copy. Sometimes if the file is embedded in the .blend file, there is no directory. You add it from the exporter custom properties on the scene tab.
  12. 1 point
    The Leftover

    Web Assembly

    The heartbreak of today was that the module I snipped this from runs faster in JavaScript. In other areas, I have reaped a 3x speedup with WebAssembly. I believe that issue is that there is substantial overhead in entering and exiting WebAssembly. You want the work it does while there to be large enough to make up the overhead and still give you a win. Gonna go soak my head . . .
  13. 1 point
    The Leftover

    Web Assembly

    Jerome, thanks. I usually do something like this. I create a module config object, and attach the memory there. This hands in whatever settings are needed and the memory. Now both JavaScript and WebAssembly can access the same typed array using 'hexlatticeMemoryView' and 'i32.load'/'i32.store'. I treat the WebAssembly module as a persistent "closure". Some of them have four or five function entry points. JAVASCRIPT JAVASCRIPT JAVASCRIPT JAVASCRIPT JAVASCRIPT hexlatticeImportObject = { settings : { weekbreaksLength : weekbreaks.length*4, weekbreaksStart : 16, monthBreaksLength : 0, monthBreaksStart : 16+weekbreaks.length }, imports : { log : console.log } }; hexlatticeMemory = new WebAssembly.Memory({initial:1}); hexlatticeMemoryView = new Uint32Array(hexlatticeMemory.buffer); hexlatticeImportObject.imports.mem = hexlatticeMemory; JAVASCRIPT JAVASCRIPT JAVASCRIPT JAVASCRIPT JAVASCRIPT WEBASSEMBLY WEBASSEMBLY WEBASSEMBLY WEBASSEMBLY WEBASSEMBLY (module (import "imports" "log" (func $log (param i32))) (memory (import "imports" "mem") 1) (global $weekbreaksstart (import "settings" "weekbreaksStart") i32) (global $weekbreakslength (import "settings" "weekbreaksLength") i32) WEBASSEMBLY WEBASSEMBLY WEBASSEMBLY WEBASSEMBLY WEBASSEMBLY
  14. 1 point
    The Leftover

    Web Assembly

    Gentlemen, thank you for the links. Let me some opinions base on three days of work. I started writing in straight WAT. Because I have a genetic defect that causes me to do things the hard way. However, it has caused me to learn a lot of things. WebAssembly is at the "MVP" stage as they call it. One can only create a module with functions below that - two levels. One can create a list of which functions may be exported. The MVP status shows: I couldn't figure out how to make a module-global variable that was mutable; so I did a work-around. One can share a typed array between JS and WA. In WA, it is called "memory" but there may only be one of them. I redesigned things a bit so all processing was applied against one array. This could put a crimp in my style. Is it possible the "C" converter bypasses these functionality bottlenecks? It seems a little unlikely; I think wat is the textual representation of wasm and they go hand-in-hand. They do appear to be beavering away at this much as we are here. The integration makes it *NOT* an all or nothing kind of thing. When the module is built, it can receive JS functions, notably console.log. So I can log things to the console. I could make other JS calls if I wanted. Exported functions are just a function. You can call it from JS. (If you print them it says "native code", which gave me a kick.) In light of this, I am pushing forward with creating limited functions for the three or four places where Illuminated City sits for more than a second. It requires some re-organization but I have the substantial advantage of being the only author. I can also write these functions in JS. That part is really neat; the array is one array and looks the same whether the manipulation was done by JS or WA. This will be helpful for testing.
  15. 1 point
    jerome

    Web Assembly

    The answer might come (before the end of year, I hope) from AssemblyScript : https://github.com/AssemblyScript/assemblyscript that allows to compile a subset of TypeScript directly to WebAssembly, aka WASM, or to Javascript. Check out this online tool : https://webassembly.studio/ Knowing that BJS is already coded in TypeScript, the effort to port some parts of the code to the AssemblyScript required subset would probably be worth a try instead of rewritting thousands of lines in C/C++ just in order to compile them to WASM. A subset of TypeScript is just some legal TS... this just means that AssemblyScript can't understand all TypeScript, but just a subpart of it because the compiling process imposes some explicit definitions. Example : whereas TS can understand the statement "var a = 10" or "var a:number = 10", AssemblyScript needs to know if the variable a is an integer, a float and what memory size to use : i16, i32, f32, f64 before compiling. The same thing we would have to do if the same part of code were ported to C actually. Well, if you already contribute to BJS in TS, or if you simply code in TS on your side, you don't really need to learn more to start to code with AssemblyScript in order to get your first working WASM. Never tried so far though 😄
  16. 1 point
    brianzinn

    Web Assembly

    Yes, you should be doing that!! And it's a good question. Especially now with essentially full compatibility. Check this issue for extra details: https://github.com/BabylonJS/Babylon.js/issues/3248 I think it's a matter of time really, but it's I think hard to split the work/communication from wasm and webGL and keep fast render. I don't think it's a question about performance - the math is going to be faster - it's getting it all working together. I haven't done any wasm experiments except playing with OpenJPEG. I need to find more time somewhere...