New Renderer (OpenGL 3.3)

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.

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

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:
Link

Keep 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

Well, my approach does not involve letting FL render for now. I keep a list on what is being rendered and update the positions before I render the list for shadows. Everything which is too far away is not added, so at least I will not get the lower LOD levels added. I also filter vertex and index data which is streamed. I hooked the function which is called when a CObject is destroyed to remove it from my list. And of course when index and vertex buffers get deleted these entries also get removed. There are still some glitches though, so for now it is not working 100%. And I will have to think about the streamed data, because planets etc. are missing for now. With this approach asteroids etc. also don’t cast any shadows (because I don’t get the CObjects from them). But at least the shadow rendering is very fast.

The problem regarding the matrices I asked you about was, that I had to multiply the modelview matrix from FL with a

1 0 0 0
0 1 0 0
0 0 -1 0
0 0 0 1

```matrix. After that I could get it to work.

So I got most of the glitches fixes, looking good so far. Here is a short video: Link

The short stutters come from running FL and the server on the same machine. The shadow flickering is due to a state change I did not find yet, but will be fixed at some point.

I think I am nearly ready to test some of the advanced shadow rendering techniques.

Thanks all!

@HeIIoween: The turret shadows actually were a bit tricky since FL renders them as part of the stations. But I guess since you noticed them the effort was worth it Currently the only problem is, that their shadows vanish when the turrets are out of sight.

@w0dk4: For now it is one PCF filtered shadow map. But since most of it works now the next step is exchanging it with a better technique. If I get PSSM shadows to work nicely I plan to use them.

Also planets still don’t cast shadows. I am not sure if this is so bad that I should invest time trying to solve it.