forums.ps2dev.org

[Ghoti]

Hi folks,

I am in doubt to what to use. I'm trying to build this particle engine and now I have to decide how to act next. I have this particle class which holds position, velocity, update function and thats it. Now I'm going to make the emitter. The problem is that this way i can create a render function inside the particle class and then call the render function N times but that is not the best way I guess (?). So i decided to retrieve the position per particle and store those in an array of vertices and then only call the render function once passed with N * 4 vertices in 1 array so that it fast?

Particle systems in 3D use triangles that are rotated to face the camera. How is this done the fastest? altering the vertices with sin and cos functions? or is there a better way of doing this?

hope that you guys can answer some questions.

greets ghoti
_________________
My PSP games:

Boxy II: http://www.ghoti.nl/boxyii.php
Elementals: http://www.ghoti.nl/Elementals.php

[flatmush]

I think that the easiest way is to use GU_SPRITES as they require only 2 verts and are always facing the camera so no maths is involved.

[Ghoti]

hmm but are GU_SPRITES not 2d instead of 3d?
and I still have to pass the rigth vertice info when used in 3d
_________________
My PSP games:

Boxy II: http://www.ghoti.nl/boxyii.php
Elementals: http://www.ghoti.nl/Elementals.php

[flatmush]

GU_SPRITES is only 2d if you specify GU_TRANSFORM_2D, just like triangles and lines it can also be 3d, but it just always faces the camera.

[Ghoti]

hmmm well here is what I do but it does not seem to work :S

[flatmush]

The gu get memory only allocates memory on the display list for this frame I believe, instead of using it in the constructor, use it at the top of the drawing code so that it gets the memory each time it draws.
sceGuGetMemory is not like a malloc routine.

[Ghoti]

Done that, but still not a particle rendered :s
_________________
My PSP games:

Boxy II: http://www.ghoti.nl/boxyii.php
Elementals: http://www.ghoti.nl/Elementals.php

[Raphael]

Why offset the .z values? If you use an identity view you'd need to offset the x and y coordinates to get a billboard. For any other view you'd need to get the up and right vectors and add/subtract those.
If you don't need the perspective projection, then just transform the vertices manually by your view matrix and use TRANSFORM_2D and offset x and y always (by pixels though).
_________________
<Don't push the river, it flows.>
http://wordpress.fx-world.org - my devblog
http://wiki.fx-world.org - VFPU documentation wiki
Alexander Berl

[tacoSunday]

GU_SPRITES are NOT automatically billboarded! You must do the alignment yourself. This seems to be most easily done when you are building your sprite array.

First you would extract your up and right vectors from the transform matrix after you have done your view transformations. I the example below the up and right vectors are combined into one up plus right vector

[Ghoti]

Hi folks,

@raphael: This may sound a little noobish but as far as I know I use an identity view and then translate and rotate it. just setting the x and y as offset did not work:

[tacoSunday]

Unless you are working in 2D you will need to set the depth( z ). As it is now you will never see the sprites because they on the same plane as your camera. This means in front of your near clipping plane.

[tacoSunday]

Just throwing this out there but you may want to build all of your particle sprites at one time and then just call sceGuDrawArray once. Also each call to sceGuGetMemory incurs overhead in the display list. Allocate all the memory you need for the particle systems sprites with one call to sceGuGetMemory(per frame of course). While having your particles take care of their own updating and sprite building is is redolent with the fumes of OO goodness, it is bad for performance. Remember that you are dealing with hundreds to thousands of particles each frame. The less baggage your particles lug around the better. If you insist on using c++ classes then I suggest that you restrict it to the particle system itself and the particle system manager if you make one. Let the particles themselves be as lean and mean as possible(ie just an array of structs). Anyways keep fighting the good fight!

P.S. If you want so see a working example (in c) let me know and I can e-mail it to you or something.

Edit: silly typo

[Raphael]

[Ghoti]

Hi again :)

here is what i have now:

[tacoSunday]

Hey there, I just took a quick glance at your code. Your transformation code definitely looks a bit wonky. Instead of building your matrices by hand and then multiplying them in, I suggest making use if the sceGum stacked matrix functions. They are much more straight forward. The procedure is generally as follows:

[Ghoti]

Hiya,

well I think it does matter because otherwise you can't rotate the camera around some point and only use a FPS kind of camera. anyway, my code is just to large to change this now, because everything is inverted, every little bit of code is inverted :s anyway, it should work the same only with some different things set. Can you take a look at the other code maybe, maybe you see something that I did wrong :s

greets ghoti
_________________
My PSP games:

Boxy II: http://www.ghoti.nl/boxyii.php
Elementals: http://www.ghoti.nl/Elementals.php

[tacoSunday]

What I meant was that it doesn't matter what order you define your MATRICES in, weather it be projection then model then view, or view then projection then model or whatever. The order of individual rotations and translations applied to these matrices certainly does matter as you say. If your code is too complex to change these things then you probably need to rethink how you are going about it.

I have taken the liberty of simplifying your setCamera method.

[Ghoti]

Well the camera settings I use is a camera that follows the player until a certain angle and then the camera halts and the player can rotate just a little more.

and the problem is, when I use this system I will have to change everywhere in my code that the objects really are at the position and not at the the negative position :s it is a little bit strange to explain.

but the view aside can there be something wrong with the code

