Code: Particle module or include file plus editor

[Michael Hartlef]

I know guys you must think that I am crazy. Here is the next generic thing that could help us create the game faster and woudl be great to use for other projects too!

And generic particle module or include file, based on Opengl/TBGL. These are the functionalies I can imagine:

1) Load precreated particle FX files, which contain the rules for particle emitters
2) Manage particle emitters
3) Particle editor where you can create the particle fx files visually and see the particles in action

Who wants to take this job?

Michael

[Petr Schreiber]

Hi Mike,

I have this in my head for long time. This is something worth adding to TBGL, but I am not sure about the syntax for now. So I would go the path of include file, and once it settles down I can hardcode it to module.


Thanks,
Petr

[Michael Hartlef]

Hi Mike,

I have this in my head for long time. This is something worth adding to TBGL, but I am not sure about the syntax for now. So I would go the path of include file, and once it settles down I can hardcode it to module.


Thanks,
Petr


Great. Generally we should do it first as an include and if it is slow then turn it into a module. Thanks for taking this on.

[kryton9]

I wrote a similar response in the GUI thread, I agree for the contest-- I think include files make sense, and perhaps could be the start of a module in the future.

[Petr Schreiber]

It seems Simone would be interested in cooperation on particling, that would be very nice.

My idea is to use entity system, as we can make range of entities to face same point ( the way particles are rendered usually ) + maybe the UDT container in each of the particle entity.

What properties do you think Particles should have?


Petr

[Michael Clease]

Petr look at this

http://www.gamasutra.com/features/20000623/vanderburg_01.htm

[Michael Hartlef]

Here are some more links:

http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=19
http://www.gamedev.net/reference/list.asp?categoryid=72#225

http://www.swiftless.com/tutorials/tutorials.html

[Simone]

Hi,

Petr the Idea to use Entity system it's very good. :D

I think that one properties necessary of particles system it's what we have to display, because for create dynamic particle engine we have to know in which situation we are, and the generic rules of the environment (like gravity).

Michael and Abraxas thanks for the links of Particles tutorial. ;)

Ciao,
Simone

[Petr Schreiber]

Thanks for the links,

very good reading, I will study them all.
Simone, I sent you concept of particles on mail, it does not contain the flexibility of systems shown in articles yet.


Petr

[Simone]

Hi Petr,

Thanks for Example of particle, i will check it and let you know. ;)

Simone

[Petr Schreiber]

Hi,

just little notice - we did not posted anything in this topic for long, but we are discussing this topic via email.
We are converging to final decision in parameters for the particle systems and particles as a such, based on information mentioned in articles you gave us as reference.


Petr

[Michael Hartlef]

but we are discussing this topic via email.


??? :o :( :-\

[Petr Schreiber]

Ok,

I think those 4 heads mean "why is there no open discussion".
I have no problem with it.

So for now, I have current idea for types, abilities:


TYPE Particle
position AS tXYZ
speed AS tXYZ

rotation AS DOUBLE
rotSpeed AS DOUBLE

scale AS tXY
scalegrow AS tXYZ

texture AS LONG

color AS RGB
alpha AS BYTE
END TYPE

TYPE ParticleSystem
blendSrc AS LONG
blendDst AS LONG

arrayPTR AS DWORD ' -- Pointer to array of particles
END TYPE


I think they are pretty self explanative.

There is other thing to consider:
What I am thinking of is making the particles "preanimated"
in texture, which would contain all key frames from particle
birth to its death, let me know which approach do you
prefer, or if you are thinking of something different.


Petr

[Michael Hartlef]

Thanks for the info Petr. Preanimating texture? Mmmh, nice feature. Hopefully not to costly for the fps.

[Simone]

Hi,

Yes I'm according with you create a particle "preanimated" it's the right way, simple and clean to put into script game.
Ok i'm work with you on it, if you havo some ideas o code that i have to do or check for example i'm ready ;)
(you have more experience than me on Particle, i try to support you ;D) .

