The system will have a CPU and a GPU version. For the CPU version it would be interesting to test the performance gain when adding SIMD instructions. Depending on where we will draw the line for GPU version maybe I could also add SIMD instructions.

Depending on the shape of the particles (points or quads) we might need to implement a method to make the particles always face the camera.

Currently, I am using an hand-made visual studio solution. My aim is to also develop under a linux distribution, so I'd like to have CMakeLists.txt file that

• Generates the corresponding compilation tools depending on which OS I'm working on
  • A Visual Studio solution when I'm on windows
  • A makefile running gcc or clang when I'm on Linux
• Links with the external libraries I will be using
  • GLM
  • AntTweakBar
  • OpenGL
  • OpenCL
• Includes all the source code in this project

https://www.youtube.com/watch?v=XLMU6o7n4E4

Need to deal with particle point sizes being always the same even from far away.

Can easily be fit in the CPU implementation, but could also be programmed for a "GPU" implementation. See task "GPU particles".

https://www.youtube.com/watch?v=8TNZS2AkFNs&list=FLGdfgiJ5xfm70S4BS1a60Lg&index=12

Also check how it collides the model.

Useful references:
http://gamedev.stackexchange.com/questions/46424/try-catch-or-ifs-for-error-handling-in-c
http://bitsquid.blogspot.ca/2012/01/sensible-error-handling-part-1.html

• Adopt an uniform method of handling errors (instead of returning bools at some places and 0xFFFFFFFF at other places...)
• If keeping the 0xFFFFFFF, use UINT32_MAX instead
• For shaders it might be a bigger problem if an error occurs, because the program will simply not work properly (in contrast with the textures which is not a big problem for the app itself if they fail)

I might have to change for pointers in the ParticleSystem. I also need to update the renderer class and the app.cc file so that I can correctly inject the particlepool or the particlesystemcomponent into the renderer

Had to hardcode a color in the shader to bypass the issue. May have to try changing the vector types from u8vec4 to standard vec4.

in files

• particle_system.* (do not care about the remove thingy and parallel stuff)
• particle_system_component.*
• app.*

• - Put shared_ptr/unique_ptr where applicable,
• - check if component pattern is applicable : http://gameprogrammingpatterns.com/component.html
• - Rename everything properly
• - Change unique_ptrs for raw pointers in pool to see if it gives some performance boost
• - Apply macros for copyable/movable everywhere
• - Change raw classes for pointers (when it is an attribute of a class)
• - Should also create folders and corresponding namespaces for classes (core,utils,dynamics,etc.)
• - Remove the PUBLIC init/terminate idiom in classes and put initialization in constructor.

