Geometry vs Transparency

General Discussion
1

I was creating some special effect objects with some cheap geometry and textures with alpha. All my effects worked with the frame rate accept for my last one. It involved two objects with two alpha textures over lapping because the objects were together as one.

I remade the effect with all geometry, which created a higher vertice count, but the all geometry effect was much faster than the original that used alpha. In fact, the two or three fps that drops from the effect is probably caused by the loading and destroying of resources on the fly, which is almost unavoidable when making effects.

Are all geometry effects with no alpha faster than an effect that uses less geometry and alpha textures.

or

Is it the fact alpha that overlaps is an fps drinker? So modern day graphic cards are not handling transparency any better?

2

The answer is, it depends. Sometimes alpha is faster, sometimes a higher vertex count is faster. It depends on the nature of the scene, the particular graphics card you are using, and a hundred different other things.

But it’s not usually going to be a big difference one way or the other–in most cases, I’d be surprised if it’s even noticeable at all. You’d really have to go out of your way to contrive a situation where either the vertex count or the extra pixel fill made an appreciable difference to your performance.

But there are all sorts of secondary things that are more likely to make a difference to your performance–the number of Geoms, the number of individual RenderStates, the number of Texture objects; all of these are going to have a bigger effect on your performance than simply more vertices vs. alpha transparency.

You don’t give any specifics about your tests, but I’d be willing to bet you’re mainly measuring the effect of these secondary things.

David

3

This test was done to see how the fps would react if I created and Actor that caused an effect to happen over and over, like a projectile being shot across an environment.

The all Vertice Model is around 1.5K vertices. The textured model is way less in vertices, but use texture with alpha channels.

The Class that creates the effect will pull from the hard drive, the object used for the effect, create any other nodes like material nodes and set in motion any tasks that animate the effect. The effects dies once a duration is reached and destroys.

The No Alpha effect rotates and repositions in every frame. It only uses Material, no texture.

I don’t know if P3D stores a copy of objects when they are first used, so that it doesn’t have to keep pulling from the hard drive.

The All geometry model did out perform the alpha model (of the effect), but that was only with one character on screen, the Actor that was creating the effect.

Once I spawned three more models, I witnessed a frame rate drop again.

At the moment, I have no idea of how to have effects without dropping the frame rate. If the fps drop is do to the re-pulling of data from the hard drive of every new instance, then I could probably create a few instances of the effect and cycle them, but I don’t know if hard drive reading is the cause of the fps drop.

I’m completely lost at the moment. Tomorrow, I might try cycling through a few instances of an effect that were pre-created, to avoid the reloading of an object from hard drive in every instance creation.

Keep in mind, every instance dumps its data once the duration is up and it destroys itself.

4

OMG!!! It was Alpha!!!

And the problem was another effect. I didn’t notice this before, because all the effects my Actor generates triggers a base effect, and that base effect causes the Actor’s hands to start bursting with energy before the cast.

That hand energy effect uses textures with alpha. I disabled that effect and ran a test on all my other effects as normal. That hand energy effect was the cause of the fps drop.

So I guess I’ll have to make that hand energy effect an all geometry effect. I believe alpha is worst with Alpha on Alpha. I’m going to change my backdrop as well. The environment backdrop uses an alpha texture, but I’m going to turn it into a flat Geometry backdrop instead.

I’m curious to see if I gain even more fps by eliminating the backdrop alpha.

Transparency is a game killer!

My graphic card is obvious kicking butt, the way it’s handling the geometry. P3D’s App and Cull side of things worries me.

5

I’m still not convinced you’ve correctly identified the actual culprit. Alpha transparency, by itself, doesn’t generally cause a measurable performance hit. But there are other things that might that could be tangentially related.

David

6

So far everything is back to normal (if normal). I kept the code the same. The only thing I did was change the objects that used alpha to objects that did not need alpha.

The only strange thing is the fact, fps did not rise or fall when I removed alpha from my backdrop. Then again, that backdrop is far off from the actual area where the characters are. My game level is on a larger scale (instead of the usual scaling down of a level to the tiny state and setting the camera fov to something like 30. Which is why I can’t use shadows).

I don’t know if Alpha has a worst effect on performance if it’s up close vs far away. That’s several times now Alpha has hit my fps hard.

I also found out (the hard way) flattenStrong() should not be called on any objects what will undergo a state change like texture swapping or animated vertices. Performance will drop. fStrong() will work with static objects and objects that will only scale, rotate or reposition.

My big concern now is my collision volume. Pstats is showing a super large collision volume. All my collision poly objects are not even attached to render and the ones that are attached, are cheap (INTO objs).

I builded a collision level as I designed the game level, with the colllision level just being cheap barriers. I’m using the collision HQ for collision handling.

It seems like P3D is trying to test every barrier for collision even if it’s not in the scene graph. If I’m losing a lot of performance from anywhere, I would guess it’s collision related, given how large my collision volume is.

Now I’m wondering; do I have to explicitly remove and re-submit collision barriers from the Trav as needed? The only problem is, objects that are not FROM objects will automatically get checked (as an INTO object). I wondering if this is going on even with the INTO objects being detached from the scene?