Ciao,
Simone

[Michael Hartlef]

Question as I might not have understood: Preanimated.... did you mean a sequence of images that are used over the time?

[Petr Schreiber]

Hi Mike,

I was thinking of prerendering the particle animation to bitmap, and then just shift frames like in cartoon movie.
The implementation would be simple - one particle = one 4 vertex model. To animate, we would just shift 1 coordinate by constant step after constant time.

As I said we were discussing this in email so not decided which way to pick.
Hybrid approach would be cool, but I think not necessary for the game.

I need to do more tests.



(you have more experience than me on Particle, i try to support you ;D) .

Simone, I need an opponent :D I need you to stop me when I go in wrong direction - longer time in TBGL word does not mean I am more experienced, I still tend to do bad descisions from time to time.


Petr

[Michael Hartlef]

Mmmh, I would need this to see in motion to judge that approach. I'm affraid that this won't look right. But like I said, I would need ot see this.

[Simone]

Hi,

@Petr I'm trying to apply the new ideas of "preanimated" particle at the script of explosion study with entity, (for test new ideas) ;D.
I think that some parts can be reused.
I post in the next few days my result.

Ciao,
Simone

[Petr Schreiber]

Thanks Simone,

I am now writing documentation for commands Mike & Michael suggested ( developed now ), then I will join your work, very much appreciated.

I was trying to put example for Mike here, but could not find any suitable "animated strip" for tests.


Petr

[Simone]

Hi Petr,

is some day that I'm doing some tests on particle System and i put here some ideas.

if instead of using an array pointing to the structure "particle" we use a matrix to handle such as multiple explosions?
if we do a different movement of particle based on the texture that are load at the moment ?

it's only some ideas that I have in the head what do you think about this ?

Ciao,
Simone

[Petr Schreiber]

Ciao Simone,

the main reason I put pointer there is that UDT variable cannot hold dynamic array ( by design ).
That means we would have to hardcode maximum particles somehow, which is not ideal.

I am not sure I understand the "if we do a different movement of particle based on the texture that are load at the moment ? ". If you mean whether texture will be preloaded, then "yes" :)

I am thinking which kind of particle effects we will need for the game.

I presume:
- smoke ( when there is hovercraft damaged by shot )
- spark ( when hovercrafts are too close to each other )
- explosion ( when hovercraft ... is too tired to go on :) )

Can you think of anything more?


Petr

[Simone]

Hi Petr



I am not sure I understand the "if we do a different movement of particle based on the texture that are load at the moment ? ". If you mean whether texture will be preloaded, then "yes" :)


Ok. It was like i tought



I am thinking which kind of particle effects we will need for the game.

I presume:
- smoke ( when there is hovercraft damaged by shot )
- spark ( when hovercrafts are too close to each other )
- explosion ( when hovercraft ... is too tired to go on :) )

Can you think of anything more?


Maybe the we can do some how "rain" but it's not simple.

Ciao,
Simone

[Petr Schreiber]

Hi Simone,

rain is tricky, but not impossible.
I would do it in similar way the snow was done in "Indigo Prophecy" ( aka "Fahrenheit ").
Have a look here: screen (http://static.computergames.ro/cg/assassin/images/fahrenheit/fahrenheit107.jpg).

They did not simulated movement of every single particle, they made bigger particles, holding multiple snowflakes ... and it still looked very impressive ( looks better in movement )

Regarding our progress ... I think if we will think too long how to do it, we will always find some downside, some problem, because we will want to find ideal system.

I propose do something little different. Think which effects we will need for the game, then do each of them as single script using our prefered technique. Then we will see what those effects have in common, and that will be the thing we will base more general "particler" in the end.

In worst case we will have effects ready for the game ( whic is good ), just not some general system ... that is pesimist view. All other cases are only better ... optimist view :)

What do you think?


Petr

[Simone]

Hi,

