[Nuke]

i was poking around the code and realized that of the vector and matrix math is done in software. i was looking at the possibility of using opengl to accelerate some of this. possibly something utilizing stream processors or the physx capabilities of some of the current generation gpus out there.  it could be possible to offload of the strain from the cpu. when freespace was originally developed, the power of the average gpu was kinda lax, so it made since to do some of this more complex math on the cpu to balence the load. but now that gpus are an order of magnitude more powerful, it makes more since to throw more math at the vid card. would make the engine more capable of doing things like supporting more turrets (faster math means less strain on the system) or making the games physics faster. what does everyone think of that?

[chief1983]

Is there any reason that impact spew particles lag the bejeezus out of the engine, even on high end hardware?  If that's related then go for it

Actually either way it sounds like a neat idea.  Perhaps having a higher reasonable weapon object count could be achieved too.  Lots of limits perhaps.

[Nuke]

yea it would also make particle creation faster, allowing for more particles and better effects

[WMCoolmon]

I did some reading (this actually has some relevance for a class project I'm doing right now). I turned up this paper and a whole bunch of other sites which all spoke favorably on the subject. It might be more efficient to try to load a whole bunch of data in, and then run a custom shader in order to computer it, rather than trying to do things piece-by-piece.

Note that this will really only be effectively possible if you decide to ditch every graphics API but OpenGL (ie assume DirectX is dead and will never be used in FSSCP again). I don't want to think about what would be involved in making something like this cross-API without nasty hacks. A test for now would be sufficient, with the option to enable it if it detects that shaders are enabled...

So I think it sounds good, and particles sound like an excellent place to start. They're relatively isolated from the main code, so you can get away with screwing around with their math routines and don't have to worry about bringing the values back in for AI and physics. I don't remember the code as being particularly huge and nasty either.

[FUBAR-BDHR]

First @WMC ow do you computer something?   

Would something like this help with the asteroid slowdowns and allow for additional beam weapons?  What are the benefits to multiplayer if any? 

[WMCoolmon]

Yes, best case scenario is that it could be applied to the physics code and reduce some of the load there. If you could actually make something do physics on the video card you might even be able to get rid of the model geometry in system memory, and just use the models on board the video card for collision detection.

Might being the operative word here.

I don't see any direct benefits to multiplayer in particular. It would allow for more time spent on compression, I guess, but it wouldn't let you send any less information between computers. And of course it'd give you a higher framerate if it were successful at getting the GPU and CPU to work together more efficiently.

On the downside you might have to do some extra work to account for the standalone, if it called any functions relevant to the physics, particle, or other code using GPU-enhanced math.

[phreak]

In addition to GPU particles, it may also be quicker to use point sprites instead of textured quads.  This way we just need to send over the center of the point along with it's size and which textures it uses and the GPU will generate the 4 points that represent the quad as well as their texture (as opposed to generating all that ourselves).

http://oss.sgi.com/projects/ogl-sample/registry/ARB/point_sprite.txt

[Aardwolf]

My computer does not support GLSL, and there are other people on HLP with the same lack of GLSL.

Take this into account

[chief1983]

They already said it would test to see if you have GLSL support.  They're not going to replace the software mode with a GLSL-only one.

[portej05]

I'm not quite sure how this is going to be achieved. Assuming you just want to do the matrix calculations on the GPU, don't forget that you've got to transfer the matrix to the GPU before you can operate on it - it might not be worth it.
I've seen particle systems implemented in shaders (but I have no idea how to do it) which can even take into account geometry.
I'm not sure. It's 2am here and I've just seen this thread. Ignore if needs be.

[Nuke]

i can see a system where particles are done as shaders or revert to the old way on lesser hardware. of course thise leads to other problems. the shader particles would probibly be faster so more can be used, but the same effect would be way too slow in software. so you would probably have to have 2 sets of particle spew parameters, one for software mode and one for hardware.

[Wanderer]

In addition to GPU particles, it may also be quicker to use point sprites instead of textured quads.  This way we just need to send over the center of the point along with it's size and which textures it uses and the GPU will generate the 4 points that represent the quad as well as their texture (as opposed to generating all that ourselves).

http://oss.sgi.com/projects/ogl-sample/registry/ARB/point_sprite.txt

Hmm.. Are those in Open GL 1.4 ?... i mean then most cards should be able to use them (though 2 seems to be the 'official minimum' it seems that cards with 1.4 support are able to run fs open).

At least some of these seem pretty nice (also in the code...) http://www.codesampler.com/oglsrc/oglsrc_6.htm

Wouldnt that move some of the load of from the cpu (not much as it only concerns particles but still...)?

[WMCoolmon]

I'm not quite sure how this is going to be achieved. Assuming you just want to do the matrix calculations on the GPU, don't forget that you've got to transfer the matrix to the GPU before you can operate on it - it might not be worth it.
I've seen particle systems implemented in shaders (but I have no idea how to do it) which can even take into account geometry.
I'm not sure. It's 2am here and I've just seen this thread. Ignore if needs be.

Would you have to transfer it back though? If you're working with something like particles, you don't need to have them interact with anything physical.

[portej05]

Would you have to transfer it back though? If you're working with something like particles, you don't need to have them interact with anything physical.

My shader/GPGPU knowledge is not working knowledge, so again, ignore/flame if necessary
If you wanted to implement a physics system on the GPU (such as the PhysX one), wouldn't you need the entire state of the physics system in the GPU?
Just using the GPU to offload some of the matrix calculations you'd still have to transfer matrices backwards and forwards, and your net result would be slower.

I saw somewhere a demo of particles done completely in shaders. It may have been on Gamasutra, but I'm not sure.

[Nuke]

really if the gpu is running the particle generation code then all youd really need to do is sent the parameters for generation. most of those parameters are not dynamic and wouldnt need to be sent every frame. all it needs to know is where and what velocity (though some of my new particle types need an orientation matrix) you really dont need to return anything back to the cpu since the game doesnt really need to know what they are doing.

the story would be different if you wanted intractable particles though. particles that can change velocity under certain conditions. i mean you could do stuff like while chasing bombs your ship flying through the particle stream could cause them to change trajectory and cause some cool effects. but i havent seen that in any other games. most ive seen is particles interacting to wind and gravity conditions which could be handled entirely on the gpu. just send the parameters, mainly a source vector and an acceleration vector (gravity may substitute an acceleration with a normal and an intensity value, as youd want to calculate falloff based on distance to the source).

again you really dont need to update all the parameters every frame, just they dynamic ones. and still its only really a few hundred bytes of data.

[Swifty]

Rendering particles and fireballs with point sprites is seriously a no-brainer. Reducing the number of vertices by a factor of four by just sending a series of individual vertex points instead of manually defining each vertex for textured quads is something that would speed up the game for everyone and not just people with programmable pipelined video cards.

[Nuke]

didnt somone try to do point sprite particles once before?
might have been with d3d though. was it bobboau?

[taylor]

didnt somone try to do point sprite particles once before?

I played around with it in 2007, but I dropped it since there are too many limitations with regards to point sprites and it wasn't possible to have everything work properly (min/max size issues, clipping off-screen, etc.).  I decided to just clean up the particle code a bit and rewrite Bobboau's grbactch code to have a few optimizations (such as using 4 verts rather than 6 like it he did it).  None of those changes ever hit trunk though, they are part of the Xt code base that didn't get committed.

[Nuke]

heh, well youre gonna love the damage i did to particle spews
on the bright side it will make the particle spew system more fun, useful and cool as well give us an excuse to make it go to the hardware. frankly the old weapons effects were getting, well, old.

up to 4 particle spew definitions per weapon (maybe more)
6 types of spew patterns (more as i think of them)
an offset so you can do multiple particle thrusters for missiles and stuff
a normal for directional spews (photon torpedoes ftw)

internally the pspew now has its own struct (i used beam sections as a template) and weapon_info has an array of that struct. im currently tying up loose ends and have to do a few more types but il probibly have a demo build and diff out by tomorrow id i dont have any major problems. too bad were in a code freeze

[chief1983]

(photon torpedoes ftw)

Sweet.