next »

[guilhermegrg]

that's up to the renderer and the scenegraph to determine the order of render and the state management of opengl to determine how are you going to render it, if with depth or without.

That is one the things that in this version i think are not correct, but i guess that with Marvin help on the renderer we can get it right. I mean if other ppl can do it like that, we can also do it.

Its just a question of doing some research on google...

[Marvin Fröhlich]

that's up to the renderer and the scenegraph to determine the order of render and the state management of opengl to determine how are you going to render it, if with depth or without.

That is one the things that in this version i think are not correct, but i guess that with Marvin help on the renderer we can get it right. I mean if other ppl can do it like that, we can also do it.

Its just a question of doing some research on google...

Yeah, I don't expect problems from that.

Marvin

[Mathias 'cylab' Henze]

Even so, the calculations on the ParticleManager are fixed at 45 Hz, that is, at 45 times per second, independently of the timelapse.

Just out of curiosity: why 45Hz? Taking common refresh-rates into account I would have choosen 25, 30, 50 or 60Hz. I think it would be best to make that configurable.

If the time is much greater than 1/45 th of a second, let's say....13/45 of a second, then it will iteratively calculate one step at 1/45 of a second for 13 times.

Can't this be shortened to one calculation with a bias factor?

One other issue is the scenegraph. I haven't seen much of xith3d, so what i am saying   might be nonsense, but i think each particle system should be placed in its own node, with its own position. the translations and rotations applied to that node are only applied to the generators, that is where the particles are created.

Once the particles are born, they shouldn't be affected by translations or rotations, as their position is calculated by the PS.

There has to be at least a way to pass a velocity to the generator, since particles emerged from a moving object have to substract this from their launch velocity. Also there should be a way to pass in a deceleration factor to simulate e.g. air friction.

Great work so far!
Mathias

[guilhermegrg]

On your first question:

at first i was using 30Hz, but it's a little jerky, so at 45 hz i found things were much more fluid. So 45 hz was the minimum for my perception for a fluid motion.

It is configurable, though, so no problem there.


Second question:
As this will be an alpha version I am quite aware of a lot of different places on  the code were i can speed things up a bit. But right now what matters is the functionality. Once a certain class structure is fixed, its implementations can be done a million different ways, some with more performance than others.

On that particular issue, i think it can't be done in just one calculation.

That is because these calculations require a certain granularity outside of which you'll just get weird results.

Consider that my generator is pointed to my left - so the particles exit to my left  at a certain speed - and is rotating to my right at a certain angular speed. Let's say  180 degrees/second.

If for some reason the particleManager receives as a timelapse 1 second, it will perfom 45 calculations with a 1/45 timelapse.

that is, my generator will rotate in small steps to my right 45 times, and each time will generate some particles.

If i were to do that with a  one second time lapse, that means my generator would jump from being in my left to my right, and it wouldn't generate any particles in between, which was the behaviour i wanted.


Add to that that in future versions there will be forces and collisions, and you can consider that its needs to be iterative to work properly. But if someone has a better solution, they will be free to implement it once the source code is out.



Third question:
Good points...Those are the kind of issues that arise on integrating with a scenegraph...
About friction and all that...later versions....