• Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by jerome

  1. jerome

    New forum

    Waaaooowww thank you so much @rich I just thought it wasn't simply possible to get the DB dump and I didn't dare to disturb you for this... there are so many users in this forum, I imagine that you can't answer everything.
  2. jerome

    New forum

    That's very kind of you. But I think we have to think about a way to download everything. Fortunately (and because we decided early to migrate) there"s no hurry for now, we can think, study, test some ways to get the archive. We don't have access to the DB, it's a fact. But it's not a new one, it's something that we've ever been facing to. We were depending on another community's tool and on a service that doesn't allow to get the data back. It's a long time known issue. We can, from now, start to think how to get everything back whatever the way. No need for hurry.
  3. jerome

    New forum

    I agree : the current backup is really a problem we should take care of
  4. jerome

    New forum

    I personaly would prefer to remain. But I already know that the Phaser community's decision will force us to move in some near future. So it's probably better to take in hands our own future from now.
  5. jerome

    New forum

    I agree : whatever the mean, it would be more than great to dump, download or save all the existing stuff... because it's quite sure this will disapear for some reason once noone will post, animate or answer any longer I also have tons of explanations that I would like to save.
  6. jerome

    New forum

    Please read this : and this : Rich is the owner of the current forum hosting, the BJS forum is simply a share in this hosting. The Phaser community will leave to Disclosure within weeks or months and the current Phaser forum will slowly terms of community activity. It will still exist for archive/history reasons. Then Rich will have no more reason to maintain, animate (nor pay) for HGdev hosting, no more reason than archive/history necessity. I know we all love our current forum. It's not just a tool. The forum is our community cement ! it's our bar, pub, club house, what you prefer... it's the place where we love to talk about BJS, to make jokes, to show nice demos and to help others. It's a meeting place and a small part of humanity in this vast virtual space that Internet is. We all are conservative, we all love our logos, emoticones, pages, links, buttons, tiny red notifications, etc. Well, our habits. Because they help us to feel confortable. Hell, it's our home, here ! But the reality is that this home will certainly disappear due to the Phaser community choices. We were depending on them since the begining and fortunately they accepted to invite us and to host us when BJS was just a tiny thing with no fame. So, many thanks to them. Maybe it's time now that we grew up to fly with our own wings and to leave this crumbling house to get a better one.
  7. In this old demo, the particles are emited according to some theshold on some bass frequency in my memory :
  8. You did this in only 3 days ???? That's AMAZING !!!
  9. it's not black ... just added another point light at the cam position : same double-sided as suggested by Wingy :
  10. you can also set simply the particles invisible : particle.isVisible = false
  11. sps.mesh.scaling = someVector3 is the right way to go in your example, it seems also that mouseWheelDeterminant is always undefined
  12. I don't think so because it's just some JS that is generated finally. This will rather impact the RAM consumption. But ... as people can manage dozen thousands particles in their SPS, I wouldn't add a default property that could never be used because people don't need it. I'm not a TypeScript expert, but I think there must be a way to re-open a class in order to add a property as JS allows it with prototypes (never forget that the final code is simply JS. Maybe some TS experts here could answer better than me. Anyway, the notation with should still work, because TS is still JS. If you can't modify the SolidParticle class and you don't want to manage a side array, maybe you could create your own objects (LogicalSolidParticles ?) either by extending the SolidParticle class, either by embedding the reference to the SolidParticle instance (the SPS will treat only SolidParticles, not other objects) in your own object type holding its dedicated properties. Then you could process your logic on the LogicalSolidParticles and just set the linked SolidParticles according to what they are supposed to do. It's a bit the same approach than the side array one, but you manage a pool of logical objects, each refering its related SolidParticle instead. There are plenty ways of doing. It would nice anyway to have an elegant way to reopen a class directly in TS.
  13. excellent ! I like this geometry too
  14. actually your bottom cube is already white. You may want to make the character disapear from textute instead ? in this case, the texture needs to be dynamically updated. Probably it needs an alpha channel and then, this one be set with a time function. Not sure... maybe there's a simpler approach by changing the mix and the way it's mixed between the texture and the emissive color. I'm not expert in this domain. I think anyway the texture must be modified at a certain point.
  15. The SPS is designed to be agnostic about everything else : it doesn't know how the user wants to emit or not the particles, how they must move (physics or not), what they must depict or act for. This is a design choice in order to make it as versatile as possible. This choice, although it forces the user to make his own behavior implementation, has shown it was a good option until now to achieve this versatility. So, if you want to make particles behind walls invisible, you will have to implement this as the SPS doesn't know anything about its environment. "Behind walls" implies a point a view, it is to say a camera position. If the camera is fixed, the walls are fixed, maybe it's easy to know if a particle is visible or not only by knowing its position in the space and without having to compute anything. In this case, it's probably worth it to set them as invisible when behind walls. Else, if you have to check if a particle is in the camera frustum and if it's occulted or not by a wall, it will be probably far too much computation to do compared to the SPS computation dedicated to the hidden particles that wouldn't be set invisible. It's just a matter a choice depending on your very special case. The need for storing extra properties for particles is obvious (what letter it represents in your case). As you discovered it, it can be achieved by two different approaches : - as you did, you store this extra property values in some structure besides the SPS, say an array storing objects (logicalParticles ?) of your own and indexed, by example, by the particleIdx. Yo can then easily access from a particle to a collection of data related to your own logic and vice versa. - you could also extend the class SolidParticle (well, it's javascript) before creating your SPS and it will be compiled with the same performance then : SolidParticle.prototype.letter = ""; SolidParticle.prototype.myOwnFunction = function() { this.letter = doSomething(); }; then create your SPS as usual and your added particle properties will be available 🙂
  16. As we have absolutely no idea about what your code actually does, it's quite difficult to answer ...
  17. alive false means that the particle is frozen in its current state (visible or not) and no longer computed until reset to true. It can used to define particles within a pool that won't evolve for a while and that don't need to be computed then. isVisible false means the particle is set in a first pass (first call to setParticles() when just set to invisible) in the same location than the camera, is scaled to zero (so no more in the frustum, not mathematically intersectable within anything else although its logical settings can be set and are saved (position, rotation, scaling, uvs, etc), then is no longer computed in the next passes (meaning next calls to setParticles() ) to improve the perfs. Therefore isVisible = false has more effect than alive = false. isVisible = false is the right way to go to fake a particle disposing : no garbage collector activity, no un-necessary computation, etc. If you want to get a bit more speed, just exit updateParticles(), that is called anyway, immediatly for invisible particles : SPS.updateParticle = function(p) { if (!p.isVisible && someCondition ) { return; } // your active particle logic then here ... }; I added "someCondition" more because you need to keep a way to reset the particle to visible at some moment [EDIT] you could of course reset the particle to visible also outside the function updateParticle() : // somewhere in the code, nothing to do with SPS management var p = sps.particles[thatOne]; if (SomeOtherCondition) { p.isVisible = true; }
  18. Yep, when the particles rotate (even just once), the normals are internally rotated, so they can't be frozen in this case. You set the right optimizers in your case. Are you encountering some performance issues with less than 1000 boxes ? weird ... If yes, what can be done then would be to act on your logic part : - for instance, set only the particles needing to be updated in the current frame with setParticles(start, end) - if you manage more particles than the ones that are actually visible in the screen, then reduce the particle pool and recycle them. If recycling is too complex to implement, then set the not visible ones to invisible (invisible particles aren't processed to make the system faster, only their function updateParticles() is called ... just in case it would reset them to visible) - if not necessary, don't call at all setParticle() each frame etc this chaotic example runs at 60 fps on my laptop :
  19. from JohnK's PG, 750 animated letters in one draw call and one texture :