search

UMLComputerGraphics / GraphicsProject

UML Graphics 2 Final Project 2013
7 stars 1 forks source link

Particle system "spurts" rather than "flows" #86

Closed nuclearmistake closed 11 years ago

jnsnow commented 11 years ago

http://www.chiark.greenend.org.uk/~sgtatham/bugs.html

InspectorConstructor commented 11 years ago

I get what's being said as it's been mentioned. I was hoping that staggered spawing would correct this... Nope!

Looks like controlling the number of re-birthed particles per frame is needed. in dev...

InspectorConstructor commented 11 years ago

aight, I limited the number of particles that can be reborn each frame. If we have a large number of particles then we should never get spurting.

(I hope)

nuclearmistake commented 11 years ago

Shouldn't it be a function of the average number of frames a particle lives, and the # of particles? rather than a constant?

On Mon, May 6, 2013 at 11:04 PM, Nick St.Pierre notifications@github.comwrote:

aight, I limited the number of particles that can be reborn each frame. If we have a large number of particles then we should never get spurting.

(I hope)

— Reply to this email directly or view it on GitHubhttps://github.com/UMLComputerGraphics/GraphicsProject/issues/86#issuecomment-17520924 .

Eric McCann University of Massachusetts, Lowell Department of Computer Science One University Avenue Olsen Hall, Room 304 Lowell, MA 01854 Lab: 978.934.3385 Email: emccann@cs.uml.edu Homepage (lab): www.cs.uml.edu/robots Homepage: www.emccann.net

InspectorConstructor commented 11 years ago

asdadsfadsf

actually the problem was, when a serious lag occurs, the update time could jump to a large number and kill all of the particles at once. Removed timer from the Particle::updateSelf() call, and everything is better... but now particles move based on how powerful the system is.

TODO re-normalize the system stuff with glutGet(GLUT_ELAPSED_TIME).