Jump to content

jerome

Members
  • Content Count

    3724
  • Joined

  • Last visited

  • Days Won

    88

Everything posted by jerome

  1. 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. 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. I agree : the current backup is really a problem we should take care of
  4. 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. 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. Please read this : http://www.html5gamedevs.com/forum/33-phaser-3/ and this : https://phaser.discourse.group/t/welcome-to-the-new-phaser-forum/15 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 die...in 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
  7. In this old demo, the particles are emited according to some theshold on some bass frequency in my memory : http://jerome.bousquie.fr/BJS/demos/spssound.html
  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 : https://playground.babylonjs.com/#HHV38I#3 same double-sided as suggested by Wingy : https://playground.babylonjs.com/#HHV38I#4
  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 https://www.babylonjs-playground.com/#ML2LR9#5
  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 SolidParticle.prototype.property should sti
  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
  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),
  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 t
  19. from JohnK's PG, 750 animated letters in one draw call and one texture : https://www.babylonjs-playground.com/#UIIK1W#3
  20. https://doc.babylonjs.com/how_to/how_to_use_facetdata
×
×
  • Create New...