[Swifty]

As I continue working on the Freespace source code for my fourth year, the number of projects and requests I'm fulfilling has increased almost exponentially. I've had a couple of major features under my belt so far, namely TrackIR support, the HUD code rewrite, and soft particle rendering. I've also written several optimizations to the collision detection code which aren't as noticeable as the previously listed features.

But the question is, what am I working on now? In an effort to make Freespace engine development a bit more transparent, I've decided to make a comprehensive post detailing the current projects planned or underway by me.

Render HUD to Texture: Render to texture is currently a feature that's available using the scripting system. You can easily render pretty much anything to cockpit models and ship models using the Lua subsystem. However, a common request despite the availability of script-based render to texture is the capability to render-to-texture existing HUD gauges that have already been built into the code.

The HUD code has been rewritten to be flexible enough to feature this capability. And as a result, Diaspora is currently testing this feature using the DRADIS radar as shown in various video previews. The plan is to open this feature up to all HUD gauges and not just the DRADIS radar once it's definitively stable and ready.

More HUD layout features: I know it's a pain in the ass to build new HUD layouts and have to use a one size fits multiple resolutions dichotomy. It was really the best I can do while preserving the old method of using retail HUDs for differing resolutions. As a result, I've been thinking of instituting some better features and syntax. Users should be able to build more flexible layouts that take into account of relative positions (positioning a gauge relative to a proportionate sector of the screen) while also giving the option to always render HUD elements in it's native resolution rather than being scaled.

It'll be funny if I end up reinventing CSS without even realizing it.

Collision Detection Optimizations: This is a pretty big one. On top of that, it's also the most frustrating. At the moment I'm continually experimenting and playing with the collision detection and rendering code to see if there are any savings to be had with the engine.

Some collision detection changes I have already made is making sure ship submodel orientations are being set once per frame instead of per collision using Polymodel_instances. I've also made sure that submodel orientations are being calculated once per frame which reduces a lot of redundant calculations as a collision tries to propagate itself up the model tree.

I currently have in progress a build of Freespace which revamps the bookkeeping the engine does to keep track of pairwise collision relationships. The engine at the moment creates a data object for each potential collision and brute forces through them all to find out which ones are colliding. A solution I worked up is to gather all the endpoints of everything in the mission space, ships, lasers, beams, asteroids, debris, etc. I sort them first on the X-axis, do a pass to find any overlappers which are then sorted on the Y-axis and sorted for the third time on the Z-axis. Using quicksort, this broad phase does a fast job of eliminating all definitive non-colliding pairs in the mission space. As a result, the memory requirements have been reduced and we've now eliminated a bunch of excessive distance checks between all objects.

Another collision optimization in the works is the realignment of BSP nodes for models. I've been experimenting with storing BSP nodes in certain orders to improve cache performances. At the moment, the game stores BSP nodes depth first. I've been experimenting with storing BSP nodes breadth first which slightly improved the performance of doing model collision checks.

Rendering Optimizations: Rendering performance is something I'm struggling with as a member of the Diaspora Development team. Our art team produces some pretty demanding models which has prompted me to figure out technical solutions for these monstrous beasts. Valathil's upcoming shadowing implementation has me a tad worried about the potential impacts on performance as our assets are already demanding enough. But we'll see what happens once he's finished with it.

I've been playing with occlusion culling by trying to cull out non-visible subobjects using hardware supported occlusion queries. Not much luck there. My next move may be to implement a z-prepass on scene renders in order to reduce the number of overlapped pixels being worked on by the pixel shader. Another performance optimization being discussed lately is finding out ways to reduce the number of expensive texture switches done by the video card. Texture atlasing has been discussed along with merging common textures into one big 3D texture. So far, the method with the quickest implementation time would be sorting render calls by their texture ID so the texture switches are shared by multiple render calls.

Non-Photorealistic Rendering: This is probably my most anticipated thing I have planned. I've been reading a lot of interesting material on non-photorealistic rendering. Also known as toon shading or cel shading. With the glut of anime mods in the pipeline for Freespace and being probably the only coder for these anime mods ('Sup, Wings of Dawn?), I thought it would be nice to offer cartoon-ish visuals to complete the aesthetic these projects are trying to reproduce. Not only does this mean producing a different lighting model for objects (Likely just different SDR files that modders can drop into the effect folder) but also creating a good and coherent method for Freespace to create seamless outlines around depth and normal discontinuities so we can get a nice hand-drawn look. Valathil's shadows will excellently complement the cel lighting and will probably be a major key to convincingly pull this off.

