Hello,
A friend of mine told me that rendering objects used for particles is much faster if they’re rendered to an off screen buffer first.
Just wonder if this was true or not. It does seem like object based particles take up a lot of the pixel fill rate, even if those objects and textures are very minimum in number and data size.
If the offscreen buffer has a lower resolution than main window it’s far faster in my case. I’ve put a code for this in code snippet you may try it.
If the offscreen buffer has a lower resolution than main window it’s far faster in my case. I’ve put a code for this in code snippet you may try it.
(Delete this message please)
If the offscreen buffer has a lower resolution than main window it’s far faster in my case. I’ve put a code for this in code snippet you may try it.
(Delete this message please).
I figured out how to render and off screen buffer (render to texture), but how would you get the results of that off screen to combine with the actual game window?
That’s where I’m stuck.
Oh, and I don’t no how to make a particle object render to the off screen only. Having it render to the main window and the off screen defeats the purpose. Haven’t solved that either.
Have a look at the snippet code [url]WIP - Fast offscreen soft particles], I didn’t success to get soft particles but it’s working with a simple z-test.
You need one dedicated buffer + camera for the particles and hide them from the main rendering camera.
You need one dedicate buffer & camera for your objects/scene and hide it from the particles camera.
You must have 4 textures :
postimage.org/image/2l1aghlno/
Then you combine them in a compositing shader.
It may be overkill but I didn’t find simpler way to do it in Panda.
What is the cause of fps drop is the overdraw caused by the alpha of the particles textures in front of each other, I think you’ll get this in all engines.
That is interesting. I did a test with particle objects that didn’t have alpha at all, nor a texture (just small geometry and material color). The FPS I experienced was even worst.
I’m guessing that was due to the fact some graphic cards are bad at handling small pieces of “free floating” geometry.
I’m guessing using Panda’s built in Particle system would have the same issues.
“object” based particles are indeed very expensive. But this has nothing to do with fill rate, and rendering them offscreen won’t help you.
Object based particles are expensive because they are implemented by replicating the geometry n times, once for each particle. This means that you will have at a minimum one Geom for each particle. So if you have only 1,000 particles onscreen, that means 1,000 Geoms, which is way more than you want to have for decent performance.
Sprite- and point-particles are much cheaper because you can have many particles within a single Geom. Usually people use sprite particles to achieve most particle effects.
If you really want to have object-based particles with many particles onscreen at once, you will have to use something like hardware instancing, which is tricky to set up and isn’t directly supported by Panda’s particle system.
David
I actaully figured out it was the total number being created. I turned off the alpha component and realized that the textures with alpha wasn’t the problem. I then create a particle with less vertices and tried it and not much change there either.
The only other thing left was to create less particles and that work! The effect don’t look as good as it did with the higher instance count, but it doesn’t look horrible either. Still fairly nice.
I guess I should run Pstats and look at my Genom count. I bet it’ll be high, because my particle model has a fair amount of vertices in it for a particle.
Geom count is not related to number of vertices in your model.
A Geom is a collection of triangles within a model that share a common state. A single Geom can include any number of vertices; it might be three, or it might be three million. Some models consist of a single Geom (if there is only one texture over the whole model); some more complex models may have dozens of Geoms.
It’s important in a 3-D scene to keep the Geom count down to the low hundreds if you want to keep good performance. That is sometimes quite challenging to achieve, mainly because interesting scenes have lots of different objects with different state, and that tends to mean lots of Geoms. (But again, to reiterate, the number of vertices really doesn’t have much to do with the number of Geoms. You can have millions of vertices in only a handful of Geoms. But if you do, you probably won’t be able to control them individually.)
The “object” particle render mode is a terrible mode for performance because it simply replicates the model (and each of its Geoms) once for each particle. Performance goes in the trash.
David
So, if a model is multi textured, it will have more than one geom count? Sounds like a Geom is a single state of a model, rather it’s a texture or group of vertices.
I’m using a task to create particle objects. Didn’t know there was a mode for that. I’ll stick with the task since my frame rate breaks from 60, but stays above 50. Sounds like Panda’s mode you mentioned is horrible.
I’m thinking I should try a re-use method with my particle objects. That is, create a few of them and use them over and over as if there was an unlimited amount of them creating and destroying. At least that way, the data will not create, destroy and create again, over and over.
That might be worth a shot.
You might do well to take advantage of Panda’s RigidBodyCombiner, whose purpose is to combine multiple independently-moving objects into a single Geom (or a small handful of Geoms). It works even if you are moving the objects with a task. It can improve frame rate if you have many objects but each object has relatively few vertices. (Since you say your object has a “fair” amount of vertices, it may or may not be a win in your case. But it’s probably worth a try.)
Search the forums for more information and examples, and also check the API reference.
David
My theory work! The problem was what I thought it was; it was the fact I was creating and destroying resources on the fly.
Instead, I created a pre-buff of particle objects so to say. For each object that would create the particles, I assigned 25 pre-loaded particle objects.
What I did was revive the particles as they died out, so that I was reusing the same particles instead of creating new ones.
My frame rate was back to normal with the particle objects splashing around. I decided to test my higher geometry particle object, which looks better, with the new code.
The frame rate kept its ground even with the higher geometry particle objects. At least now I have some code I can use for particles later, if I decide to design an application with this graphics engine.
If an object that creates the particles is destroyed, I would destroy all of its particle objects at that time.
Great news!
You may find tools such as PStats useful to help you diagnose performance bottlenecks such as this before you begin. I find it helpful to know precisely where the bottlenecks actually lie before I start to rewrite code. 
David
I don’t see how I could of solved this with Pstats, but I do use Pstats for other things. I find using the process of elimination better for solving issues, unless you already know you’re dealing with something really engine specific, like its graphic memory or caches.
My problem was just a matter of finding out if it was alpha, geometry or instance count causing the fps drop. It was instance count. Which I had a gut feeling from the start it was just that, but wanted to rule out any other possibilities.
Oh well, at least I have the foundation code for creating a ton of particle effects at no real cost to your fps; but that depends on how many objects are going to create particles at one time. I guess one can over do anything if they’re not careful.
I had this one question I wanted to ask about the P3D engine, but it slipped my mind. “Bummer.”
My friend is telling me to go with the Inrich Engine or however it’s spelled, but the documents on this one aren’t bad.
I do have this question - What lens perspective is better for a game? Perspective or Ortho? I’m guessing P3D is in Ortho by default.
After looking in the manual, it appears P3D is default to perspective lens. That was a surprise, because I manually set the lens to perspective and got a crazy view result when running my small app.
Perspective does make things appear more three D, but not in the way I saw it. I’ll just stick with the default cam until I can study up on the different lens settings this engine has.