New Renderer (OpenGL 3.3)
-
Just had to step in to say that your work is awesome. Keep it up mate. I hope once you release the final version, other modders will work on it to improve it even further (if the renderer is capable of that, ofcourse). I wish you best of luck for your project. I hope we end up with graphics of FW:TOW but for vanilla. FF, wodk4, sizer and adoxa are helping you in it. That is how the FL community should be instead of modders having indifference and hostilities between them.
-
Thanks for the kind words!
I don’t think there are hostilities. FF helped me out with some offsets (e.g. shadows would not work otherwise) and all the .sur files of TOW should have been generated with my sur converter (if they did not change it).
My main issue is with the models and textures anyway. There are a few tough cases where the vanilla stuff did not age well. I hope there will be people who are willing to recreate the models and textures, but I am not too optimistic. At least mods can really improve their graphics, if they find the right models. I will probably write a new .cmp converter to make the conversion easier (no promises, but lots of code is already there).
-
Yeah, I was about to say, the biggest problem is that most of FL’s stuff aged poorly. The style was never great to begin with, but it doesn’t fare well when you try to upres it. You’d need to redesign it entirely with FL’s original style being more a spirit than anything else.
Also, you haven’t even broached planets yet, which are a completely different game. You can’t have modern looking models with FL’s crummy planets.
-
Not indifference between you and the FW:TOW team. I am talking about indifferences between other modders.
Anyway, I can help (I don’t know 3d modelling and texturing (though i am learning it, which is hard)). If there are is any misc work you can tell me and I am sure there isn’t a scarcity of talented people on the forums.
-
@FF: Yeah, for planets I have some ideas, but we will see whether it will work. It won’t be easy I guess.
@zebby: Sorry, then I misunderstood you. Also thanks for the offer. I think once I am far enough I might actually start asking for help and hope enough people respond. We will see
In the meantime for people who enjoy videos: Here is another one where I test exposure values for filmic tone mapping. I needed a GUI at this stage so now one also is included. Should come in handy I think. The tone mapping works surprisingly well for my taste (and others I have asked ;)). But I still need to apply it to the glow maps (windows etc) and effects, so they don’t use it yet.
-
Your last video was great, but left me with a few questions. Does it affect everything globally? i.e. asteroids, planets, etc. (the shadowing) Looks like you could do god rays if so. Have you imported anything with bump maps and spec maps? If so, how does it read them, meaning from the texture file. Did you have to make a different node for them in the mat file? How many light sources is the bump map affected by? Last, in the video at 0:05 when you dimmed it all the way down, can that been done just to the side facing away from the the light source, giving a realistic light effect? Just so only light maps are seen, not the stations textures.
-
Uh, that are a lot of questions and I am not sure whether I understood everything correctly.
First of all, I don’t do post-processing yet, but it will be included. That means the filmic tone mapping is then applied to the whole image (meaning exposure of zero results in a black image). And yes, god rays also are possible then, but with no atmosphere or a lot of small particles they don’t make much sense. But I can try to implement them if there is a demand.
For now the textures are not in the mat files, but lie in three folders. One for normal, one for height maps and one for the (modified) SSBumps. The textures are loaded by file names. If you load a diffuse texture I look in the folders whether there is one with the same name and load it, too. I can extend the amount of maps later depending on what artists want (specular, reflective etc).
Light sources are the ones FL uses, so in this scene it is two. I’ve seen FL using more, but I did not investigate where the limit is, yet.
For the last one I could try some sort of screen space reflections, but no promises.
-
FL’s limited by D3D8’s own 8 lights cap, so it should never go beyond that. You can add dynamic lights to stuff but FL’s buggy about that (w0d swore at it for months because of it).
-
Cool beans, but what I meant was does the shadowing affect everything? Like if your in front of a planet, asteroid, other ships, jump gate, etc.
And what I meant by directional lighting was this:
I’m guessing there is some kind of atmospheric lighting causing everything in system to be lit up on all sides, like this: (picture is big, so I linked it)
http://indus3.org/wp-content/uploads/2014/01/No-fog-vs-atmospheric-light-scattering.jpg
This was a good read, don’t know if you would be interested:
http://indus3.org/atmospheric-effects-in-games/#.V_pxgfkrKM8
-
Does opengl allow you to bypass the 8 light limit cap as Friendlyfire said that there is? How taxing is opengl on the game engine? i.e. stuttering, fps, etc? As for post processing, what kind of impact will that apply to the engine. From what I have seen in newer games it lowers the fps i.e. Guild Wars 2. With it on, it lowers fps, off the fps increase. Granted GW2 is poorly opitmized.
On a different note, does anyone else get this message when they try to make a post:
Invalid submission. You could have exceeded session time. Please re-submit or make a backup of your post and login to resubmit if necessary.
-
- The light cap was caused by the fixed-function pipeline, so the programmable shader pipeline Schmack uses doesn’t have that restriction. The game should attempt feeding the extra lights even if it couldn’t technically render them - you could see that in vanilla by attaching a bunch of lights to stuff, they’d flicker in and out because they’d get sent in a different order and D3D8 would stop at the 8th.
Only thing I’m not sure is if it caps the static LightSource lights to 8, since I’ve never had 8 such entries at once.
-
Post-processing is very lightweight. Anything you add will incur a cost in terms of performance, but that’s not where the big drain is.
-
You get that error message when you take too long to post.
EDIT: And to address your previous post (which btw, you should try to avoid double-posting, just edit the first post instead):
-
Unless Shmack did something weird (and I don’t see why he would’ve), all objects should be affected equally, so going behind a planet will block light, and objects in front of a planet will cast shadows onto the surface.
-
Directional lighting is like the most primitive thing you can have, so it’s pretty obviously going to be in. Now, since FL’s systems have an odd scale, you typically want to use a point light to represent the sun rather than a directional light (the parallel ray assumption doesn’t hold anymore).
-
The image you linked has what’s called participating media, i.e. fog. That’ll soften the scene and illuminate everything. It’s not particularly realistic to have that in space though, outside of nebulae.
-
Just thought I’ll let you know that I did not stop working on this. But I did not have much time due to university stuff, so not much happened since the last time. I started again a few days ago and made a lot of progress reversing stuff with the help of adoxa, FriendlyFire and the guys from FTOW. So now we know what models are being rendered plus some other stuff which hopefully will save me a lot of time.
I also fixed some rendering bugs and thought it looks really nice know. Here are some screenshots:
I am still months away from a release, so hopefully the images make up for that
-
It looks more classic. Love it
How about performance? -
Thanks! I am mostly way above 100fps, even with this quite instruction heavy shader. I did not use the optimized version of all the formulas yet, because I can only do that when the parameters are final. So I expect the worse cases to get better.
My only problem for now is dynamic asteroids, since the way FL renders them in d3d8 seems not to be OpenGL friendly (or I have a bug there somewhere). But since now I know when they are being rendered I plan to use instancing so you wont notice a fps hit. But you’d need a dx10 (and OpenGL 3.3) capable graphics card for that. So for the old ones I’ll try a different optimization.
-
This is really cool. This reminds me of what ichiru is doing. He is currently rewriting the entire of FL to use the OpenGL engine if I’m not mistaken.
https://github.com/CallumDev/Librelancer/
If I may, how does this actually work? I’m assuming that this is still basegame freelancer.
-
Yeah, I know what he is doing. But it is not so much comparable as he has way more work to do than I have (even though what I have to do is a lot).
Basically I create an own d3d8.dll which wraps every call from FL to d3d8 and translates it to OpenGL. I chose OpenGL because I am not a DirectX fan plus you don’t have that restrictions of the specific DirectX version. I can just mix e.g. OpenGL 4.5 ( which is dx11 equivalent) with the old fixed function pipeline from the 90s and don’t have to worry about the version. The graphics card only needs to support it. This saves me a lot of trouble.
There is also injecting own code into FL done to get the texture names, model names etc.
-
Oh cool. So you’re pretty much telling the game to change how it renders objects altogether?
-
Yes plus I am also adding new stuff which is being rendered. Otherwise you would not see a difference.
-
Very interesting project. Spectacular results so far as well applied to vanilla Freelancer. I’m not much of a graphics programmer but I would be very interested in it and its internals for a project I’ve had floating around the back of my head for a while, and I’m sure it would absolutely shine with something designed around it.
