• Content Count

  • Joined

  • Last visited

  • Days Won


jerome last won the day on September 9

jerome had the most liked content!

About jerome

  • Rank
    Advanced Member
  • Birthday 03/17/1970

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location
    France / Rodez

Recent Profile Visitors

5,579 profile views
  1. jerome

    Cylinder edit vertices on top

    As I said, you could do a curved path in the upper part and you could also add as many steps as you need on the lower part, not necessarily all aligned together, just make some tests to get the wanted shape this one reminds me something but I can't tell what :
  2. Mmmh really weird indeed. I just checked in the Github PR history : the latest changes in the Tube or Ribbon code (the tube is a ribbon-based shape) are at least one year old. Moreover the bug happens only on the tube update. So I guess this issue doesn't come from the tube geometry itself but rather from the vertex buffer update : how or when it's updated ? Can someone here remember about a recent change in the ribbon update ? I can see this about some _creationDataStorage that I don't really know : Not sure it's the reason though, but the rest of the existing looks still familiar to me
  3. Could you please create a PG ( ) to isolate the issue ? As far as I know, nothing has changed in the tube implementation : release/what's
  4. jerome

    Babylon.js v3.3 - Code freeze

    here's the current one :'s looking for the previous ones ...
  5. jerome

    Cylinder edit vertices on top

    quik and dirty : just change the tube internal path coordinates on the wanted steps. Said differently, don't make a straight path but a curved one in the upper part
  6. jerome

    Cylinder edit vertices on top just use a radiusFunction to set the radius according to the current tube step
  7. jerome

    Cylinder edit vertices on top

    no time for me now (later), but the answer is to create a tube with variable radius along its path
  8. jerome

    SPS experiments

    let's also recap what dimensions we are talking about : 20 K boxes, each having 24 vertices = 480K vertices + 20K tetrahedrons, each having 12 vertices = 240K vertices A total of 720 K vertices, knowing each has 3 floats (x,y,z) for the positions and 3 floats for the normals, so 4.320 millions floats just for the coordinates. Each particle stores a shape length, an integer, so 40K integers more. Each particle is set a transformation (a position, a rotation and a scaling) so 9 floats per particle, so 360 K floats. In total 4.680 millions floats and 40K integers as input data. From these input data, 4.320 millions floats, the transformed vertex positions and normals, are computed and stored in the same buffer... in 18 ms [EDIT] and meanwhile 40K quaternions and 40K rotation matrices, one per particle, are also computed !
  9. jerome

    Web Assembly

    For those who might be curios about I finally achieve the painful data exchange between JS and the WASM module, here's the explanation directly in the AssemblyScript Github repo : I wouldn't have succeeded without the AS contributors help. Thanks to them.
  10. jerome

    Web Assembly

    Sorry, the right link is In order to compare things with equity, I measured the elapsed time on the part ported to WASM only (because some of the time is elapsed in the user logic that remains in the JS loop anyway : how do the particles move ?). This part is the engine, what the SPS does for you under the hood whatever the logic you implement : Buffer SPS internal computations : 86-92 ms per frame Wasm SPS internal computations : 18 ms The isolated real gain of WASM is then a x5.44 speed increase. That's exactly what I expected from this port. Why ? because this is the expected average ratio between dynamically and statically typed languages in general (from x5 up to x20).
  11. jerome

    SPS experiments

    Let's go on now with the WASM SPS. First remember the former tests on a 40 K solid particle SPS and the perfs I get in my Chrome : Legacy SPS : (8 fps) Lighter Buffer SPS : (7 fps) Two worker SPS : (37-42 fps) and now the WASM SPS : (31 fps) This last version has done with AssemblyScript like explained here : It's the Buffer SPS version ported to AssemblyScript, then compiled in WASM. It brings a gain of 4.4 more speed You can get the AS source here : Please let me know how this behaves in your browser. Note that WASM is compatible with workers and that a double-worker-wasm SPS could be implemented... not sure I'll do it because it's quite complex. [EDIT] : a test with 20K particles runs at 60 fps here. So I guess that a two-worker implementation, each computing 20K in wasm, could also run at 60 fps for a total of 40K particles.
  12. jerome

    Web Assembly

    Hi guys, Here's my first real WASM test : Caution before clicking on the link : it's a very big SPS with 40K solid particles, this could freeze your browser. I'll report more precisely about this experiment here : About WASM itself : I generated the WASM bytecode from some code ported from TS to AS, AssemblyScript . If the logic is quite simple to port from TS to AS (because the syntax is almost the same, just add strong types like "f32", "u32" instead of "number"), the shared memory access (shared between the JS main program and the WASM module) is really complex and painful. Indeed, WASM knows only very basic numeric types only : i32, u32, f32, f64, etc and nothing about more complex structures like strings, arrays, objects. It's really low level and we have to deal with pointers and offset to pick/store the data at the byte level directly in the memory. Note also that there's no garbage collector. This means that creating any "object" (array, instance of a class, each time we type the word "new", etc) in our logic will require to manually free the dynamically allocated memory to prevent memory leaks. Moreover WASM doesn't provide any math library, so no trigonometry at all (sine, cosine, tan, everything required for 3D computations actually), so we have to implement by ourselves, say, the function sine. In brief, for a developer coming from a productive high level language, despite the help of the easy syntax of AS, it's a jump back in the past because the way to code it right looks more like some the C or the assembly way. Indeed, the first version of this code, very TS-like, very twice slower than this more low-leveled published version. You can get the AS source here : [EDITED] That's said, what about the gain ? Here are different versions and the FPS in my Chrome : Legacy SPS - 8 fps : Reference Buffer SPS - 7 fps : fun to see that now the legacy SPS what has been optimized is faster than the lighter buffered one WASM SPS - 31 fps : it's the port of the Buffer SPS in AS perfs gain = x 4.42 ... not that bad, finally
  13. jerome

    LinesMesh and createInstance

    Meanwhile you could use the LineSystem maybe
  14. Please read this doc : you need 2 paths of points to create a ribbon (it's better to use MeshBuilder.CreateRibbon() rather than Mesh.CreateRibbon() also)