particle project info

[al404]

I'm new to 3D and 3D in web browser

I'm looking into threes and babylonjs to see witch will better suit for my project

I need to make a cloud particle system based on an exported ( blander or other software ) mesh

I need to click with the mouse on a singolar particle and retrive an associated ID 

I need to move my make a little animation over the particle close nothing too fancy, just particles moving a little around the mesh

 

I stated with threes and disappointed me so far is that changed code and functions name, i guess multiple times, 2015 examples often display in console deprecated function or errors on older code

Not sure witch is better to lear since i may not develop something else for a while after this project

 

From what i read i'm not sure i can assign a name to a cloud particle with babylon, i guess click interaction is possible 

Is it possible to download and install playground on a local server?

Thanks

[GameMonetize]

Hello and welcome!

Among other rules we try to keep back compat between versions

For your specific question, we have the Solid Particle System. Here is an example where a mesh is used to generate particles: http://www.babylonjs-playground.com/#1VCUIJ#15

Documentation: http://doc.babylonjs.com/overviews/Solid_Particle_System

[al404]

i did try to download the linked example with different browser but it says "Creating archive...Please wait" but download doesn't start

i saw a JS error "index.js:343 Uncaught TypeError: Cannot read property '0' of undefined"

[jerome]

both links work here 

what doesn't work exactly for you ?

[Wingnut]

Hi guys!

  Deltakosh showed you a BIG scene... slow heavy loader (but it's very cool once/if loaded).  It makes my browser window close sometimes, but not the whole browser.  Just the window that IT is using.  Strange.  I think @jerome worked-on that url/scene, and webGL gets nervous when Jerome is nearby. 

@al404 - can I ask more about your goal?  How many particles?  Are these pickable particles/planes... used as a menu?   Used as selections/choices?

Do you want the particles/sprites to "orbit" around the mesh?  Will this be "solar system"-like? 

If too many particles are within the "cloud", then it is difficult to select.  Difficult to differentiate.  I think you can use little planes or sprites.  (Almost the same as particles, but a little different).  Our playground's Lights Demo uses some basic orbiting.  Change the spheres to planes, turn on billboard mode on the planes so they always face the camera... and you are pretty close to your goal.

In the playground, do some edits, hit run, edit more, hit run, and at any time... hit save.  The playground will give you a new URL after the save.  Bookmark it... come back to it later, edit, run, edit, run, save... bookmark the new URL again.  You cannot "hurt" anything in the playground.

After we learn more about your goal, we can find a demo that helps more.  Be well, welcome to the forum.

[jerome]

ah oki, this comes from the geavy scene maybe ?

so if you want pickable solid particles and if you take a look at this doc http://doc.babylonjs.com/overviews/Solid_Particle_System#pickable-particles , you could see that it's quite simple from this example http://www.babylonjs-playground.com/#2FPT1A#14

the particle is pickable, its id retrieveable and then the picked particle is animated... all what should fulfill your requirements if I didn't misunderstood

[al404]

thanks for your help the cube example is really close to what i want to do, i explain all i need and step i'm using to break down my goals

- particles hold be on the outside of the mesh

- i need to assign at each particle an i ID so i can retrive it when i click the particle

- i need to click the particle and retrive the ID previously associated

- i need to move particles around the mesh

i add a link of something that look close to what my 3D object should look like except that it should not have that mouse interaction i have click the particle and open an overlay

http://www.iamnop.com/particles/

try to select bear from dropdown

 

I'm just stating to test some code, i use a mac and coda app but i guess i don't have any way to use intellisense to get info about functions

I download visual studio code for mac but if i hover a function it doesn't seem to suggest anything

do you know how can i do on mac?

 

MY goal are:

- load my mesh, and i got it to work :-)

- create a particle cloud that covers my mesh, i'm working on it

- add an id to each single particle

- move the cloud

- click and open an overlay

 

Thanks!

 

[Wingnut]

Thanks, al404!  That's a nice effect.  I love the animal shapes. 

http://www.html5gamedevs.com/topic/18959-add-attractorsreppels-to-your-partciles-system/

In that thread, Jerome and Steve were playing with flocking/swarming.

No matter if you use the Solid Particle System (SPS) or the standard particleSystem, it's likely you will be coding a "custom update function".  Both particle systems are completely prepared for that.  Particle custom update functions are very easy to install (as you can see by the demos), but coding the function to make the particles act like you wish... could be challenging.  If you can do it, that would be wonderful! 

