[DaBrain]

This might seem odd to you, as we already have similar feature, but glow points aren't suited for all tasks and are somewhat limited.

Why do our sprites/billboards always have to be squares?  
Depending on how you use them, you can cause serious overdraw problems. It's just a waste of performance.

This explains the problem pretty well:
http://www.humus.name/index.php?page=News&&start=40





Sometimes I want to use multiple planes as one camera-facing object. With glow points each of them would have to be one glow point, which is waste of CPU time for the addional draw calls.

Maybe I even want to have facing object instead of a plane, or use animated textures on it. That's not possible with glow points.


I'd like to be able turn a mesh into a facing object by adding the axis constraint type(s) into the custom properties of the mesh (in 3ds Max, or PCS2).


I hope I'm not asking for too much with this. In my eyes it would help to allow the artists to things nobody thought about so far, along with the option to optimize their stuff properly.


Well what do you guys think about it?

[Nighteyes]

I also thought about that, can be great for clouds, debris dust, small debris floating about, worm holes...

[mjn.mixael]

Would that help the nebula effect? (which IMO needs some work?)

[DaBrain]

I don't know.... I guess that would require more coder work. We can only define the nebua textures, not the actual meshes. (You are talking about full nebula effects, right?)

Well, they do produce overdraw. Maybe if we could optimize the shape around them (depending on the texture), we could reduce the overdraw a little bit. We might as well add a third 'layer' to it after optimizing it, to give it more depth.



Actually, I'm working on a script that will replace the current debris system... that's why I'm requesting this.

[DaBrain]

I suppose I could also try to match the orientation of the debris clouds to the player ship in the script. I just fear it would have to be updated so often, that things might become pretty slow.

[Nuke]

seems like you would have to preprocess lots of effects bitmaps, possibly on gameinit or with an external tool. you would probibly need a new file format to store the polygon verts. if the feature was made transparent where the game would generate model data based on the effect bitmaps and store them in the cache this wouldnt be a bad idea.

but this seems like it would work well in situations where you need fewer highly detailed particles where i kinda want the exact opposite (pointsprites).

[Mongoose]

So could a concept like this be used in any way to make the damaged-ship particle spew more efficient?  That's the one area of the game that always eats my framerate alive.  It's more difficult than it should be to aim at a ship filling half your screen when the game slows down every time you look straight at it.

[DaBrain]

Yes, I think what you describe is in fact an overdraw problem. With all the screen-filling particles, your gfx card hits it's fillrate limit.

[Nuke]

seems to me like this idea would work with the system we have in place now. i still wouldnt mind having a pointsprite system to complement the current system though, since they only use about 1/4 the memory bandwidth of quads, im not sure if that gets around overdraw issues though, but pointsprites are generally used for much smaller particles (usually < 64^2) and it might not be as much as a problem.