New Particle System

[Hao Wu]

Hey guys,

Remember the particle effect editor?

http://www.rigzsoft.co.uk/timelinefx-particle-effects-editor/

Apparently, some one has written a C++ generic runtime 

http://www.rigzsoft.co.uk/c-code-for-timelinefx/

This should be a great starting point for our new Particle system

[Ricardo Quesada]

sounds good.

Our current particle system has a design flaw. And this is the flaw:

ParticleSystem
{

    update(dt) {

       apply_hard_coded_math(dt)

    }

}

apply_hard_coded_math(dt)
{

  if(mode == radial) {

    // do something

  } else { // gravity mode    

     // do something else

  }

So, if you want to edit the current math, you have to subclass the particle system, which is not very convenient.

And also, in the hard_coded_math we have a switch, that allows us to use one kind of math, or another.

So, what we need is to be able to change the math in runtime in an easier way.

Something like this:

particleSystem->setMath( MathObject );

And the code should look like this:

ParticleSystem
{

   update(dt) {

     apply_math(_math);

   }

}

By doing that:

   - we no longer have a hardcoded math

   - radial and gravity modes are going to be 2 different instances of Math

   - it will be easy to support new particle system (like the one mentioned by Hao)

   - users will be able to customize the particles in an easier way

[Dawid Drozd]

I think templates with injected math would be faster

Like

class MathInterface

{

    void update(){} //No virtual nothing

} 

class MathRadial

{
    void update()

    {

        //impl

    }
}

template<typename Math>

class ParticleEngine

{

    void update()

    {

        math.update();

    }

   Math math;

}

no inheritance simple composition

to customize you only need implement MahInterfance.

No virtual == faster 

we can add a lot of static_asserts for checking a lot of stuff. 

--
You received this message because you are subscribed to the Google Groups "cocos2d JS development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cocos2d-js-dev...@googlegroups.com.
To post to this group, send email to cocos2d-...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Pozdrawiam
Dawid Drozd.

[Ricardo Quesada]

Yes, templates are going to faster, for sure.
And whenever possible, we should use non-virtual functions or indirect calls.

But sometimes it is a mix between speed and ease of use.

For example, I was thinking that we could use an std::function<> for the math code.

eg:

class Particle {

  setMathFunction( const std::function<void<ParticleSystem*, float>>& math_code);

}

Pros:

  - very handy

Cons:

  - slower, since it will use an indirect call.

In any case, what we need is to do some performance tests.

If the new API with std::function<> is no more than 10% slower than the current implementation, then I think we should use std::function<>.

Otherwise, we should re-discuss how to implementing it, and templates will be a valid solution.

[Dawid Drozd]

I want only say that i don't like this way of thinking 10% here 10% there and when to sum up this all we loose 40% of performance. I understand that ease of code is more important but we can achieve this by high hermetization. On example of this particle system. Who modify code of particle? No one. Only people who know what they are doing. I use only XML for editing particles i don;t even touch code. We have few engines for game programing but i think cocos should focus on speed and open source part. 

Code should be high quality and high customizable.

I agree with tests they are important and often show something that we do not expect like performance boost :)

--
Pozdrawiam
Dawid Drozd.

[Ricardo Quesada]

I also don't like that way of thinking :)

Performance for me is very important. That's why v3.0 is about 10x faster in the rendering, and about 3x faster on visit, etc, compared to v2.

And the engine should be (among other things):

 - easy to use

 - easy to maintain and extend

 - and fast

And it is a question of balancing all the features.

For example, we could write the engine in Python: it would be super easy to use, extend and maintain, but with terrible performance.

We could write the engine in asm to gain some performance, but it will be impossible to use, maintain and extend.

C++11 has great features (like lambda objects), but dispatching them are slower than non-virtual functions.

So, should we use the new features in order to gain a better API, but at the cost of losing some performance ?

Well, it depends the cost of the performance and the feature, and should be decided in a case-by-case basis.

But for the particles, I want to see what is the performance penalty of using the std::function for the new math.

In any case, the two existing modes (gravity and radial) could be hard-coded as they are now, and only call std::function<> code only if a new one is set.

[Hao Wu]

I agree with Dawid on this

People want to modify our particle system algorithm because the current one is too simple, it cannot do a lot of things. Once we provide a powerful enough algorithm, like the timeline fx particle system, like the Unity's Shuriken Particle system, then the demand for customizing particle algorithm will diminish.

[Xiaoming Zhang]

I don’t think there is a powerful enough algorithm to fit all needs. So customized requirement is needed.

And i agree with Riq that

- we can use hard code for existing algorithm, and may provide some other useful ones

- but we also need a way to customize

About performance issue, i think we can discuss it after testing.

Best Regards

Minggo

[Dawid Drozd]

Ok only 1 thing left you check performance with your Profiler and this profiler has bugs ;/ 

I write my own simple time measure tool and comparing with cocos (from version 2) cocos profiler returns bad times sometimes with even 1s fail

[Hao Wu]

The current algorithm is very basic

almost everyone think this way, but almost nobody write their own algorithm, why?

1. They don't have the confidence that it is fast and bug free
2. you will also need an editor to get anything out of the new algorithm
3. its hard to come up with an algorithm

What we want is to have advanced user, for example, the guy made Particle designer, the guys from Timeline FX editor to write their algorithm to support their format which works with their editor.

The average joe developer doesn't want to implement their own algorithm because the above 3 reasons, what they want is just damn powerful particle system

[Dawid Drozd]

Yeah as Hao said.

If cocos particle system is quick as possible it would be great and i think particles are used a lot. Everyone will appreciate this. I understand that high performance code is hard of course it must be very very quick and has very very good architecture. So people like from Particle designer can add their particle systems. But all of this we can achieve without std::function or virtual methods. 

--
Pozdrawiam
Dawid Drozd.

[Ricardo Quesada]

Hao, you have a point.

Yes, probably what we need is a more sophisticated math algorithm with an editor (having flexibility in the particle system has lower priority).
Is Timeline FX free?

[Hao Wu]

I think the plan is to support their format first, once the community is impressed by the new particle system, we can them write our own editor

Timeline FX editor is not free, its 30 EURO or $50USD, same cost as particle designer 2

[Xiaoming Zhang]

Is there any doc about the format?

Best Regards

Minggo

[Hao Wu]

Please refer to my first email

http://www.rigzsoft.co.uk/c-code-for-timelinefx/

[Xiaoming Zhang]

I have read it.

But it is not official codes.

And i think we need doc to describe format when a bug met.

Best Regards

Minggo

[Hao Wu]

Yes, there is no official code for TimelineFX but why don't we give it a try

If it has bugs, its not a big deal, we have bug in our particle system, that is reversed direction upside down, and in from out straight out of particle designer 2

and once we have implemented it, we can make our own editor and modify the algorithm to our needs

[Xiaoming Zhang]

Yep.

We can do it like this.

@ricardo

Where to record these requirements?

Best Regards

Minggo

[Ricardo Quesada]

The best way to record it is to put it in Hao's Trello's board.