New Renderer (OpenGL 3.3)
-
- 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.
-
Thanks! I don’t know if you’ve read my reply, but I solved the latter last Sunday: http://the-starport.net/freelancer/forum/viewtopic.php?post_id=62352#forumpost62352 From what I gathered it is a windows problem since I had the same low res textures with my wrapper. I added it to the Limit Breaking 101 wiki entry.
@Kazinsal: Not sure what you have in mind but not that you get any ideas: I won’t have the time and I don’t plan to write another wrapper
Also it will only work with Freelancer (I don’t translate every d3d8 call plus you need some hooks to get the textures etc.). -
I can tell you it’s not a Windows problem because our D3D9 implementation doesn’t have that issue. As far as I know, it’s a weird interaction between AMD GPUs and D3D8 games.
-
If you use my wrapper there are no d3d8 calls anymore and the problem still remained. So my conclusion was that it must be another problem, since it did not matter which maximum texture size I returned. I even found the return value while I was reversing FL and changing it in memory has no effect. But maybe we should continue this discussion in the other topic.
-
Schmackbolzen wrote:
@Kazinsal: Not sure what you have in mind but not that you get any ideas: I won’t have the time and I don’t plan to write another wrapper Also it will only work with Freelancer (I don’t translate every d3d8 call plus you need some hooks to get the textures etc.).Oh, no, not another engine. Something I’ve been thinking of proof-of-concepting in Freelancer. I can’t seem to tear myself away from this engine…
-
Hehe, I see. Well I am curios what people will do with it, once it is released. But it is still a long way until that
-
Here is a video of the current state: http://www.flnu.net/downloads/fl2603_q20.mp4
With the new knowledge from reverse engineering the rendering pipeline of FL I was able to render the starsphere into a cubemap und use that for environment mapping. I also experimented with different lighting models and added bicubic texture filtering.
At the end of the video you can see the scene with disabled environment mapping.
I still need to fix the calculation of the normal, tangent and binormal vectors which are stored in the models. This is the reason you see bad lighting at some locations.
If you have any suggestions, constructive criticism or already like the look let me know!
I still need to add a material system, change the shadow rendering technique, fix the remaining bugs and a lot more stuff.
Edit: Exchanged the video with a better encoded one.
-
That looks stunning mate! Really nice graphics, would make good in a mod
-
Thanks! I still am not quite satisfied with the look. We will see what I’ll come up with
Btw. here is the video encoded with h265: http://www.flnu.net/downloads/fl2603_x265q20.mkv I made it for testing purposes and it is less blurry.
-
Thanks!
So here is a video of the current state: http://www.flnu.net/downloads/fl0906.mp4This is a graphical level of which I think it is ready for release (minus the shadows! I definitely need to change the technique!). Lighting is about two third PBR plus a few tricks I used to make it work with the old FL lighting and materials including textures.
I recalculated all the normals and don’t weight in the original ones yet so the geometry is less round at some places. But all the wrong lighting is gone now.
What’s left is fixing more bugs, a material system, some optimizations and different shadows. If there is time I’ll try to render better planet atmospheres, but maybe that comes for later versions.
Also I have been working with .Nx from this thread to create better models and textures, but this will take some time.
At this point feedback would be helpful, negative and positive. Things you like and you don’t etc.