-

I unfortunately don't have an ETA on all this stuff. It's a lot of work to do but I at least want to be held accountable for these features such that I don't get lazy and forget about them. There's so much I want to do for the engine but I figure I should get these out of the way first instead of flip flopping around the codebase and spreading myself thin.

[Rodo]

So the dradis video you guys uploaded a while back is made using the scripting system right?
I've been playing around with the hud table and I must say it was a good idea to code that, the hud looks so much better now that's hi-rez compatible.

Me be quite happy, thanks

[Commander Zane]

Oh my god Cell-Shading's coming back?
And double-thumbs up to the optimization changes, and Render to Texture.
Hell, thumbs up to the whole damn thread.

[Thaeris]

The days of MV-Cel shall come once more, only gooder this next time around.

[Dragon]

Wow. Can't wait for it, especially simpler RTT and optimizations.

[Bobboau]

a thought on the rendering things, it might be a good idea to separate out all of the code involved into modular components, this will make future endeavors of this nature easier, and eventually a materials system could be plugged in as a new rendering module.

[Valathil]

Show this man more appreciation. I'm doing the flashy eyecandy stuff everybody notices. He does the invisible grunt work that nonetheless is needed and is as awesome as my work!

[MatthTheGeek]

Soft particles do count as awesome eyecandy. But heh, it's your problem here. Stop stealing him all the glory !

[Valathil]

[Spoon]

I approve of this post a lot!
This gives a bit of insight on the less appreciated things being done behind the scenes like optimizations. Of course I'm also really interested in what kind of result the cell shading will produce 
I also like this line: "I at least want to be held accountable for these features such that I don't get lazy and forget about them"
It helps when you know which coder you need to ask when something is bugged somehow! 

[torc]

hey swifty a question:
The new HUD will allow us to animate it?
i was thinkin at this :

http://www.icosaedro.it/acm/download-hud.png

as you know the pitch ladder moves...it should be a good improvement 

[Swifty]

So the dradis video you guys uploaded a while back is made using the scripting system right?

No, that is all done by the HUD code. DRADIS is just a different radar type along with the standard and orb radars.

Show this man more appreciation. I'm doing the flashy eyecandy stuff everybody notices. He does the invisible grunt work that nonetheless is needed and is as awesome as my work!

Thanks, Vala. I've always wanted to work on graphics improvements but I never had the time because I would always fixate myself on optimizations, save for soft particle rendering. It's great having you around so I can focus more on performance stuff and frivolous stuff such as cel shading.

hey swifty a question:
The new HUD will allow us to animate it?
i was thinkin at this :

http://www.icosaedro.it/acm/download-hud.png

as you know the pitch ladder moves...it should be a good improvement 

Why do you need a pitch ladder if you don't even have a horizon in space?

In any case, the new HUD code allows us to create any gauge in the source code and allows us to use it using hud_gauges.tbl. So yes, we can theoretically make available a pitch ladder HUD gauge. There are some gauges I've created for Diaspora already using this framework but are still work in progress.

[MatthTheGeek]

Why do you need a pitch ladder if you don't even have a horizon in space?

FS mods are not necessarily about space, noob You most not forget atmospheric mods !

[torc]

Why do you need a pitch ladder if you don't even have a horizon in space?

FS mods are not necessarily about space, noob You most not forget atmospheric mods !

And simply because is... COOL!
Seriously,the pitch ladder not needs only for horizon, but gives you the feel of your roll and pitch speed,and,in space theorically,where many places are completely dark,this feature could help a lot.

plus,if the pitch ladder should be sincronized with a ship,this could help to bearing your fighter with the ship you targeting (for example,very useful in landing procedures with a capship)

[Darklord42]

A well "pitch ladder" needs some frame of reference from which to orientate.    I suppose you could have an orbiter style hud where its orientated to your forward movement, but that would only be important if you were orbiting something which isn't exactly useful in this engine. Especially where nothing operates on pure Newtonian physics.

