New Renderer (OpenGL 3.3)
-
I have replaced the two screens with ones where I have converted nearly all the textures. I think it helped the overall impression a bit more.
I’ve also added a third one where I noticed that it looks really nice.
The next step would be adding real shadows, but that’s a topic I better not talk about, since this means much more work as I have done for now. So no promises.
Hope you guys like it so far, as always I appreciate feedback so that I can get an impression what people like and what not. And I should really be doing something for university, really!
-
Dude, its awesome!
I know its hard to leave the modding when you bite so hard to finish that what is on your mind, but turn to Uni stuff. The FL can wait and will be always here!
BTW, Where is the limit for total upgrades that this game still can accept? :evil: -
Hehe, yeah it is hard. For me especially with graphics programming.
I think it looks quite good, too, but there still could be this and that and …
I guess the limit depends on the time you are willing to invest. I decided that I don’t want a long development time on it, so I won’t push it too far. Although with OpenGL I am not limited to this DX9, 10, 11 etc classification (even on Win XP you could use DX11 stuff if the driver supports it). Maybe I will use geometry shaders (DX10 stuff), but that is still out in the open. Would be optional anyway.
-
Hell yeah! I’m actually thinking that Open GL is the best. No limits!
By the way, with OpenGL, can you choose the texture filtering method?
-
Yes, of course you can set it
Would be a little bit weird if you could not. It is on a per texture basis, though. This includes anisotropic filtering.The texture filtering right now is already better than with the original d3d8 rendering path. I always force anisotropic filtering on driver level, so it is the mipmap filtering which is not identical. This is a topic I want to do some research on. The question is, whether it is API specific or not.
As for which API is better: If you don’t want to be dependent on the OS (like me), then there is no question. If you are a pure OOP fan (not like me), then you will most likely prefer DX (although that comes with a performance price, like Valve noticed with their D3D to OpenGL wrapper (the latter was still faster)). I am also hoping to get the rendering path faster (it already slightly is, but it is debug build plus nearly no optimizations). And of course there is the issue with the DX level restrictions, which I think is a huge disadvantage. ATM OpenGL 4.2. even supports slightly more than DX11.1 (but I think this is not really relevant). You could argue that the drivers for DX are more polished, but I think with more and more games having an OpenGL rendering path this is getting better and better (I never had any issues).
-
OpenGL is slower than DX but the quality is really better, I’ve just experienced this with Dolphin emulator, thin beams are really better rendered in Metroid Prime 2.
When I said texture filtering, I asked if you can use images upscaler like Genuine Fractal or S-Spline Max. It could make all textures have sharp edges.
-
Here are the numbers: http://blogs.valvesoftware.com/linux/faster-zombies/ A follow up on that article would be interesting, though.
For a real comparison, you have to make absolutely sure that you are rendering the same. So e.g. if you get different images you cant compare the fps.
The way you want to have textures filtered can only be done per shader and that is not a question whether DX or OpenGL. They are both just APIs for the same purpose with a different design philosophy.
Anyway, I think we are getting offtopic here.
-
Yes, for example the maximum number of lights and the maximum number of lights for shadow casting (if I implement shadows) should be configurable depending on your machine. I think I also will write a simple gui for it.
I am not going the deferred rendering way like Freeworlds did, so think of it like an upgrade of graphics for not so fast machines (since deferred rendering takes a lot memory and memory bandwidth). The number of lights will have a much greater performance impact, though (although you can do some clever optimizations).
It is still way to early to tell exactly how it will look in the end. And as stated above, I am currently focusing more an university stuff for a while.
-
Schmackbolzen, will you release some sources, so other advanced mod developers can supplement the stuff as they need to?
-
Not sure yet, but if I do I would want that everyone has to contribute their changes, so the license will be accordingly.
Also you really would have to convince me that there are people who could contribute. Otherwise it is more work for me without any gain
-
Schmackbolzen wrote:
I am not going the deferred rendering way like Freeworlds did, so think of it like an upgrade of graphics for not so fast machines (since deferred rendering takes a lot memory and memory bandwidth).
You’re saving yourselve a lot of headaches, that’s for sure. But even without deferred, you can do lots of awesome stuff as you already did, but I doubt the newest features of graphic cards are really needed (geometry shaders etc…).
FL doesn’t even use programmable shaders so that’s already a huge step forward.Good job!
-
Thanks! Yeah, I know that it is way more work and thus decided that more lights are not worth the hassle. With the shader power of modern hardware it should be possible to render more than the old 8 lights maximum anyway (FL only uses 2 in space!). Plus only newer graphics cards have enough memory and memory bandwidth to not take a large performance hit.
Geometry shader etc only would be for optimizations, I have seen some techniques using them for further speedup. So this again would be optional (on some older cards they even make it slower…).
Thanks also for separating the posts into two threads, with the number growing it really was necessary.
-
-
Nice video, but wrong topic
Unless you magically switched to OpenGL -
I know it has been some time (quite a lot actually), but I had some other stuff to do plus I put it aside for some time to get new ideas (which I got plenty of now).
Here are the newest screens where I tested the new automatically upscaled + filtered textures. I also changed the normalmaps so that it doesn’t look too much like plastic.
There is still some testing, bug fixing and optimization to do, but at least I got some ideas how to get around some problems. For now it runs on my AMD graphics chips and on my Intel hd4000 (which has one more bug I need to find).
-
Just to keep you guys updated: I am still working from time to time on this. Thanks to FF and the FTOW guys I now know what is being rendered (well, besides which lod level) and thus could include some basic shadow rending (although there are still some bugs).
Here is a screenshot:
And here a short video:
LinkKeep in mind that there is still work to be done. Ideally I don’t use simple filtered shadow maps so that the edges of the shadows don’t get so blurry. But before I use more complicated algorithms the rest has to work well enough
Edit:
I got a request for a video with a larger player ship:
Link -
You can actually fairly easily work around the LOD issue by giving Freelancer the wrong render information and adding a correction matrix to all SetTransform calls involving the world transform. The correction matrix would simply move the view from the player ship to the light.
The downside to this technique is that FL’s occlusion culling will prevent stuff behind the camera from rendering, so you have to render twice with rotated views and a ~180 deg FOV. This can get a bit expensive with cascaded shadow maps like Freeworlds uses.