Babylon has everything you need.  If you do a Playground Search for 'updateFunction', you will get many examples of custom update functions for particles.  (such as this)    (lines 55-83)

I can't help with the intellisense/Mac stuff, sorry. And I also don't know if others have used the playground on foreign servers.  There might be copyright issues... not sure.  Hopefully, others will comment about these things.  Stay in touch.

 

[Wingnut]

@al404 - Hi again!  Are the other topics you have on the forum... all related to this topic? 

No problem, just curious.  I have been working on http://playground.babylonjs.com/#ZPIC4#0

In fact, I made a different version... one that uses a slightly more "sane" update func - http://playground.babylonjs.com/#ZPIC4#1

But, it's still not working correctly, so I grabbed the zip and took it home.  I will do a little more work on it, now.

You know... "the bear"... is no easy effect to achieve.  You are taking-on a "bear" of a task.    Did you play with the gravity setting on the datGUI panel?  With shape gravity at 10, the particles "hug" the shape of the bear... closely... tightly.  With low shape gravity, the bear shape gets "looser".

Now, I have seen your #ZPIC4#0 (and my version #ZPIC4#1) "work".  We can use an updateFunction to keep the particles AT their "assigned" vertex.  We can use a startPosition function to start them there, too.  But, the bear's particles keep "flowing" and are not hard-positioned at vertex points.  This might not be easy to accomplish. 

For the bear, in a way, each particle is "orbiting" its start point, with gravity involved.  But even THAT is not completely true.  We do not see "clustering" around vertex points on the bear.  We see the particles smoothly distributed across the surface of the bear's skin.  How the heck did they do that?  :/  It's pretty amazing.

I think, in one of your other threads, you talked about adding vertices to models.  Not sure why, but if you are seeking to "smooth-out" the particle distribution using that method, that might be a questionable approach.  The "startPosition" that we want for each particle... is an even-distribution across the skin of the mesh, no matter how high/low the resolution of the model, and no matter the size of the triangles that create the surface.

SO... my theory is...  using vertex points as particle start positions or as "gravity-well points" for updateFunction->particlePosition... is the wrong approach.  I think, IF you use vertex points as your start/update reference points, your point cloud particles will try to "cluster" around vertex points on the model... and the particle skin wont be even and consistent across the surface.  Instead, it will look like you have a particle emitter at every vertex... and there will be less particles at positions not-near vertices.

SO... (again)...  MAYBE... you could... hmm... unwrap the model's texture, place your own uv2's evenly spaced across its surface, wrap it back onto the model, and use those uv2 locations as the start/update positions for the particle system.  (What did he say?  Wingnut is talking crap, again)    Generally speaking, YOU cover the skin of the skull model with your own array of locations (uv2?).  Then use THOSE as your particle start/update/gravity points, and NOT model vertices.  By making your own "skin net".... YOU get to control the granularity of your particle spread... the distance between each start point (YOU control the thickness of the peanut butter you spread on your bread). 

If there is a big triangle on part of a mesh, now that is no problem for you.  The area between the 3 vertices of the big triangle... will have many uv2 points across it... so no cloud-gaps in the middle of big triangles.  With me?  You no longer use vertex positions.  You made your own array of "places on the surface" and you can use those, instead.

Can it be done?  Phew... I don't know.  I have no idea what uv2's are used-for.  The added size of your model... caused by adding a uv2 array to it... is dependent upon how tight/loose you distribute the points (grain/resolution).  If you cover a bear's skin with dots every 1 inch, how many dots?  Maybe 1000?    *shrug*

I have NO idea if I am speaking wisely or not.  (Probably not).  The tech-level needed for this challenge... is not within reach of me AT ALL. 

How did they do that?  heh.

[al404]

@Wingnut Hi thanks for the reply, yes they are all related.

I open different topics because i thought it may be easy for some one to search and find the solution to a similar problem.

 

The bear is an example that can be confusing because it has many effect in it but if i can put togheter on the same mesh 2 particle systems il will be OK

i don't want them to follow the mouse or other physics things

 

I'm end up thinking that i can just put together 2 clouds of the same mesh one like this example ( flare is the wrong one, the correct one has alpha ):

http://playground.babylonjs.com/#21XXDF%230

and other is the one that you was looking

http://playground.babylonjs.com/#ZPIC4%230

 