I agree with you. In fact I hope to be able to send my first script for the explosion before Monday '. is ready but there are some things that i want to improve. ;D

I've play the game Fahrenheit and if we can do some similar to snow would be nice.

Ciao,
Simone

[Petr Schreiber]

Hi Simone and others,

here comes basic "smoke" demo.
It uses entity based particles, user data for each entity and finally TBEM module as the heart of particle spitting :)

It is not general purpose yet, but more kind of demo of direction we might take with Simone.

The particles fade from starting color to end color, they have some constant velocity, scale shifts...


Petr

[Michael Hartlef]

Nice one Petr. And ncie use of TBEM. Thanks ! :)

[Petr Schreiber]

I thank you for TBEM,

it is very easy to use!
I need to learn it better ( TBEM_SetData / GetData ) to make everything even more "automated".


Petr

[Simone]

Hi,

Petr Nice version, it's like my idea of Explosion (but your Version it's more simple to check than My ;D).

Ciao,
Simone

[Simone]

Hi all,

I've study for Explosion something like Image Below.
There is some thing that I've to check before post the script.

Simone

[ISAWHIM]

Could you use your camera trick, and render the explosion by itself...

Project the frame, or the whole animation into the scene, with the TBGL_RenderToTexture... projected onto a sprite that always faces the camera, or multiple sprites in layers. (As a depth option)

Each frame could be an array value, so a 100 frame explosion, could look like 100 separate explosions. (Though, the end result of all those alpha-blendings may be taxing.)

Particle grass... (Forced simple rotation, based on distance from camera. Closer sprites re-render or load more angle precision, while distant sprites only have 16 or 32 angles. Same array, just skipping cells, and not changing distant sprites until X angle change.)

Particle bushes... (One single object rendered at an angle related to the entity position in the world, but drawn on the screen as a BMP sprite in the distance.)

Particle leaves... (Sprite on the ground, but leaves blow into fog/alpha on the particle cam, and become invisible at the edge of the sprite/view. Rendered in the scene showing motion underneath. Same effect as a burn-mark on a wall or a simple projected shadow.)

Not making requests, just thinking of odd ways to use this, "invisible production studio". Could be a generic setup, not specific to a particle, but a general entity. (Could be used as the skybox also... or a rear view mirror... or an INFO screen which does not slow-down scene rendering. Since it is not rendering and blending text onto the moving ground/scene, it is rendering in the skybox. Plus, that might help speed-up the game rendering, if it covers enough of the screen area.)

[Simone]

Hi ISAWHIM,

Thanks for your suggestion, Let me hear that Petr think about this.

Because I and Petr had thought to develop only what we needed for the Game, and we had not even thought to things like grass and Sprite.


Ciao,
Simone

[Petr Schreiber]

Hi Simone,

looks cool!
Can't wait for code, screenshot looks really nice!

Jason,

thanks for your ideas, we have used approach you mention for vegetation for flat forrest with partial glow demo already in the past. But we have code for 3D trees as well :), which look a bit better from close distance.

I agree with Simone - better to focus on what we need now for the game directly.


Petr

[Simone]

Hi,

I've done some modify at script of Smoke of Petr. I've add an example of Explosion with particles based on idea of Petr.
it's a test no a final version. ;D

Ciao,
Simone

[Petr Schreiber]

Hi Simone,

very good!
Thanks a lot for this sample, it cheered me up :)

I will just find the way to keep Particle_Process event alive after end of explosion.


Lucky Petr

[ErosOlmi]

Simone,

what a bout 1 or 2 pictures of your great job?
;)

Ciao
Eros

[kryton9]

Thanks Petr and Simone for the neat special effect demos!

[Simone]

Hi,

Thanks to all :D,



I will just find the way to keep Particle_Process event alive after end of explosion.


@Petr, Yes I was also thinking about how to do this.
Next test i would try to do are sparks. ;)

P.S: I've add two images about Explosion_Smoke script in post with code. ;)

Ciao,
Simone

