jerome

Members
  • Content count

    3,293
  • Joined

  • Last visited

  • Days Won

    72

jerome last won the day on September 12

jerome had the most liked content!

About jerome

Contact Methods

  • Website URL
    http://jerome.bousquie.fr/BJS/demos/

Profile Information

  • Gender
    Male
  • Location
    France / Rodez

Recent Profile Visitors

3,683 profile views
  1. setting material on sps causes webGL error

    If you have only 50 particles, you can keep the rotation computations enabled anyway, you won't even notice the difference compared to disabled rotations. That's just a speck of dust for the CPU. I thought you had something like 10K particles. At this level the optimizers really matter. But for 50 particles, the difference between computer/un-computed rotations would be only micro-seconds... nothing to be concerned about So my advice would be : keep the rotation computations enabled and enjoy all the SPS other features ! Note : for any standard mesh, its WorldMatrix (so all its transformations : position, scaling, rotation) is computed/cached anyway, even if it's not rotated, translated from a draw call to the other. As it's quite complex to guess what a user wants to do or has just done with all its objects in the scene, plenty of computations are done under the hood to be sure that's things are in the final right place, even when un-changed.
  2. setting material on sps causes webGL error

    Exactly And as we deal with thousands or dozens of thousands occurences, we need to make choices : multiply CPU cycles or (far) more memory allocation
  3. setting material on sps causes webGL error

    Ok, I got it about the reason. Actually, the transformations (translation, scaling, rotation but also billboard) are required to be done in certain order like for meshes : rotations come always before translations. That's why, storing in memory only the global last computed coordinates to pass to the GPU for performance reasons, we need to re-apply the rotation computation each time to get new final coordinates as the SPS doesn't store each particle vertex last state coordinates, but only the transformation (position, rotation, scaling) to apply to all of them. Not sure I'm clear... Ex : 1 SPS is 10K particles and is a big geometry : millions of coordinates to pass to the GPU (so one big final array) each particle stores its own set of transformations and a reference to its shared geometry model each particle is, say, 40 or 50 vertices, so hundreds of coordinates per particle stored successively in the final array each particle transformation computation updates in the big final array the part (so hundreds of floats) related to this current particle from its set of transformations As particles share the same geometry model and as the particle vertex last state coordinates isn't stored, there's no per particle baking possibility for now unless implementing some system that would multiply the memory consumption by far. Nevertheless, I will try to do a way to this ... In your case, as you have to call setParticles() to reapply the rotations, the right way is to call it only when necessary (not every frame maybe), maybe also to use the start and end indexes ( http://doc.babylonjs.com/overviews/solid_particle_system#start-and-end-indexes-for-setparticles ) to modify only the required particles.... and to tolerate the rotation computation when unavoidable ;-)
  4. setting material on sps causes webGL error

    https://www.babylonjs-playground.com/#N6PH8X#1 mmhh... the positionFunction doesn't seem to bake the initial status either. As everything was done by choices, I have to remember the reason why by checking the code back. All the rest I said in the former post is right anyway, about how the rotations are computed or not from the initial status.
  5. setting material on sps causes webGL error

    Ooops maybe I spoke too fast I need to check if it really bakes the transformation or not, just can't remember.
  6. setting material on sps causes webGL error

    This is the expected behavior actually. The SPS is designed to be able to manage a big number of solid particles, but everything is done CPU side. Including the rotation computations, what are the one the heaviest part of all the internal computations . So choices were done to give priority to some optimizations over some others : - only the particle initial status is stored (the status at build time) as a reference (imagine it's some mesh local space, in comparison) - only the translation and the scaling, among all the possible transformations, are applied anyway from this initial status when calling setParticles()... meaning that, if the rotation computation is disabled, the initial rotation (at build time) only is kept (it's zero, by default). This is the case you're encountering and this is done in purpose for users wanting faster animation without rotations. That said, if you need to give only one initial rotation to your particles, then pass some positionFunction as a parameter to addShape() before building the SPS. This position function will modify the initial geometry (so the initial status) of the particles added by this call. Thus, you could set them with your custom initial rotation. Any further call to setParticles(), even with computeRotation set to false, won't reset this initial status to zero. http://doc.babylonjs.com/overviews/solid_particle_system#create-an-immutable-sps As a comparison, the positionFunction would be a way to bake your own transformation in the mesh local space at construction time. In the contrary, if you need to update the particle rotations at least once after the SPS construction and if you need to re-apply this rotation on next calls of setParticles(), you musn't unfortunately set computeRotation to false then.
  7. setting material on sps causes webGL error

    Setting the UVs in the SPS just modifies the mesh UV initial values by shifting them for some percentage but it can invent these initial values. Your model needs UVs if you want to apply a texture anyway.
  8. Solid Particle system questions

    SolidParticle.prototype.direction1 = BABYLON.Vector3.Zero(); should do the job ... Then each newly created particle object is set with a Vector3 as direction1 property. If you implement an emiter (not existing with the SPS in purpose), you can then set each particle direction1 the way you want. To answer the first question : the velocity is a Vector3 designed to store the particle velocity, meaning its direction scaled by its speed. This can be used to move the particle this way : position.addInPlace( velocity ) as we can imagine that the user would want to animate the particles... but it can be used for any other usage if you want. The SPS has no default behavior by design. It can be used to animate particles or to build aggregated immobile objects also or to simply build a complex mesh and to access its subparts.
  9. Solid Particle system questions

    The SPS is behavior agnostic in purpose. So anyone can implement his own custom behavior and super set the particle object with any wanted property. Stop, Pause, Play() would just a way to call or not setParticles() in the render loop.
  10. Solid particle system SPS.dispose

    I don't have any error in FF nor Chrome here with your PG. Since the PG is served with https, all the embedded resources (images, etc) are now required to be also served with https, instead of http. I just changed the image URL to https in your PG : https://www.babylonjs-playground.com/#WCDZS#60
  11. setting material on sps causes webGL error

    Did you check that the imported mesh model has UVs ? The SPS copies the mesh model settings (geometry, uvs, colors, etc) when building its own geometry. If something lacks in the model, then it lacks in the SPS...
  12. SPS experiments

    So maybe it's worth the try to add the worker to the GPU version and check ... I'll do it next week if I can.
  13. Recalculate mesh shading

    I would sugget you to NOT create intermediate vector3 during the process by using TransformCoordinatesToRef() instead and by using a single temp Vector3 http://doc.babylonjs.com/classes/3.0/vector3#static-transformcoordinatesfromfloatstoref-x-y-z-transformation-result-rarr-void something like this : var positions = mesh.getVerticesData(BABYLON.VertexBuffer.PositionKind, false, true); var vertex = BABYLON.Vector3.Zero(); for (var i = 0; i < positions.length / 3; i++) { var idx = i * 3; BABYLON.Vector3.TransformCoordinatesFromFloatsToRef(positions[idx],positions[idx+1],positions[idx+2] , worldMatrix, vertex); positions[idx] = vertex.x; positions[idx+1] = vertex.y; positions[idx+2] = vertex.z; }
  14. SPS experiments

    thanks for the feedback... I'm no shader expert, it's my first one ever. The message seems to tell us that Edge doesn't like my float array declaration : float[11] rotMatrix not sure... I'll ask to the shader gods. In order to better understand the comparisons between all these versions, the GPU one ( http://jerome.bousquie.fr/BJS/test/SPSGpu/spsShader.html ) is actually exactly the same than the monothreaded typed array based one ( http://jerome.bousquie.fr/BJS/test/spsBuffer.html ), except that the transformations are computed GPU side instead of CPU side. This means that, without any worker, the gain is really important. Compared to the worker versions, on my not-that-strong laptop, the GPU version is a bit faster than the worker version. Should I add workers now to the GPU version ? not sure actually, because all the heaviest computation part is deported to the GPU and the CPU only does now simple array element assignements. Splitting the array among different workers won't bring anything more because the memory shared between these workers can't be also shared with the GPU, meaning that we have to loop over the whole worker shared array, once updated, to copy it into the GPU buffer anyway.. so the same loop size in final, once more, to fill the vertex buffer.