• Content count

  • Joined

  • Last visited

  • Days Won


jerome last won the day on May 31

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,319 profile views
  1. Just change BABYLON.Mesh.ExtrudeEtc() by BABYLON.MeshBuilder.ExtrudeEtc() everywhere it appears ...
  2. jerome

    Cap Uvs?

    The tube cap texturing has a simple (poor) implementation. Maybe shoud you consider using a cylinder instead ?
  3. What did I do ? I just repeated the points in the list where the normals musn't be smoothed. Nice hack Pryme8 😄
  4. jerome

    Web Assembly

    Really nice feedback and interesting try. I have done some investigations about asm/wasm some time ago and I know this way of sharing data between JS and WASM (typedArrays / buffers). The approach you made, and I didn't mention, to build dedicated code in wasn is obviously one of the best : why only thinking about porting the 3D engine in wasm and not the user code (the logic) that may often be the slow part of the final software ? Please have a read about how they choose smartly to share the memory between JS and the compiled wasm module in AS : This could be inspiring to organize the data transfers to/from JS and the module.
  5. jerome

    Babylonjs consumes too much memory

    70 millions triangles !!!! Do you have at least 70 millions pixels in your screen ? It's not a joke ... but an advice : try to manage only what is visible in the screen.
  6. jerome

    Web Assembly

    The answer might come (before the end of year, I hope) from AssemblyScript : that allows to compile a subset of TypeScript directly to WebAssembly, aka WASM, or to Javascript. Check out this online tool : 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 😄
  7. jerome

    Fastest way to display fps

    I would suggest not to update the DOM element each frame : it's expensive. You could update it only, say, every 60 or 120 frames.
  8. continue() is a function from the Curve3 class what is not related to the Path3D class. If you want the same than continue() for Path3D, you could easily adapt it : then update the newly created Path3D object
  9. jerome

    Bezier Surface

    excellent tool 🙂
  10. Not sure to get exactly what you mean .... The Path3D is just a maths tool to design a 3D path and its triplets (tangent, normal, binormal) whatever the direction in the space. If a direction matters for you (say, the UP for every point), you could, for instance : - build your path3D - get all the tangents from its triplets - compute, with a simple cross product, for each point your own normals and binormals from each tangent
  11. I know the guys are working on that issue.
  12. it seems less visible with the backfaceculling : anyway, if you need at some cost a real facet depth sort :
  13. Q1 : I guess there's a misunderstanding about what is the bounding sphere of a mesh here, of any mesh (a sphere or a box, or anything). The bounding sphere is simply the sphere embedding the mesh bounding box ! In the particular case where the mesh itself is a sphere, well, it is contained in a bounding box greater than it, this bounding box being contained in its bounding sphere greater than the bounding box. That's why the bounding sphere radius is always greater than the contained spherical mesh radius. If you want a better explanation, please have a read at the part starting by "As you may know, a mesh -so a solid particle- is inside its bounding ..." here : In the case of spherical mesh the ratio between the bounding sphere radius and the contained sphere radius is sqrt(3)
  14. please tell us a bit more about what you're trying to achieve and where you notice the bottleneck ? Do you download thousands of different meshes ? Do you build, from BJS native constructors, the meshes ? Do you need to display all of them in the same time on the screen (not sure there are enough pixels on the screen to display thousands meshes anyway) ? Do your meshes share the same geometry, same material, same colors, etc ? There are tools in BJS to load scenes or meshes before starting a scene. There are also tools to clone meshes or merge them in a bigger geometry, there are tools (and user practices) to optimize the rendering process too by selecting only the meshes to be rendered... well there are many ways to improve things once we know what is to be done actually 😉