[Petr Schreiber]

Simone,

I am hypnotized by your explosion, it could be used in sci-fi movies - very life-like.
Just the sparks now ... and we can make Episode 7 of StarWars :)


Buona notte,
Petr

[ErosOlmi]

Hi Simone.

your script work perfectly here from the particle point of view but on my computer I get a delay of more than 2 secs when the script starts and a delay of about 3 secs when the rocket hits the rock.

I made a lot of tests to try to understand where the script stay during this delay but not able to understand it.

Ciao
Eros

[ErosOlmi]

My problem seems related to some TBEM calling.

[ErosOlmi]

I made more investigations and I think problem is inside TBEM_Run.
Maybe more functions are using the same TBEM ID. Can it be?

[Michael Hartlef]

Simone,

when the rocket hits the asteriod, it isn't neccesary to add another Particle_Process event, as the one from the Particle_Add (smoke) is still alive and so will run further.


SUB Missile_AI( )
LOCAL Distance AS DOUBLE
LOCAL eventId AS LONG
LOCAL last AS LONG = TBGL_ENTITYGETFREEID( %sScene, %particleFirst ) - 1
LOCAL eventParticleAdd, eventParticleExplosion AS DWORD
LOCAL count AS LONG
GLOBAL Time_explosion AS LONG
IF TBGL_ENTITYGETUSE( %sScene, %eAsteroid ) = %FALSE THEN
IF GETTICKCOUNT - Time_Explosion > 10000 THEN
eventId = TBEM_GETEVENTID( %evt_Particleadd )
TBEM_DELETEEVENT( eventId )
Time_Explosion = - 1
END IF
END IF
IF TBGL_ENTITYGETUSE( %sScene, %eAsteroid ) THEN
Distance = TBGL_ENTITYGETDISTANCE( %sScene, %eAsteroid, %eMissile )
IF INT( Distance ) = 0 THEN
TBGL_ENTITYSETUSE( %sScene, %eAsteroid, %false )
eventId = TBEM_GETEVENTID( %evt_Particleadd )
TBEM_DELETEEVENT( eventId )
eventParticleExplosion = TBEM_ADDEVENT( "Particle_Explosion", %evt_ParticleExplosion )
TBEM_SETREPEAT( eventParticleExplosion, %TRUE, 20 )
TBEM_ADDTRIGGER( %evt_ParticleExplosion )
'eventParticleAdd = TBEM_AddEvent("Particle_Process", %evt_ParticleProcess)
'TBEM_SetRepeat(eventParticleAdd, %TRUE, 20)
'TBEM_AddTrigger(%evt_ParticleProcess)
TBGL_ENTITYSETUSE( %sScene, %eMissile, %false )
Time_Explosion = GETTICKCOUNT
END IF
TBGL_ENTITYSETTARGET( %sScene, %eMissile, %eAsteroid )
TBGL_ENTITYPUSH( %sScene, %eMissile, 0, 0, 21 / framerate )
END IF
END SUB

[Michael Hartlef]

Hi Simone.

your script work perfectly here from the particle point of view but on my computer I get a delay of more than 2 secs when the script starts and a delay of about 3 secs when the rocket hits the rock.

I made a lot of tests to try to understand where the script stay during this delay but not able to understand it.

Ciao
Eros



Hi Eros,

are you running this in an OS emulation?

[Simone]

Hi Mike,

Thanks for you suggestion :)

Ciao,
Simone

[ErosOlmi]

Under OS emulated all is working fine.

On my real machine it stops for 1 sec at the first TBEM_RUN and later when explosion takes place for the first time. And this also removing the 3 lines you mentioned in previous post.

Ciao
Eros

[Michael Hartlef]

Mmh? ??? When you add an event, it stores a starttime (GetTickCount). When you call TBEM_RUN, it looks at all active events (which triggers where fired), if there starttime is older then the current time (GetTickcount) of TBEM_RUN. If the trigger is a repeating one, a new starttime is set (Old starttime + trigger_repeattime). So what you have experienced sounds like somehow the starttime is set 2 seconds in the future, same when the explosion starts.