the idea is that the 1sth mesh has the clickable particles, since it slows down my FPS increasing the number of particles i would add over a 2nd particle system that is lighter and give a more "fancy" look 

sorry to confuse you with the bear but if i can just get new particles on same wetter as i do on load it would be more the enough

if open your link i don't see the particle system but only the mesh

[Wingnut]

Yeah, my old link is still broken.  Struggling with min/max life for manualEmitCount.

This version is starting to work...

http://playground.babylonjs.com/#ZPIC4#2

myUpdateFunction is a little more basic than yours.  Still testing things.

I am glad you are not trying to do "the bear" demo for yourself.  That looks HARD!    Scared me.  heh

[al404]

i just try to change 3 value

line 76: number of total particles to 5000

line 81: manualEmitCount 1000

line 4: maxLifeTime 4

and it disappear 

it seems that once first set of particles reach the end of their life cycle dies

http://playground.babylonjs.com/#ZPIC4#3

I also link my starting point where it has a low maxLifeTime  = 4 but it seems endless

http://playground.babylonjs.com/#ZVNDN%233

 

[Wingnut]

  Things like fountain emitter and startPosition... I just ignored/removed.  When using manualEmitCount instead of emitRate... we just spray all the particles into the scene RIGHT NOW.  And the very next frame, we align all those particles to the model vertices.  So, we don't care where the particles start from/at.  We take full control in the 2nd frame, (in the updateFunction)... so... users won't even SEE where the particles start.  Too fast for their eyes.

And age/life min/max... I/we don't care about that very much, either.  I send 10000 particles "out there" and I prefer that they NEVER die.  See the age-checker in myUpdateFunction lines 197-203 (those lines are from the default BJS updateFunction).  We could remove that age checker from OUR myUpdateFunction, because we don't care about particle age.  Let them be 10 million frames old... no problems.  We don't want any of them to die of old age. 

Let's see what else happens in a particleSystem updateFunction.  Lines 205 - 208 in our playground... handle the colors.  Removing those lines and adding our own colorizer.... might be fun...  http://playground.babylonjs.com/#ZPIC4#4

Oh my, what a mess.

What else gets updated in an update function?  particle.angle (spin around z axis - we can ignore/disable), particle.direction (flight trajectory - we can ignore/disable)... and particle.position (super-important to this project).  Playing with particle update functions is FUN, and Deltakosh has his world famous particle effects running, too... so it even gets MORE fun.  If wanted, you can remove the 'effect' parameter from particleSystem constructor, and that will turn off DK's effect.  But he has some debris in the render loop, too.  That debris is a direction reverser.... because the effect got really violent without it.  Folks were reporting broken glass on their monitors... from too much effect. Just kidding, of course.  But it IS true that the reverse was installed to keep the effect from getting too "wild".    Particles are so much fun.

[Wingnut]

Yes, with manualEmitCount, no more particles are emitted AFTER they die.  So I prefer that they not die.    But it's okay if you want them to die, sometimes.   Yes, there's some problems with min/max life.   Same problems I had before.  Max life needs to stay big.

If you set particleSystem.manualEmitCount = meshmodVertices.length;   then you know you have one particle per vertex.

Don't let any of them die. 

I am still testing, still learning.  Particles take practice.  But min/max lifeTime... they are trouble. 

If you want to use min/max life, maybe you should turn OFF .manualEMitCount (remove that line)... and re-activate .emitRate.  If particles are going to die, you must replace them.  But you can also REPEATEDLY keep setting manualEmitCount... over and over... in the renderLoop or with a setInterval timer.  Lots of options.

By the way, I don't know what the goal is, so I am probably doing wrong things.  But, I'm having fun.  How about you?  Are we moving toward the goal, at all?  I hope so.

[Wingnut]

Hi gang.  We are here, the forum is slow, the topic is paused... so I will present a challenge!  Yay!

For some time, I have dreamed of particles emitting from each vertex of the "fountain" emitter.  The direction of the particle trajectory is derived from the lighting "normal" of that vertex.  On a sphere, it is a wonderful sight.    I saw it in 3ds Max years ago.

You will notice one other interesting thing.  The particle color == the material color/textureColor at it's emit point.  Cooooool!

If my memory is working, 3dsMax allowed some options for emit locations:

- Emit from each vertex
- Emit from center of each face
- Emit in restrained-random directions/locations  (min/max emitBox already does this, so ignore, please)

Adding those features to our particleSystem... would over-ride our .direction1/2 and min/max EmitBox properties.  (good? bad?)

