[The E]

Uhm. Yes. Of course there are. Look for the SCP badges. Dragon, despite his badge collection, is not a coder, and what he writes should be read with that in mind.

We are more than willing to work with you. If you can give us hints to improve our particle infrastructure, we're more than willing to listen.

[General Battuta]

Dragon isn't a coder or a member of the SCP, he's just an unaffiliated modder working on it on his own. I wouldn't draw conclusions about the SCP team from his approach.

[Dragon]

I'm just saying you that you may not need to work on a new particle code, I'd prefer to see shadows implemented first.
Of course, if I'll be unable to get the effect I want with existing code, I'll tell you about it. I'd just like to make sure you wouldn't be implementing a redundant system (and thus wasting time), since there's a possiblity that such effects can be achieved with what we have now.
There's a lot of other things from D2X-XL which FSO could use, for example shadows and collision avoidance for AI (which was rather good in D2, not so in FS2). If you're certain that a your new particle system won't be redundant, then go ahead.

[General Battuta]

Dragon, I think it would be best to let people work on what they want to work on.

[karx11erx]

Shadows are hard to add. Particles are easier.

As I think of it, adding just the particle code is only half the job though. D2X-XL has a halfway efficient transparency renderer that does back to front sorting on the fly, and that is what FSOpen would need, too. That's why it would have been helpful if you had some active OpenGL/graphics coder who knows how to insert such stuff.

Btw, rofl @ your remark about your post count, Battuta!

[karx11erx]

Ok, I think I will look into the entire OpenGL renderer stuff first, and adding particles would be a good approach to that task. Once I have been able to add particle rendering, adding more stuff shouldn't be that hard anymore. I will try to add deferred lighting plus shadow maps after that. Doing something about collision avoidance shouldn't be too hard, too.

[General Battuta]

i am such a smart cookie

If you can do even the smallest thing to improve the efficiency of the renderer you would basically be Jesus. I say this as a layman, but I've heard enough coder complaints to know it's a major bottleneck in the engine (along with collision detection).

[Dragon]

If particles are to be a start of the whole series of improvements, then I don't mind the modification ending up redundant, especially if it helps you with getting started with the engine.
There's a lot of things that could be ported from D2X-XL. I'd really like to see improved collision avoidance, which, as I said, is really good in D2. Robots can slide throught narrow hallways, make tight turns around corners, camp behind doors and walls, etc. FS2 AI just slams into anything that's in it's way, slams into player when forming up if it's flying a sufficently large bomber, slams into capships it's trying to launch from, etc. . It could use an improvement.
And of course, any efficency improvements to the renderer are really welcome.

[karx11erx]

I see the main problem with renderer performance in how model data is handed to the renderer. There is a very efficient way to handle this with OpenGL.

[The E]

If you can do even the smallest thing to improve the efficiency of the renderer you would basically be Jesus. I say this as a layman, but I've heard enough coder complaints to know it's a major bottleneck in the engine (along with collision detection).

It's not that bad, really. The problem is more that none of us have really grokked it, so adding the features we really want takes longer than it should.

If particles are to be a start of the whole series of improvements, then I don't mind the modification ending up redundant, especially if it helps you with getting started with the engine.

Dragon, learn some bloody patience. We will get what we get when we get it.

I see the main problem with renderer performance in how model data is handed to the renderer. There is a very efficient way to handle this with OpenGL.

Well, now this topic has deviated a lot from the original intent. Would you mind if we continued this discussion here?

[Dragon]

I see the main problem with renderer performance in how model data is handed to the renderer. There is a very efficient way to handle this with OpenGL.

If you could implement it without breaking backwards compatiblity, you'd most likely be considered an SCP demigod (do a similar thing with collision detection and you could become a full time one) 

Also, I indeed think that the discussion reached the point when splitting it and moving into SCP board could be a good idea.

[Sushi]

Doing something about collision avoidance shouldn't be too hard, too.

No, the tricky part about that is doing so in a backwards-compatible way without rewriting huge swaths of the AI code.

[Nuke]

If particles are to be a start of the whole series of improvements, then I don't mind the modification ending up redundant, especially if it helps you with getting started with the engine.
There's a lot of things that could be ported from D2X-XL. I'd really like to see improved collision avoidance, which, as I said, is really good in D2. Robots can slide throught narrow hallways, make tight turns around corners, camp behind doors and walls, etc. FS2 AI just slams into anything that's in it's way, slams into player when forming up if it's flying a sufficently large bomber, slams into capships it's trying to launch from, etc. . It could use an improvement.
And of course, any efficency improvements to the renderer are really welcome.

its likely he wont even need to touch the spewer code, sounds like he only needs to work with the render code, which should in no way affect the way particle spewers work from the modding side. of course faster particles would mean an increase to the particle limit which means more particles that could be generated, in turn meaning more things can have particle effects. even if the whole system ended up getting deprecated, it would still be worth it just having someone who knows their graphics around.

and (this is not directed specifically at you, but to anyone who could monkewrench this) frankly i dont want to see what happened last time karx11erx came here. i dont want to see hordes of seasoned modders acting like noobs and demanding cookies. show the man some respect this time and leave the code to the coders.

[Kolgena]

I say we let him do his thing, and wait to see what turns up. Since we don't really have anyone working on graphics code at this point, might as well let karx11erx try his hand.

[karx11erx]

I will of course make sure I won't break anything for the modders, or add proper modding support after new features are in place. No worries. I am not planning to take this project over and twist it any way I might like it. I strongly believe in teamwork.

Here's a taste of what would be possible: http://www.youtube.com/watch?v=DQYuhLC-GHY

[Reprobator]

I really like the smoking trail after the explosion of the main ship !

[Swifty]

Shadows are hard to add. Particles are easier.

As I think of it, adding just the particle code is only half the job though. D2X-XL has a halfway efficient transparency renderer that does back to front sorting on the fly, and that is what FSOpen would need, too. That's why it would have been helpful if you had some active OpenGL/graphics coder who knows how to insert such stuff.

I'm currently working on collision detection optimizations. I'm actually planning on working on the graphics pipeline after the collision code is no longer as big of a bottleneck in the engine. I'd say I'm pretty familiar with the graphics code and probably the closest there is to a "dedicated OpenGL coder" active on this team.

Deferred shading and lighting is something I was also investigating. FSO has framebuffer objects support which fulfills the G-buffer requirements of deferred rendering. I wasn't planning on going through with it until The_E produced his more robust materials system so that there won't be so much trauma in the hypothetical merge. It's something I definitely would like to tackle so any help with that would be obliged.

If you want to work on improving particle rendering, take a look in Particle/particles.cpp. The function you might want to look at in particle_render_all() which uses a geometry batcher to render all particles in batches that share the same texture using glDrawArrays. Our particles are currently just screen oriented unlit quads rendered using the fixed pipeline. It would be nice to have soft particles but our current materials system hasn't been extended to fireballs/particles yet. It would be nice if we had that more robust materials system The_E is working on.

[karx11erx]

Does the renderer sort transparent polys back-to-front already?

[Swifty]

Does the renderer sort transparent polys back-to-front already?

Kinda. We only sort stuff in the Objects array which includes fireballs but not particles.

[karx11erx]

Well, as I said: D2X-XL sorts transparent polys on the fly (no extra sorting), and that is something I would add to FS Open, too.