I uploaded the current sources so you will be able to debug this better if you want.

Michael

[ErosOlmi]

Thank you so much Michael.
I've already downloaded sources. I will study them this evening when at home.

In any case, this is happening only on my computer. On other computers this is not happening. So very very strange.

Ciao
Eros

[Michael Hartlef]

With the sources you can debug it better. Maybe I'm doing something wrong and this way we can catch it. I allready saw two little other buggies, but they are not related to your problem. I would bet one that. So a new version is bound to come anyway.

[Simone]

Hi Petr,

I was thinking how to do a sparks, you think is best to use polygon like point and line and change size and color or use a texture of one spark like Explosion and smoke. (we have to search the best way for do star wars 7) ;D

Ciao,
Simone

[Petr Schreiber]

Hi Simone,

I would not use GL_LINES, as they are slower than classic polygons and they do not get thinner with distance.

There are many approaches to replicate sparks, I have seen following used in games ( and preproduction of Episode 7 ;D ):

Approach #1> Solid object
... so no particle. You create little spark object, you put lot of them on one place ... it is like launching multiple tiny rockets. You have to turn them during flight as they fall down.

Approach #2> 2 poly Particle
Two crossed quads with spark texture - turned as they fall down.
They do not always face camera, look quite good.

Approach #3> Particle
Round circle fades from yellow to black and has very short life span.
They always face camera, but fall down attracted by gravity.

So all have in common some gravity force, which is missing from our system now.
Approach 1 represents one spark by one object of few polygons, approach 2 represents spark by 2 crossed quads, approach 3 represents one spark by multiple particles delimiting the sprak trajectory.

Approach 4 would be to use motion blur and let there fly just one light point - but this is little clumsy solution, so far #2 looks ok to me, although it does not fit to particles design.


Petr

[Simone]

Hi,



Approach #2> 2 poly Particle
Two crossed quads with spark texture - turned as they fall down.
They do not always face camera, look quite good.


Ok approach 2, sounds good for me, for physics we can use uniformly accelerated motion that use weight of particle multiplied by gravity force, and obviously we have to know the trajectory of particle.

I think that to do this approach we have to find a nice Texture.

Ciao,
Simone

[ErosOlmi]

I'm studying TBEM source code but it requires some time. It is a quite complex code to understand and follow.

In any case I think it is something related to timing when a new event is added and immediately supposed to be executed.
In my tests I've see that if all events are set to be repeated at intervals more than 100ms by TBEM_SetRepeat function, the 2/3 seconds of inactivity disappear but of course code is not so nice looking. I think that with intervals lower than 100ms GetTickCount has some problems in fast CPU. But, again, this seems visible only if the events to fire is supposed to be executed immediately after adding it into the queue. So some initialization param is failing or is inconsistent so TBEM_RUN enter in a temporary loop.

Still looking at the problem ....

[ErosOlmi]

OK, I've found the problem. Solution is easy from the script point of view but quite complex to solve from the module point of view.

I will start from the script change.
Every TBEM_ADDEVENT must have a starting time specified. So instead of:

eventParticleAdd = TBEM_AddEvent("Particle_Add", %evt_ParticleAdd)
change to

eventParticleAdd = TBEM_AddEvent("Particle_Add", %evt_ParticleAdd, gettickcount)

Without a starting time, TBEM event manager the very first time the event is fired will enter into a loop that can take a while to complete. The loop is

While @currEvent.starttime <= time
@currEvent.starttime = @currEvent.starttime + @currEvent.intervaltime
Wend
Because @currEvent.starttime will be ZERO at first, depending on @currEvent.intervaltime it can take a while to complete.

From the module point of view, I will comment later when I will have study more deeply TBEM source code.

Ciao
Eros

[Michael Hartlef]