I am thinking to do it just with trianglestrips, is this alot slower? (because of the use of sin and cos to rotate the strips to face the view or can I use the viewmatrix just as you describe ?
_________________
My PSP games:

Boxy II: http://www.ghoti.nl/boxyii.php
Elementals: http://www.ghoti.nl/Elementals.php

[tacoSunday]

It might be helpful if you tried to isolate your particle system from the rest of your code to make testing it easier. Assuming that you are using good programming practice, you should be able to take your particle system class and wire it up to a test stub. Have the stub try to build and render the particle system at a point you know is in the view frustum. This will enable you to determine if the issue is in the particle system or somewhere else like your camera transforms.

Alas, this may not be possible. In this case I suggest trying to render as simple GU_POINTS to determine if the particles are indeed where you expect them to be. If they are then try to render as GU_SPRITES with an arbitrary alignment and a solid color instead of a texture. If all goes well you should see your sprites, just not aligned to the view. Then try aligning them. You should keep enabling functionality until your code finally breaks. This will give you a much better idea of where to look for the problem.

I wish I could give you a more definite answer, but it is impossible from just looking at isolated chunks of code. As you say, the error could be totally unrelated to your transformation and alignment code. The only way to find out is logical deduction and process of elimination.

Best of luck.

[Smong]

[Ghoti]

Yess i know I now also do i-- so that it takes the new value at that point also but thanks for noticing, if you see anything else please let me know.
_________________
My PSP games:

Boxy II: http://www.ghoti.nl/boxyii.php
Elementals: http://www.ghoti.nl/Elementals.php

[Ghoti]

Hiya,

@tacoSunday: I have tried to alter the camera to the code you provided but It is no use :(, When I change it the camera functions no longer how it should. It does not follow the player anymore.

HEY i found something out... If I use 0.0f, 0.0f, 0.0f as the base position for the particlesystem then it renders it (using trianglestrips, not sprites) at the middle of the car, I render the car first and then I render the particles but with the particles I do not use any matrix multiplications so I GUESS it uses the one of my plane for it.

fixed it and now I have a trail :D:D:D

only thing to do is get it to face the camera all the time.

Since I use trianglestrips now to make a particle, how can i use the view matrix on the vertices now ?
_________________
My PSP games:

Boxy II: http://www.ghoti.nl/boxyii.php
Elementals: http://www.ghoti.nl/Elementals.php

[tacoSunday]

The procedure is the same, you just have more points to define now.

Adding the right and up vectors during extraction was an optimization for creating square centered GU_SPRITE's. A more generalized tristrip version follows.

[Vincent_M]

That code worked for me! Also, I noticed that when your particles' life is equal to 0 (I'm guessing false), you delete it from memory. Adding and deleting particles from memory is slow, and can fragment your ram up pretty good once done enough, which can cause it to be ungodly slower more and more with allocation errors after a while.

What I suggest is that you just don't render that particle when it's dead. If you decide to render the entire particle system all in one sceGuDrawArray() function call, you'll just want to move that dead particle from wherever it is in the linked list to the tail, and subtract 2 from the amount of vertices to render in sceGuDrawArray(). Still, your vertices must be in a vertex array too, so that may not work depending on how you implement it. You might want to adjust a few things, but all in all, it'll work out. If you don't need the particle system at all, however, just delete if from memory altogether in one shot (possibly on a separate thread). That way, you'll keep your framrate high and healthy. ;)

[Ghoti]

@tacoSunday: sprites work now also but very incorrect, I see color but that is everything. You said that the trianglestrip need to be called every time but when I do not i get this behaviour (with depth writing on):



It looks as if the quads are rendered without a problem ?

The view thing just won't do the trick. The resulting quad are rendered always in the same direction.

I can get them right by getting the angle of the camera and then rotating the vertices using that angle using sine and cosine however this is very slow and bad I guess ? With the viewmatrix thing you provided it just not faces the camera, I have tried setting a lot of different + and - in the vertices but the behaviour does not even change :s

I have printed out the matrix retrieved and the right parts are always the same, every frame, even when I translate and rotate the camera.

[Vincent_M]

I noticed a few things. First off, you only need to setup your projection matrix during your initialization before your game loop. You can still call it inside the game loop if you wanted to change the projection matrix for special effects though, but if not, you don't need to set it up anymore than once. That way, fixing that'll give you a speedup.

Also, are you drawing your billboards with GU_STRIP? You actually don't have to make them quads. You can speed up your code by using GU_SPRITE and transforming it in 3D. That way, you only need two vertices. Here's my code to render a billboard:

[tacoSunday]

Looks like Vincent_m has the right idea. I really think you need to go back to the drawing board and work out your transform matrices correctly. But just out of curiosity, what happens if you use the up and right vectors from your model matrix? If you are using your model matrix for both view and model transformations(witch I suspect since you say your up and right vectors never change even though your camera does), the view matrix probably wont help.

As far as optimization goes, Vincent is absolutely right about constantly allocating and freeing your particles. It's a bit tricky, but I use a modified ring buffer to keep rolling the pointer around a pool of particles. Another far less tricky method is to allocate a pool of particles, and track them in 2 linked lists. One for active particles, and one for dead particles. When you need new particles, pop them out of the dead list, and into the active list. When they die do the reverse.

Cheers.

[Ghoti]

Hi, IT WORKS !!!! the particles are now always facing the camera :) whiehieeee!!!

thank you guys for your help

Vincent_M: Yes I have set the projection now with the loading of the level and that works so that is some speed increase :D thanks for that. I'll look into the other optimizations also, thanks.

The sprites do not work as of yet but I will use the triangle strips instead and will look into the sprites sometime later on, now I want to continue with the game :)

@tacoSunday: Thank you for sticking to the thread and for the help !
_________________
My PSP games:

Boxy II: http://www.ghoti.nl/boxyii.php
Elementals: http://www.ghoti.nl/Elementals.php

[tacoSunday]

Glad to hear it. What finally did it?

[Vincent_M]

Can't wait to see this game in action!

Also, I don't want to beat this dead with a stick, but if you were wondering how GU_SPRITES works, you just have to take out the two middle vertices in your vertex array for every quad you draw.

For example, you have theses four vertices to make a quad: