Soft Particles, Dynamic Lighting and DX9 wonderfulness in FW:ToW

TheDvDMan wrote:
Awsome! I saw it also in Crossfire.
BTW how is it done? With some C editing?

This has nothing to do with Crossfire. Crossfire does have lights on some weapon effects IIRC, however they are also bound to the old way of FL’s bugged lighting rendering system.

LancerSolurus wrote:
Excellent work indeed!

On a side note, could you post some of the articles you used to get the deferred rendering to work?

BTW, voted for this mod…

Hey LS,

actually I couldnt really find a “tutorial” like article about deferred rendering… I basically browsed through the internet and learned by doing.

http://www.gamedev.net/community/forums/topic.asp?topic_id=424979

http://www.gamedev.net/community/forums/mod/journal/journal.asp?jn=263350&reply_id=3432126

http://www.guerrilla-games.com/publications/dr_kz2_rsx_dev07.pdf

Looks you need to do some programming for it. But how you done this in FL w0dk4? You done some new render lib or made something like ENB?

Share the technology
I don’t like starwars, and would like to see this in common FL

The plugin will be released some time after FWToW is itself released. Then just about everyone will be free to include it in their own mod

And just so you understand the difference, this can run 1000 lights simultaneously (there’s no limit, but we’ve only tested up to about a thousand so far). FL, by default, can run 4.

FriendlyFire wrote:
The plugin will be released some time after FWToW is itself released. Then just about everyone will be free to include it in their own mod

And just so you understand the difference, this can run 1000 lights simultaneously (there’s no limit, but we’ve only tested up to about a thousand so far). FL, by default, can run 4.

plugin? Ahahaha, my guess is right!

FriendlyFire wrote:
The plugin will be released some time after FWToW is itself released. Then just about everyone will be free to include it in their own mod

And just so you understand the difference, this can run 1000 lights simultaneously (there’s no limit, but we’ve only tested up to about a thousand so far). FL, by default, can run 4.

To be a bit more precise, this can run infinite lights per object (or lets say, per pixel), whereas FL is restricted to 4

The other advantage is that no lights need to get culled, which is FL’s main problem: It culls lights not by distance, but rather by some other method, like first come, first serve. This results in bugged lighting quickly when there are more than 4 lights per object (i.e. on a Star Destroyer).

FF, how long we have to wait?

Nova wrote:
FF, how long we have to wait?

Twice as long as half the time until it’s released

Sorry

=\

Nice being able to see everything coming together a little at a time, what’s cool about this in particular, is that it also clearly demonstrates what’s missing from freelancer, things that I wouldn’t have been aware of without seeing this. I probably would have just played it after release and thought, wow, this looks different, but wouldn’t have been able to fathom why. You make a great team guys.

I have a question about the plugin that you might eventually release. When you say plugin, do you mean something that will just get dropped into the EXE folder and work with no necessary tweaking? As in it could just be applied to vanilla freelancer and make a noticeable difference like we see in your deferred lighting video.

if you want your particles to enlight surfaces, you need them to code like this. but the applying to the already present light sources should be just adding the plugin, triggering it via a configuration file and/or maybe some tiny hex edits.

That’s what I’m trying to establish, how much of what we see in the dev videos is to do with the effects that they are creating and how much is due to what will be the eventual plugin.

i.e - will freelancer look all that much different to what it already does in vanilla form with just the plugin.

as there are already lights and even dynamic lights in vanilla fl - yes, it will. however, if you want all your projectiles and missiles and flares and everything to emit light to nearby objects, you need to code it. it could even work with the fl you have now, problem is only, you have neither specular support nor will all lightnings show up or show up correctly.

What Gisteron said.

Different additions will mean different amounts of work. Bloom will work out of the box, obviously. Color correction needs per-system TGA gradient ramps created, so by default nothing would happen. Specular lighting is enabled by default, but for best result you will need to create your own specular map for all models (planets included). Soft particles need to be added manually on VisEffects. Dynamic lighting uses FL’s lightanims, so the few places where they are used will benefit from the new tech, but for the most part additional light sources would need to be added manually for the effect to really stand out.

Eventually, normal mapping will also require manual addition of your own normal maps.

FF wrote:
Color correction needs per-system TGA gradient ramps created

dear, FF, would you, please, explain what color correction is in this case and per-system TGA gradient ramps?

This page has all the info you’d need:
http://http.developer.nvidia.com/GPUGems/gpugems_ch22.html

Take these effects and apply them to systems.

Thanks for clearing that up, I had a feeling that it might be that way. Awesome for modders with knowledge of ALE’s and such then, but slightly less awesome for others. Awesome with the potential for sauce! :lol:

to be honest i don’t understand what you mean by “systems” nor any other way of applying it… just correcting the textures but the result would appear in vanilla FL then, too.