• Content count

  • Joined

  • Last visited

  • Days Won


jerome last won the day on April 3

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

2,875 profile views
  1. I should have answered this one
  2. Earcut is a third party library that was integrated into BJS at the time Canvas2d was released, so it's (and should be) responsible for all the triangulation processes : It's soon the time I come back to some BJS dev, I think, as the list of requests for features and other fixes about what I provided so far gets longer and longer ;-)
  3. mmmh... currently the cap the computed from the model shape barycenter what is fast (especially when the mesh is dynamically morphed) but doesn't fit the needs for people just wanting a fixed mesh and more versatility in the cap management. This means I will have to implement something like a staticCap feature, a cap computed from a triangulation algo with some predictible positions, so uvs, if possible. For now, the capping algo can't do this unfortunately. The best choices are either to use the powerful shaderBuilder, either to design your own cap from a mesh appart, then to merge it to a un-capped extrusion
  4. lots of points/coordinates => some 3D visualization ? particles, SPS or ribbons
  5. Actually the old behavior tolerance was just a side-effect ... It MUST be passed a LH orthogonal system like it's written in the API doc.
  6. you're right @adam but it used to behave differently in 2.5 I'm showing here the default axes (nothing flipped) That's what I don't really get.
  7. I didn't follow this thread until now, but to answer your question : yes, the code of RotationFromAxis() changed in an improved way (I hope) release/what's it's weird that the behavior changes though Actually the former algo was more tolerant to not well designed 3 axis system (left handed) passed as a parameter (in other terms, it could compute something even with not a real LH orthogonal system and the result often looked like it were right) Does this one run a bit better ? I just shift the parameters or this one (+ addRotation) : Maybe did I do something wrong with the quaternion and matrices used in this new version .?I need to check this with @adam
  8. I should to the same, good idea
  9. Well, making a real PG has some benefits : this forces the user to reproduce the problem by isolating it from all the context of his whole application code. This forces the user to simplify things to make the issue visible and understandable to others... and, most of all, this often leads the user to discover that the issue wasn't where he initially thought but somewhere else in his code, because of its complexity or length (it appends to me all the time). So please try to reproduce the issue in a PG
  10. I'm afraid that without a PG example we won't be able to help ...
  11. For 1 to 2K, the SPS is your friend anyway :-D It's quite easy to make explosions with solid different particles rotating in every direction. Have a look please at those demos featured by the BJS web site :
  12. In theory the standard particle system is faster than the SPS. You should be able to start to notice a little difference for more than 12-15K particles emitted at once (more visible above 50K particles) That said, if you need : correctly sorted particles relatively to other transparent meshes or per particle color/texturing/scaling/pickability or particle intersection computation or solid particles... well, you have no other choice to use the SPS... The SPS is quite optimized and its performances will be really close from the standard particle system and you would probably notice no difference for thousands of particles.
  13. It's by design. Just change all your values to : val / 255
  14. it was mine ;-)