particleSystem.particleTexture

Questions
1

Hello everybody,

It took me the last 4h to address a little bug, which might be just a misundesrtanding of myself :slight_smile:

My last thing is to set on fire any card combo: works pretty well, but it worked only once… so I finally realized the issue was about using the same texture (preloaded with the assetManager) for every new fire effects and not a different one…

Not sure if this is a bug or a feature, huhu, but here is the playground I used during my track: https://www.babylonjs-playground.com/#WBQ8EM#125

image
image.jpg913Ă—525 207 KB

2

Sorry but what is the question? :smiley:

3

Huhu, no question, and my assumption is wrong :slight_smile: but I guess I am asking if I found a bug :wink:

in the pg I just saw I can add mutliple particleSystem with the same particleTexture (multiple clicks on create), but, as soon as I remove the emitter (the fountain, by clicking on the second button), then I cannot use anymore the same particle…

hum, well, let say that in the PG, I expected to be able to click on create - remove - create and to have the fountain working a second time, which is not possible if I don’t recreate a new particle… not sure that makes sense… starts to be late :stuck_out_tongue:

4

Hi Fenryll

Um… particleSystems can be created and started without an .emitter (or with .emitter = null)… IF it also has .emitRate=0.

https://www.babylonjs-playground.com/#WBQ8EM#130

In this PG, fountain is gone, but 5 cards were made. In lines 44-94, I do that particleSystem with .emitter = null and .emitRate = 0… and I start() it. It does nothing, of course.

Look at lines 110-112. All we do if top button is pressed… is set an .emitRate = 1500. Easy, huh?

Look at lines 125-127. If bottom button is pressed… set an .emitRate = 0.

Now, for the fancy part. FIVE emitters… operating all at the same time… on a single particleSystem.

Line 129 starts it, and is where YOU will put the cards that YOU want to be on-fire.

Line 131… puts some code on the renderLoop… a switch/case statement that simply keeps changing WHICH card… is doing the emitting. Pretty nice, huh?

Lines 54-55… are kind of important. Each card is 7 units tall and 5 units wide. Let’s bring it into the post, here…

    particleSystem.minEmitBox = new BABYLON.Vector3(-2.5, 3, 0);
    particleSystem.maxEmitBox = new BABYLON.Vector3(2.5, 3.5, 0);

These lines tell us WHERE (in localSpace for each card)… the particles will be emitted-from. Since you showed us cool pictures, I knew that you wanted flames coming from the tops of the cards.

Can you see that our “emitBox” (emit area) is from -2.5X (left edge of card)… to +2.5X (right edge of card). You also might notice that the bottom of the emit-area… is 3Y units above card center, and top edge is 3.5Y above card center.

To be brief and blunt, the particleSystem’s “emit box” is the top-most 1/14th of the card. (The top .5 unit area of the card). We could have done something similar with the original fountain box. Using min/max emit box… we could have set the particles to only emit from one corner area of the box. Emitbox generally means… WHERE upon the emitter… should the particles be emitted-from.

Lines 80/81 were also adjusted. There is a “1” in both Y values, so that means I want the particles to MOSTLY shoot “upward”… but the -.1 and +.1 in the X values… means the spray gets slightly wider in X-width… as they travel thru space. Since this is a “flat” scene, I set both Z values = 0, so the particles have no “spread” on the Z axis. Look at the cards particle spraying from the side… you will see that the particles spray “flat”, z-depth-wise. Hard to explain, easy to experiment-with. Those vector3’s are called “direction vectors”… not at all like the “position vectors” we used on the emitBox values.

Ok, let’s let all that soak-in, and wait for questions from you, if you have some. I bet you didn’t expect that a single particle system could have 5 emitters, did you? The first time I saw it done… I was pretty amazed, myself.

And we’re ONLY using a 1500 emitRate in line 111. Crank that to 5000, and they REALLY REALLY spray from all 5 cards. Too fun. BJS particles are high-performance, for sure. Now for some flame colors, and you’re ON FIRE! :slight_smile:

Remember those -2.5 and +2.5 values in lines 54/55? You are allowed to make them -3.5 and +3.5 or any other values… for a spraying emit-area that is wider than the card. In other words… emitBox numbers don’t HAVE-TO fit onto the card. The emitbox could be -20 and +20 X values… 8 times wider than the width of the card. No problems.

But if I were you, I wouldn’t go wider than -3.5 and +3.5 … 2 units wider than the card. That will fill-in the gaps between the cards. Setting those -.1 and +.1 values in lines 80/81… to -.3 and +.3… would also fill-in the gaps between cards… by letting the particleSystem spray-volume… spread wider during flight.

Ok, I hope I have been helpful. Start the particleSystem in a 0 emitRate “mode” (sort of idling)… and then get out the pliers, and start twisting its knobs. TOO FUN!

1 Like
5

wooow, amazing!

… and okay, took my a while to understand the switch in the rendering loop, lol, so you are “just” moving the system in a … loop … around all cards, at each rendered step, right ?

I was about to argue that, as you can see on the screenshot, I need different particleSystems as, since fire goes up, I setup specific directions based on the card rotation to always point it up, but, I just realized that I can change directions too in the rendering loop, so it is super cool https://www.babylonjs-playground.com/#WBQ8EM#132

I still have some math problem, but the idea is there :wink:

Last question (for now): is it a good practice to charge the rendering loop ? Writing the question I think I have the answer, it is anyway the loop used behind any animations of the engine, right ?

So, I would just put a first test “is something burning ?” then would put the switch inside, right ?