ok, that should be easy to solve. When an event is created, I can set the time member to the current tickcount.

Still I don't understand why it takes that long on your computer and not on ours.

[ErosOlmi]

The reason is easy: you use GetTickCount (http://msdn.microsoft.com/en-us/library/ms724408(VS.85).aspx) function to set the timers.
That function retrieves the number of milliseconds since the computer was started. But because I usually do not switch off my laptop but put it always in suspended mode, my computer results to be started some days ago, so a lot of milliseconds ago.

Now, if your timer is set to zero and inside you WHILE/WEND you add 20 milliseconds each loop, to get my current GetTickCount it takes a while (how many milliseconds there are in 5/10 days?

So your idea to set a default starting time if no staring time is specified is good and should work in almost all cases. Anyhow remember that GetTickCount can return correct results up to 49.7 days as indicated in Microsoft documentation. This open some considerations when TBEM is used on machines that usually do not switch off like servers. For example in the company I work for some server are restarted every six months or so.

For the moment you idea of a starting time is perfect.
I'm still looking at your code to see how it can be possible to improve.

Ciao
Eros


PS: a little improvement in speed can be achieve in this way:
set funcName to ASCIIZ instead of string: funcName As Asciiz * 64
than when you need to pass it to "thinBasic_FunctionSimpleCall" do not use "Trim$(@currevent.funcName)" but just "@currevent.funcName"
this avoid thousands of TRIM$ calling because PowerBasic will just pass the name up to the NUL char. Also thinBasic internally is already making internal checking on it.

[Michael Hartlef]

Hi Eros,

try the attached version and let me know if it is better now. Which timer function woudl be better to use and also availabel in thinBasic?

Michael

[Michael Hartlef]

Further discussion about the timing in the TBEM module, please do it here:

http://community.thinbasic.com/index.php?topic=2178.0

[Michael Hartlef]

Simone and Petr, do you think that you guys can deliver the needed fucntionalities and an editor application till the end of the month?

[Petr Schreiber]

Hi Mike,

I know we are silent like ... something silent :), but I think the particles in form of include are realisable in form of include in scale needed for this project before October ends.
We will go the traditional way shown in my smoke demo and Simones rocket - that means textured particles changing position, color and scale during their life.


Petr

[Michael Hartlef]

How will the particles actually be implemented in the game?

[Petr Schreiber]

Do you mean how for what they will be used?

IF yes THEN
for marking vehicles which were hit ( it will harm visibility to drive behind such a "smoker", hehe ), for highlighting collision ( sparks ), to mark picking up powerups (?)
ELSE
I am not sure I understand the question :)
END IF


Petr

[Petr Schreiber]

Hi Mike,

now I read your other post so I get it - particle editor.

My idea is to have it like dialog with TBGL canvas.
You could switch between design mode ( set color to particles, change size, define forces, define spawn area, ... ) and test mode ( basically effect preview ).
For design mode I was thinking of some kind of time axis too.

I stop talking here, will try to bring preview in horizont of 2 weeks.

We are currently doing all the particle effects "by hand" to put it quickly together and see what will be needed, the editor will meet requirements discovered during this research phase.


Petr

[Michael Hartlef]

As you didn't mentioned a word about an editor, I was wondering how do you guys setup an effect. Like you said, there will be sparks, smoke, glows, etc etc. Will you use handedited effetc files, that will be loaded, or is everythign then hardcoded?

[Michael Hartlef]

Thanks, that will answer my question. :)

[kryton9]

I don't know where to post this but since it relates to editor(s) I will put it here.

Do you guys envision separate editors for each thing, track, fx, level, and models-- then to have them output text files that the program then uses to put it all together?
Or will it all eventually be done in one editor?

[Michael Hartlef]

I think several separate editors are easier to control and develop.

[Petr Schreiber]

Kent,

I am thinking of separate editors too.
As Mike said - easier to manage.


Petr

[kryton9]

It will be interesting to see what you guys come up with.