• Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by jerome

  1. About ComputeNormals(), I agree it's a good candidate. First note : usually, unless you're dealing with an updatable, then morphed, mesh, you don't need to recompute the normals each frame. But it's still a good candidate for a WASM computation, especially when the mesh needs to be morphed. The current implementation of ComputeNormals() has been optimized many times over its life (check old forum posts about this topic)... and I'm the culprit 😄 . Actually there are parts of the ComputeNormals() code that are conditional and used only for the feature FacetData, because they use the very same algo on the same data. So it's faster to compute the normals and the facetData in the same time than to do this big loop twice. But you can just ignore the facetData part if you want to focus on the normal computation only. About my first test with WASM, I did like you : I used only TypedArray. Actually one big TypedArray in to pass the data to the WASM module and a big TypedArray out to get the results back from the module. But, in order to focus only in my own logic, I also used the library wasm-ffi : This library handles for you all the TypedArray/ArrayBuffer exchanges between the AssemblyScript code and the WASM module. I should probably get rid of it and manage the data passing/sharing by hand to be sure it happens like I really want. At last, WASM and workers are compatible AFAIK because modules are objects that can be passed to a worker, then be instanciated in the worker itself. So, although it's probably hell in terms of data exchanges and memory sharing (main thread sync/to/from/ the workers, each exchanging with their own WASM module), it's also maybe (theorically) what could bring a huge performance gain.
  2. That said, don't trust me either. Why ? well, in '98, I tested Java for the first time and it was sooooo slow. I made a definitive opinion : this stuff isn't worth it and has probably no future. So please, don't trust me. By nature (statically typed, low level, bytcode, aot compilation), WASM is way faster than JS in theory. I've probably done plenty of conception/usage errors in my test, maybe also the AssemblyScript emiter isn't mature yet, and perhaps the browser compilers/runtime executer will get better and better (or the 3 reasons together). The theory seems to tell us this is the way to go to improve by far the performances. Now, it's just a question of time for the theory to get into practice.
  3. 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.
  4. Excellent !!! and what a huge work !
  5. not really as, when using a SPS in general, it needs to "build" a real 3 geometry CPU side contrary to some particle 2D system using either a direct screen space projection, either a dedicated GPU computation
  6. Ok, I understand. Whereas the sprite manager or the legacy particle system always render their elements (sprites or 2d particles) directly in the screen space in a certain manner, the SPS, even in billboard mode, still computes everything in the world space. So when using the billboard mode, the SPS needs to rotate each particle for you under the hood so they always face the camera ... and rotations are the heaviest computations in the process. That's why I often recommend to use the legacy particle system or the sprite manager when people need the billboard mode for planar particles only because they are more powerful when dealing with huge number (> 10K) of particles. That said, if you still want to use the SPS with billboard because of its extra features (per particle color, uvs, intersection, picking, particle depth sort for alpha blending, etc) and if you want to get higher performance, you could consider these leads, knowing that the heavy computation is done in setParticles() : - don't call setParticles() at all if your camera doesn't need to rotate (but only to zoom in/out, so no need for billboard there) and keep the planar particles : - if the camera needs to rotate, call setParticles() only on demand : - don't call setParticles() at all, don't use the billboard mode, and replace the planar particles by real 3D particles visible from everywhere (tetrahedrons or tiny low poly spheres) tetras : icospheres : boxes : 300K fixed boxes : BTW, I'm currently working on my poor free time on a wasm test about the SPS computation process to check if this could be really improved with wasm. This is really painful because WASM doesn't provide any math function like sine, cosine that are massively used in the rotation computations. So I have first to reimplement some sine and cosine before making the SPS test.
  7. reading quickly your code : - you don't need to update the facetData once they were computed if your mesh is not morphed in some way - I think you're trying to find the closest item facet near to the sphere position (so its center) and not from the sphere surface ... FacetData are a facet related feature : if you search for the closest item facet from the sphere center, you'll probably get nothing, hence the returned "null" As you can't know what part of the sphere could hit the item, you would check in theory is there's some closest item facet near to each sphere facet what you probably be too much computation. Maybe you could instead check only some part of the sphere surface to lower these computations and keep a good approximation (like there were some points or vertices on the sphere acting as collision sensors)
  8. just starting some little tests on my poor free time to evaluate the gain provided by wasm with AssemblyScript and wasm-ffi in order to focus only on the perfs and to not loose time to implement array passing nor to waste time on the C compilation toolchain : TS only and a library to manage out-of-the-box the data exchange between JS and WASM I'll let you know if something good raises from this
  9. \o/ for SAB ! That said, the usage of webworkers with SAB is not that simple about their synchronization. Please have a read at this last year experiment : As sebavan said about wasm, the best implementation would be that the major parts of the framework would be ported to wasm AND the user logic would also be coded in wasm to avoid the communication issues (data passing back and forth, multiple wasm calls from js, etc). Note that, they intend, some day, to implement the multi-threading wasm side and the question of the performance gain will then be capital. Meanwhile, maybe are there other ways to improve your very own case ? ... reducing the draw call number, reducing the globally the computation required (don't compute what's not visible, what's not pertinent, etc), reducing the number of loops, iterations, the amount of data ? well, just leads as we don't really know what you're trying to achieve 😄
  10. imho, Phaser is really dedicated to genuine 2D games on webGL. BabylonJS is dedicated to 3D and provides a 2D GUI and 2D tools (these tools being able to be injected in a 3D world what is huge) Phaser has a 2.5 D support what is actually a 2D layer with a z level approach whereas BabylonJS can display real 3D in a 2.5D mode (orthographic camera) Both are WebGL engine.
  11. no time for me either 😞 unfortunately ... still for while
  12. another approach would be to use the facetData partitioning that can work with any mesh if you like to tweak things
  13. getFacetNormal()
  14. Making a PG is always a good idea because it helps to isolate the issue (if any) in the code 😉
  15. that said, we could get the curve points with getPoints() then each bipoint is a little straight line, also a vector. It' might be easy to get each vector length and to set then your own wanted points at a given fixed interval.
  16. not with the current Bezier implementation
  17. When you use a ribbon, the UVs are computed by default to be stretched on it as if the ribbon were unwrapped. This is why they can differ from what you expect when you fold it to some specific geometry. That said, you can pass your own UVs as a flat array of Vector2 (each array element being the UVs of each ribbon vertex) with the optional parameter "uvs" :
  18. I agree : calling small wasm functions could be slower than using the same algo inside the JS process, because of the memory access and the entering/existing. I think that the gain and the power of wasm could be real when dealing with few calls of wasm functions treating large amounts of data at once (some kind of batch computations) : big loop with huge iteration numbers, big float arrays (meaning over 10K elements to treat), etc Example : CPU particles, culling (if it were batched : one process for all meshes at once), SPS, WM computations of instances (idem, if it were batched) Most of the BJS functions are already very fast and quite short, they won't probably get no gain at all to be translated to wasm as is.
  20. The frustum check against boundingSpheres only is obviously faster but also less accurate. Not sure, but I think that 3JS computes the culling only with the bounding spheres : Well, if you tune your BJS demo so it's the same as the 3JS one, you'll get same perfs 😉 Maybe we could add a parameter in BJS to let the final user to choose whether he wants to limit the culling tests to boundingSpheres only. This already exists in the solid particle intersections boundingSphereOnly : true