This is a post to keep you informed of latest spark 2 features implementations.
The API is still under active development but appears to be relatively stable and is already usable.
The SVN adress to get it is : https://sparkengine.svn.sourceforge.net/svnroot/sparkengine/spark2/

The main lacking feature is the renderer serailization. A refactor of the renderer system is scheduled and will allow to factorize the code of the different types of renderers in order to avoid to have to reimplement it for each rendering module. The development of specific module renderers will still be possible though.

PS : Dont hesitate to ask questions or share your point of view in this post.

The latest feature that I want to share with you is something I wanted to implement long ago. It is the implementation of space partitionning. The space can now be partitionned thanks to an octree.

This allows to considerably optimize algorithms running in O(n²) by making them scale better : the complexity of such algorithms becoming O(nlog(n)) with an octree.

Algorithms of quadratic complexity are typically algorithms where every particle is under the influence of all the others. A few examples :

• particle vs particle collision
  
• flocking
  
• simulation of gravitational forces (universe, galaxies...)
  

The octree management in SPARK 2 is totally transparent from the user point of view. Modifiers needing octrees have to set a constant to true. In that way, a group containing at least one modifier requesting an octree will create one and maintain it at each update. Neighboring particles and states of octree nodes can then be easily gotten in the update code of modifiers.

I ported the collider modifier (particle vs particle collision) so that it takes advantage of the octree and the increase in performance is quite consequent. With the collision demo I can have 15000 particles colliding with each other at around 60fps. The time step has however to be reduced to keep the simulation realistic.

I modified the collision demo so that it has more particles and it allows to render the octree state (by pressing F2) :



Some changes in the interface are still necessary and maybe the possibility to tweak the octree for fine tuning and gets the best of its power. Some further optimizations might also still be possible.

Hi Juff ! Here's the issue with the box zone i mentioned (the other issue was solved as it was a bug in the wrapper so the Sphere zone works as it should)

Ok i don't know how to describe this problem , so i uploaded a video
As you can see the particles are aranged in a line in the center of the zone .

I used a straight emitter (direction 0,-1,0) with a box zone

http://www.youtube.com/watch?v=6qWGo075nlU

Yes you are right. There were some issues in the code of the box that are now fixed on the svn.
Everything is working now for the box except the intersection (used for the collisions) which I need to rework.

Hi Juff . Any progress on the box collision ? and do you have plans adding a triangle zone (defined by 3 vectors for vertices) because that way we could build more complex collision obstacles based on a mesh or a level.
Regards

Hi sorry for the late reply, I was not available.

Regarding the box collision, I didnt work on it these last days. I m planning to do it soon anyway. I m currently working on the binary serialization which should be finished soon and I need to work on the renderer refactor (It is also started but needs some more thought).

For triangle zones to compose complex shapes, I dont think it is the best way of doing it. Using some raw model data directly to emit particles from it or to perform collision sounds more optimized. The hard part is to make the use of models abstract. I m thinking about it too.

I have just finished the binary SPK format (version 0) specifications and its corresponding loader and saver classes

The integrity of the data of each types of objects is ensured by its Descriptor signature (a hash computed from the name and the type of each of its attributes)

Here are the specs :

Code:

Note : The data are inserted in little endians --- Header --- "SPK" - Magic number - 3 bytes version of the format (0) - 1 byte size of the data part in bytes - 4 bytes number of objects n - 4 bytes --- Data --- n Object Data --- Object Data --- object type - string nbChar bytes + 1 ('\0' char) size of object data (not including object type) - 4 bytes object descriptor signature - 4 bytes n Attribute data --- Attribute Data --- attribute present (false : 0x00 or true : 0x01) - 1 byte // if attribute present attribute serialized - size depends on type of attributes (for array 4 bytes of length + data written sequentially)

Nothing new yet friend?

A few days ago, i downloaded and compiled latest spark, tried to load the provided test file and i only got a crash : /

is this known? i can provide more info when i get home, but spark doesnt seem to be working right yet :p

I just added the SVN branche containing the controller system: https://sparkengine.svn.sourceforge.net/svnroot/sparkengine/spark2-controllers/

The controller system is almost done; I spent a lot of time on a precise part of the system, which is only useful for GraphInterpolator for the moment... (and I'm not really satisfied of this part). I think that committing the code will allow other members to find a new solution.

The rest of the code is working nicely. There is a test in 'demos/controllertest' (it will be changed into a demo when the controller system will be integrated with the 'spark2' branch).

There are a few bug fix on this branch that are not present on the 'spark2' branch for the moment.

Don't hesitate to give it a try!