Maybe it will be done directly in the renderers (TBD, see issue #11 )

Could be done by using different methods

• Could do as mentioned there : http://stackoverflow.com/questions/8897019/git-how-to-handle-git-libraries-in-project
• Or add the external libraries in an /ext folder and link to it in the CMakeLists.txt file

Libraries concerned are

• GLM
• AntTweakBar
• OpenGL
• OpenCL

Since the last time the Cmake files were updated a lot of new files and external libraries were added to the project. I am currently maintaining a VS solution, but if people want to reuse this project, we need to this for sure.

Debugged by putting an hardcoded color for vertices and saw the points are simply not moving. Debugged and saw that the values are all the same.

The solution needs to provide a way to

1. Include the shaders in the project somehow
2. Get the shader source code
3. Create a shader
4. Attach the source code to the shader
5. Compile the shader

Right now, the application loads explicitely (hardcoded in the code) all the different projects that could be executed in the application.

It could be replaced by another setup like this one :

Each project has its own dll/.so, the engine is a .lib/.a
and the executable only runs the dll/.so loading (through .ini/xml files maybe?)
and launching the said dynamic library. But this is good enough for now for decoupling.
An issue will be created for this.

I also tried to register the projects in a map in a static fashion, meaning that its initialization(project registration) would be executed before the logic in the main, but ran into runtime issues. Wanted to focus on the core.

http://www.opengl-tutorial.org/beginners-tutorials/tutorial-3-matrices/

https://www.youtube.com/watch?v=8NgCozKDy7k&list=FLGdfgiJ5xfm70S4BS1a60Lg&index=14

Just as explained here https://www.youtube.com/watch?v=7hC_QT4GLiU

NOTE: GeForce GTX 660 limits:

• GL_MAX_UNIFORM_BUFFER_BINDINGS -> 84

• GL_MAX_UNIFORM_BLOCK_SIZE -> 65536 (bytes)

• GL_MAX_VERTEX_UNIFORM_BLOCKS -> 14

• GL_MAX_FRAGMENT_UNIFORM_BLOCKS -> 14

• GL_MAX_GEOMETRY_UNIFORM_BLOCKS -> 14

• See light_module.cc, current implementation is not good enough for having particle lights. I need the Light structure to be directly integrated in a new ParticleData (like in particle_core_data.hh).
  struct ParticlesLight {
  float intensity;
  float radius;
  float attenuation;
  };

struct LitParticlesData {
std::unique_ptr<float[] > m_lifetime;
std::unique_ptrglm::f32vec3[] m_velocity;
std::unique_ptr<glm::u8vec4[] > m_color;
std::unique_ptrglm::f32vec3[] m_position;
std::unique_ptr<ParticlesLight[]> m_light;
...
};

NO, in fact the attributes of ParticlesLight will be shared for all particles. So ParticleCoreData is enough, I only need a light updater (CPU or GPU). If CPU, this light updater only needs to update the UBO block, which will look like this:

layout (std140, binding = WHATEVER) uniform ParticleLightsData {
vec4 ParticleColors[2000];
vec3 ParticlePosition[2000];
float Radius;
float Intensity;
float Attenuation;
}

The 2000 is a rounded value that matches GL_MAX_UNIFORM_BLOCK_SIZE (65536 byte for Geforce GTX 660) for the UBO above (total size is 56012 bytes).

Also, UBOs are usually faster than SSBOs, and it is quite standard to use uniforms this way, (see https://github.com/andreasmuller/NoiseWorkshop/blob/05eacee5dc58e48265e0153aba9ad2782190f185/ParticleCloudGPU/src/ParticleSystemGPU.cpp#L128)

• A parameter will determine what is the percentage of particles that will emit lights. This percentage will cap at PERCENTAGE * NUMBER_OF_PARTICLES * SIZEOF(LIGHTDATA) < GL_MAX_UNIFORM_BLOCK_SIZE (in other words, needs to be < GL_MAX_UNIFORM_BLOCK_SIZE/(NUMBER_OF_PARTICLES * SIZEOF(LIGHT_DATA))). So with the data above, if particle_count = 5000, the percentage must cap at <=40% (0.4*5000 = 2000).

• Since the alive particles (in the pool) are not sorted, the first ones could be the lit particles. To make sure this is truly "random", the life of each particles should be randomized (their age should be randomized and capped at maximum lifetime)

Since the goal is to have a highly customizable particle system, users might find interesting to save the current settings via the GUI and create all sorts of customized effects.

• The axis lines should be put as a debug option....maybe of opengl_context or something new. Certainly not the renderers, because it would be something to duplicate in each renderer. Also there'll be more than one renderer per system (most likely) and this needs to be rendered only once.

• Find a place where to put the MVP matrix.

ShaderManager
GraphicContext
Camera
ParticleSystem

http://gameprogrammingpatterns.com/service-locator.html
http://gameprogrammingpatterns.com/component.html

I love the servicelocator pattern for the factories...check how it integrates.

Redesign with component pattern
rename sources to spawns
rename dynamics (maybe?)
set both as deriving from a component class
start to integrate the entity/component pattern where the particlesystem is an entity/aggregate of components and we could have a noise component which would be a dynamic

There's a performance leak for applications that switch programs too often. There shouldn't be any other program IDs outside of the renderers, except for entities which use compute shaders, so it shouldn't be that hard to implement.

When pressing left click, particle emitter position should be set accordingly with mouse position translated into world coordinates. Emission rate should also be set to 0 when left button is released.

This implies either changing unique_ptrs for emitters and dynamics in the particle_system to shared_ptrs and add a shared_ptr to the corresponding emitter somewhere (event handler?.....) OR go through an ID for the emitter object ID and add methods in the Iparticle system to set parameters....

In other words, I want to be able to keep track and have multiple particlesystems in my applications. They would be accissble from a dictionary and selected by either :

• inputs sent to the program
• project properties including definition of a macro
• directly in the code of main selecting the right project

Currently everything is in app.cc, I need to seperate the glfw, glew and even shadermanager initialization in a separate component.

Solutions are:
1- Clean the way it is used in app.cc and leave it there
2- Maybe have a component structure?
3- Have a GraphicContext class and make OpenGLContext and Direct3D (or whatever it's called) inherit from it
4- I like the name GraphicComponent, but it would be confusing and I could easily assume I need to use this to render something...

As demonstrated at cpp.sh/7m77d. So I would need to change raw class/shared_ptrs/unique_ptrs for raw pointers to class where performance is critical or put unique_ptrs if performance is not an issue.

https://www.opengl.org/discussion_boards/showthread.php/198689-Compute-Shaders-(Particle-System)
https://www.khronos.org/opengl/wiki/Transform_Feedback
https://open.gl/feedback

https://www.opengl.org/discussion_boards/showthread.php/198689-Compute-Shaders-(Particle-System)
http://stackoverflow.com/questions/6543924/is-double-buffering-needed-any-more

In those files:

• - spherical_stream_source.cc (not being in spawned in a sphere, see http://corysimon.github.io/articles/uniformdistn-on-sphere/ for this)
• - camera.*
• - opengl_context.*
• - stub_renderer.*
• - renderer.hh

NOTE: As seen here https://github.com/amulware/genericgamedev-gpu-particles/tree/cpu-gpu-comparison/GenericGamedev.Pixelation
The CPUSimpleParticles.cs, AlmostGPUParticles.cs and GPUParticles.cs demonstrate how you can completely render/update on the GPU.

List of things to do for this:

• Need to add a call from app to particlesystem or something else
• Maybe add renderers or entities that can iterate through all the pool particles and render and use the camera and add some special effects i guess
• I need to provide minimal implementation in the shaders (take the matrices and multiply it with the vertex location)

SEE THIIIS
http://stackoverflow.com/questions/8608844/resizing-point-sprites-based-on-distance-from-the-camera he uses a sampler2darray as a uniform, would it be possible that way?

COMPUTE SHADERS

I need to have tests to cover at least

• The pool functionalities
  • Particles swapping, creation, destruction, corner cases, etc.
• Core functionalities
• GUI stuff

If many layers doesn't affect performance, then we can

• rename sources to spawns
• rename dynamics (maybe?)
• set both as deriving from a component class
• start to integrate the entity/component pattern where the particlesystem is an entity/aggregate of components and we could have a noise component which would be a dynamic

Use either a custom class or a std::function (lambda) as a parameter to use in the particle system to initialize the particles when LifeDeathCycle::Disabled is used in the particle system.

http://www.glfw.org/docs/3.0/group__input.html

I would want to have a scene including a skybox/skysphere or a background.

A nice texture for a skybox
http://www.zfight.com/misc/images/textures/envmaps/stormydays_large.jpg

NOTE: We might have to increase the viewport depth in order to not clip the skybox/skysphere wherever the camera is. I think some applications move the box/sphere with the camera when it moves.

Self explainatory. Resources are shaders, textures, meshes, sounds, etc.

If applicable see where to draw the line of necessary vs unnecessary.

1. Bug when moving camera with middle mouse button. After clicking, the cursor is positionned at the place where the cursor was when the middle mouse button was released.
2. Sometimes when moving camera with W,A,S,D, the camera does a 180 degree turn instantly.

https://goo.gl/images/og7RaI

Prerequisite(s) :

• - Be able to display sprites with blending
• - Find adequate textures/material (IMPOORTANT)
• - Have an event manager specific per project
• - Find the right type of blending for this kind of particles
• - Have an UI that allows me to change parameters at runtime

Implementation will need:

• - Find a way to store the info about normals for each vertex (must use quads directly instead of points, OOORRR maybe we could still use billboards? would kinda look weird but the normals would be easy to compute (see wPosToCamera in geom shader)) BETTER IDEA: We could simply keep the normal vector and generate the quad from it and apply the texture (would need an up vector also)....
• - Material class
• - A luminosity intensity gradient array -> NOPE
• - Lights (particles will need to have reflection and refraction)
• - Particles must have a random initial rotation axis and rotate around it
• - When they are about to die, particles drops their alpha value so that they fade-out in the oblivion
• - Curl noise to give a leaf effect
• - Not sure they will have to face the camera

In files

• global_acceleration.*
• dynamic.hh
• default_dynamic.cc
• particle_pool.*

CHECK THIS: http://wiki.popcornfx.com/index.php/CParticleRenderer_Ribbon

https://answers.unrealengine.com/questions/41579/how-to-create-a-particle-trail.html
https://wiki.unrealengine.com/Ribbon_Particle_%28Tutorial%29
https://www.youtube.com/watch?v=jBUF6at1s1o
http://www.digitaltutors.com/lesson/45920-Ribbon-particle-emitters

See how it integrates with GLFW. You might have to reenable cursor upon a certain click to make it available for selecting some features. Maybe when middle mouse button is released or something.