Activating a "get particle color from material" feature... would over-ride our .color1, color2, colorDead properties.  (good? bad?)

Maybe mesh.convertToEmitter()  ?  (adds custom stuff for enhanced emitting?)  (goofy idea, eh?)

SPEAKING of emitting, there is one other thing we emit.  Godrays.  (Volumetric Light Scattering).  Our VLS system is great, and WHAT IF... we could tell IT to emit a "beam" of godrays from every vertex, or from the center of every face, and the beam color comes from the material color at emit point?  Wow!

mesh.convertToEmitter()  ??  It overloads the mesh with both particle-handling and godray-handling emitting powers!  WOW!!! 

Super-Emitter v1.0!  Hide the dog!

Nah, we can simply temp-overload... no need to build new planets.    Also keep in mind that VLS is a post-process... which makes it 2D... which... you know... godrays aren't real light beams.  They can never aim away from the camera.  They are depth-less.  It's the same reason that lens flares don't reflect in mirrors.  They are a 2D thing, right?  (good coffee this morning)

Should we build/test it?  First create a playground, and then think about adding these features to our particle systems?  Or build the first ever Super Emitter-class mesh?  The ultimate godray and particle shower head?  4000 different spray nozzle settings and pulsing options?   Thoughts?  Ideas?   Vomit? 

Let's see... what was the theme song for "The Shower Massage" commercial?  Oh yeah.  "Why just turn-on the particles... when the particles can turn YOU on?"  Yeah!  Something like that.

[iiceman]

Looks fun! Here a pretty inefficient try, I guess, using a bunch of oldschool particle systems just to show what it could look like: 

http://www.babylonjs-playground.com/#2A4NUR#1
http://www.babylonjs-playground.com/#2A4NUR#2
http://www.babylonjs-playground.com/#2A4NUR#4

[Wingnut]

hahahhaha  EXCELLENT!  too cool!  Iceman, you are the cat's meow. 

Let's get them boxes a-spinnin and a-hoppin now.  Maybe a little physics tumbling?  hehe

Nice job, Ice!  Good to see you again, too.  You were hiding for a little while.  I hope you are well.

http://www.babylonjs-playground.com/#2A4NUR#5

Uh oh.  We got troubles with the roTATERS.   Our meat is delicious but the taters don't taste so good. 

I tried render loop box.bakeCurrentTransformIntoVertices(), but the baked taters didn't taste good, either.  heh

 

[iiceman]

Yeah, feels good to be back  beautiful scene there, you tuned the particle system quite nicely!

Everything good, I am doing very well, just a bit busy so I had to cut down the time that I spend on some of the fun things

Again, probably not a good solution, but the good old gizmo trick still does the job: http://www.babylonjs-playground.com/#2A4NUR#6

[GameMonetize]

Beautiful!! and performance is not that bad (On my old laptop as my powerful PC is dead:))

[Wingnut]

Yeah, it looks great!  Well done, Ice!  Hi DK.  Not good news about your big box.  Sorry to hear that.  Did you try percussion calibration?  (banging on it)  A guy like you should always have 6-10 emergency power-PC's warmed-up and standing-by.   I will try some remote chanting... maybe it will work.

http://www.babylonjs-playground.com/#2A4NUR#7 (can't stop, too addictive) 

In FF, I get a Error: WebGL: bufferData: out of memory after I RUN it 10-11 times.  Weird. 

[iiceman]

I had to reduce the amount of particles a bit, but it still looks totally awesome: http://www.babylonjs-playground.com/#2A4NUR#9

[NasimiAsl]

nice @iiceman 

[eboo]

hi

    scene.registerBeforeRender(function () {
    perticleFromVerticesEmitter.position.x = Math.random()*2;
    })

is working with the box but not with the sphere.

[iiceman]

@eboo not sure what you mean, seems to work for me: http://www.babylonjs-playground.com/#2A4NUR#10

[Wingnut]

  I like to keep those line 58 and line 82 numbers a bit higher.  It makes the strings-o-beads nicer, but it is a bit more boggy.  Nice effect, guys.  I've been drooling and bookmarking my brains out.   And turning knobs, of course.  http://www.babylonjs-playground.com/#2A4NUR#11

Now, if we used a Solid Particle System, and had standard particles emitting from each vertex of every full-mesh particle... then... umm... that would be something.  (something ridiculously boggy, probably).