New Renderer (OpenGL 3.3)
-
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.
-
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.
-
Super! Even with turret animation
Now it is more atmospheric with shadows, etc.! -
very well done
-
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.
-
Personally I find planet shadows to be extremely important, but I don’t rasterize them because sharp edges look bad on them. Instead, I raytrace the shadows as a final step to the shadow buffer (I buffer the shadows so I can use temporal shadow filtering), which allows me to smooth them out at the edges. No flickering, no aliasing, they look great and honestly run very quickly.
-
Yes, spheres are easy to ray trace and the shadows will look great then, that is for sure.
For now I just generate a polygonal sphere which I scale for each planet so I don’t have to generate more than one. If I subdivide it enough it should not look to bad. In my tests it does work on the player ship for all of the planets. I have yet to find a system where a planet actually casts a shadow on a station, as this seems to be very rare in FL.
Long story short: Shadows for planets now work, too
-
Here are some nice screens I took while testing (click on the images for a large version):
This will be the last for a while as I need to find the remaining bugs and also try to use a better shadow rendering technique.
Feedback is always welcome!
-
Thanks!
It was actually surprisingly easy to enable shadows for the second light source FL uses. So I replaced three of the screenshots with new ones in my post above (the ones without statistics in the upper left corner). I was expecting it to be unstable, since FL switches between the light sources rather often, but so far it seems to work very well and looks really good for my taste. -
So how far away would you say you are from release, or is this going to be kept under wraps with the excuse of ‘polish’ until Freelancer really has kicked the bucket?
I’m not a coder and I take a lot of flak for that, apparently not understanding the hard work that people put into this sort of thing and how its their decision to do what they like with it.
Buuuut as an artist, it pains me to see technology like this which could extend Freelancer’s life expectancy and make my work look ten thousand times better kept behind lock and key because nobody wants to help anyone out.
-
Well, currently the plan is to release it first exclusively for a mod update of our mod, but to open it up for all after some months. Basically I want this to be one basic feature of the update plus it is easier to find bugs if I know the environment it is tested in.
The plan is not to keep it under wraps, so that everyone can use it (else all the work would be for nothing), but I see it happening more like next year. It all depends on how well things go. Keep in mind that I still have not fixed everything (although I am getting closer now).
As an artist, are there any specific details you don’t like in the screenshots / videos (except the weird white stripe reflections from which I think I know where they come from)?
-
Thanks for the quick response. My problem isn’t so much with the rendering as it is with the textures themselves. FL’s textures were never intended to be normal mapped and while it works great on some, others look far too noisy/bumpy and should probably be redone for a project like this.
Also, if there’s any way I can help do let me know, I think its in everyone’s best interest to get this out sooner rather than later.
-
Thanks for the offer! I have been thinking and actually it would save me a lot of time if someone could create all the normal and heightmaps for the vanilla textures. For now the vanilla textures are automatically upscaled and filtered with a program I wrote. I had to create the height maps myself, which took some time and only include a few for now. The normal maps are generated from the textures. My intention was to approximate the maps with some algorithms when the rest of the OpenGL wrapper is working.
I understand if you don’t want them first used by our mod, but if they would be ready for a public release this would also help me a lot.
-
Looking so Awesome, please Release it ASAP i cant wait to play Freelancer again
-
Hehe, thanks!
But you have to be patient. I don’t have the time to work full time on this. On the positive side I was able to fix one major issue today:
Before:
After:
This was not so easy because I needed to duplicate vertices and this is tricky with the model format FL has. I also still need to fine tune the algorithm which generates the tbn data (those of you who now tangent space will know what I mean). But at least those weird white stripes are gone.Issues like that are the reason why this will still take months to be in a state where I can release it. It is of no use if you fly through FL with weird graphical artefacts and flickering. Breaks the atmosphere. I hope you can understand my reasoning