[Ace]

Plus you can always have it be an arbitrary celestial grid based on a planet, or galactic plane, etc. (which FS wise would be based on the mission grid)

[Swifty]

However much of a good idea or bad idea a pitch ladder gauge will be, I'd rather we not derail this topic any further.

[Reprobator]

I'm greatly interested for the more  "modder" friendly rtt code

[headdie]

massive to the optimisations you are planning for the collision detection Swifty

[Nuke]

Render HUD to Texture: Render to texture is currently a feature that's available using the scripting system. You can easily render pretty much anything to cockpit models and ship models using the Lua subsystem. However, a common request despite the availability of script-based render to texture is the capability to render-to-texture existing HUD gauges that have already been built into the code.

The HUD code has been rewritten to be flexible enough to feature this capability. And as a result, Diaspora is currently testing this feature using the DRADIS radar as shown in various video previews. The plan is to open this feature up to all HUD gauges and not just the DRADIS radar once it's definitively stable and ready.

script level rtt is buggy as hell right now. granted it was pretty rock solid in 3.6.12, it had its quirks but for the most part it worked well. i managed to do several from-scratch hud and panel elements, entirely in scripting, and managed to apply them to ship geometry (old-skool cockpit submodel using show ship flag, as scripting access to cockpit modes was non-existant at the time). it worked well, had working radars and whatnot, and a system for animating subobjects within the cockpit model and elsewhere so you could have animated cockput controls and potentially others, such as control surfaces. i also had intended to make its features modder friendly so they could edit familiar tables to configure the script for their mod. of course at some point the rtt features of script just did not work with 3.6.13.

right now i think ive identified 2 distinct problems. one i believe is a geometry issue in my testbed models. when i converted models for use in my rtt heavy cockpit script, i didnt make models from scratch, i just used some of the cockpits already found in various nukemod ships. i essentially used pcs2 to insert a few polygons which were textured for the mfd panels i was using at the time. the mfd textures would be replaced with textures generated by the script. now this worked before 'go faster' builds came along and after that i had a whole bunch of issues with uv space banding. i found out that this had nothing to do with render to texture calls and 2d stuff worked fine. i think the problem had something to do with ibos (the effect is similar to the uv space corruption that happened recently in the nightly builds). to fix this id just have to work on the models abit more.

the second issue is probibly not relevant to to your hud system, but getting the renderFrame() call to work with a render target is really hard to make work. it kinda works right now, sometimes, but at what appears to be 1/4 the resolution (it kinda renders to the bottom left corner of the texture). some times it renders to the screen in an odd way, instead of into a texture. this is only useful if you want things in your cockpit like a simulated monitors, mirrors, etc.

i just want to bring this up, kind of a heads up on whats going on with the scripting side.

hey swifty a question:
The new HUD will allow us to animate it?
i was thinkin at this :

http://www.icosaedro.it/acm/download-hud.png

as you know the pitch ladder moves...it should be a good improvement 

scripting. learn it, know it, love it, and then use it for evil.

it does however bring up a good point. id like to some how make it so scripting and the hud system have some degree of interaction. i want to use scripting to create gauges. scripting gives you drawing primitives, capacity for bitmap rendering, some 3d rendering features, in addition to maths and access to game data. everything you need to come up with gauges just like the one in the picture there. problem with these scripted gauges, is that you pretty much treat it as a function to be called on the draw hud hook. it just draws on top of whatever was on the hud without regard to its layout. you could give the scripting access to some information about the hud layout, but it still requires scripting talent to get it to work with your mod.

instead what if i define the gauge with scripting, and place it with the hud layout system. so when it comes time to render that gauge, it runs a hook ($on hud gauge render: name of gauge). and when it does the script is passed layout data such as: resolution, size, color, Slew, etc. as an example, some time ago a modder wanted to use my attitude gauge from my atmospheric flight script. it shoulda been easy to hand it over, a table and some graphics. but i had to do a lot of cut and paste to make it standalone and then had to tweak it to look right on their hud at different resolutions. it would be nice if i can just say, "stick this in your mod folder and configure it in hud-gauges.tbl".  would also make it much much easier to render custom gauges to texture without having to have the script manage the render targets and texture replacement.