6

Not “all cards” each render step, but a DIFFERENT card each render step. It happens so fast… we don’t see it switching card emitters. It changes to a different card… approx every 1/12th of a second.

Careful here. :slight_smile: Fire should go “up” from card? Or “up” from scene/table? IF “up from table”… we will need to use negative gravity… or custom directions like you did. We will also need a card.isHeld or card.isOnTable or similar… so we can test things. Cards laying flat on table… with NO particleSystem negative gravity… will need more -Z direction value… BUT NOT when card is held. Only when it is on-table. -Z direction for HELD card… would make particles spray toward camera… looking weird. :slight_smile:

direction1/2 are direction from card… and not direction from ground/world. ParticleSystem.gravity = new BABYLON.Vector3(0, 15, 0); … would make particles go “up from world”. If you activate that, you might wish to reduce the min/max emitPower… so the particles are not “thrusted” from the top of the card. They would then “float” towards scene gravitational pull… more.

Just to prove stuff… I added more toys. :slight_smile:

There, no gravity set in line 99, and I disabled your direction-adjusters… at line 154… and I activated demo card spinner at line 153.

Notice that no-matter HOW the card is rotated, the particles always spray from top of card… because direction1 and direction2 are “directions from the card” and not “direction from the ground/table”.

Let’s lay some of the cards (sort of-) flat on the table, and THEN spin them…

Again, no matter how the card is rotated, particles spray from top-edge of card… no gravity affect. Activate negative gravity (now at line 105)… and the particles will try to float upward from the table.

Keep experimenting… you are becoming a particle system PRO… very quickly. I don’t think you will need to change direction1/2 values when the cards get rotated. If the card dealer… ever deals/displays the cards… upside-down, THEN you might need some custom directions… AND you will need to move the emitBox to the OTHER end of the card. :slight_smile:

If you need to have flames go UP FROM TABLE… I would use negative gravity… like line 105 of PG #135. Easy. You CAN use custom directions to make flame move up-from-table (and then turn-off negative gravity), but it is some work - needing to test if card is held-upright, or laying flat on table. A bit difficult… but CAN be done. Likely, each card would need a .isFlat or .isHeld boolean flag. And I am assuming that a face-down-on-table card… NEVER is burning, right? They must be face-up, to burn, right? Anyway, that’s all too much work for us, at this time. :slight_smile:

I know, I know, you are getting particleSystem brain overload, right? :slight_smile: Lots of knobs to turn, eh? nod. Your “custom direction per card rotation” IS a good idea, and you coded it nicely, but I don’t think you will need it. Instead, reduce the min/max emitPower, and increase negative gravity… maybe to (0, 50, 0). Might work. :slight_smile: Increase emitRate to 3000, set color1/2/about-to-die to fire colors, adjust min/max sizes and min/max lifetime… and stuff might act like you wish. FUN! :slight_smile:

PS: IF you are a truly demented mad-scientist as you SEEM to be… change particleTexture from flames.jpg… to smoke.jpg in that switch/case area. Switch it every time a card is selected to be the emitter. IF it was smoke, make it fire. else, make it smoke. It MIGHT fail/suck, though. :slight_smile:

LESSER mad scientists would activate two identical particleSystems… one for the smoke particles, one for the fire. We’re more demented than that, right? A third particle system for occasional fast-flying sparks, you say? heh. WOW! :slight_smile: FUN!

If I were you, I would NOT try to live-adjust emitPower and min/max lifetime… to cause occasional fast-flying long-flying sparks. BECAUSE the sparks would have a faster fly-speed and be far less frequent than the other particles (emitRate = .5 or something)… then I would use a different particleSystem for the sparks… IF you ever decide to add them. Gas flame? No sparks needed. :slight_smile:

2 Likes
7

“negative gravity” yeah, what else :wink:

That is so helpful, cool and nice of you, big thanks!

I planned to use fire to show the combo in the hand of the player but to stop the emission when the card is being played (kind of nice to see the last particles flying with the card), but now… there are other “special events” where I could use what you demoed here, gniahahAHAHA !

e.g. the total points of a round is 157 (long story short -> a match is the first team to reach 1500) and if you won all the 9 turns of a round, you have a special bonus of 100, so if a team won the first 8 turns and is playing the last one, there is some suspense… that last card the starting player will play to begin that critical turn could really benefit of some magical emissions… but, and that is for another thread I think, what I originally thought was a “Matrix effect”: the card is played normally but at maybe half of the trajectory to the table, super slow motion, with a quick 360 degrees turn of the camera centered on the card, and then back to original speed and camera angles and boum… yeah I have that feeling that babylon js (and its amazing community) is limitless :wink:

1 Like
8

Excellent! My pleasure. Your game is looking SWEEEET. REAL nice gfx/feel.

There’s one thing to keep in mind about standard (non-SPS) particles. ALL particles in a single particleSystem… are actually separated pieces of a single mesh. They are like a single highly-sub-divided plane/ground… that has been separated into many “quads” (squares/cells).

SO… when BJS does “depth-sorting”… it must decide if a mesh is IN-FRONT-OF or BEHIND other mesh in the scene. It treats ALL particles of a single particleSystem… as a single mesh. It HAS TO.

SO, in general, particles can be behind other mesh, or in-front-of other mesh, but not both ways (from a single particle system). With me? Having particles spray both in-front-of… and also behind… some other scene mesh… is trouble. So, particles have SOME limitations. The Solid Particle System (SPS) CAN have depth-sort… but it is a bit lower performance than a standard PS… but it still totally rocks.