New Renderer (OpenGL 3.3)
-
@eigos: They just lie in a folder and if the texture from a mat file is being loaded has a file with the same filename in it (e.g. “STADTL1_256.tga.dds” ) this one is loaded. Same applies to normal and ambient occlusion maps plus any future maps I might add (each have an own folder). I don’t know which material is being used, yet.
Actually I am quite surprised how well it looks now. Had some small ideas and the combination of them plus some rendering fixes really work well. E.g. I was not expecting how well it works here (apart from the rocks): http://www.flnu.net/downloads/fl1510.png
Today I finally was able to fix the fake lights in nebulas (fog did not work), so here is a video: http://www.flnu.net/downloads/fl1510neb.mp4
There is still some work left, but we are getting closer
-
Just boring stuff. Tested window management and OpenGL context creation with SDL2, but sadly the event processing breaks the controls. Plus it does not fix the wrong resolution in fullscreen mode (since FL manages the window, something seems to break there). Also I had to patch SDL2 to make it use an existing window with OpenGL.
I also did some further clean up and optimizations. On my NV 970m it is now nearly about 1,5 times faster as the original d3d8 renderer (with disabled shadows), but on my AMD RX480 the d3d8 renderer is faster. So either a driver problem or I am doing something wrong / something the driver does not like. Not much left I can do, though, since I have not that much control about how FL renders things. Sadly weapons fire also seems to impact FPS (on AMD). This is something I need to investigate further. I tested the newer OpenGL debug callback functionality, but neither on AMD nor on NV this helped.
Shadows also seem to impact the FPS a lot, but not when generating the maps, but when using them in the shaders. So I’ll have to investigate whether this is normal or not. Could be a fillrate problem, though. The scenes I am testing with have a lot of overdraw, since FL renders back to front and there a hundreds of objects. A z-prepass could help here.
I also have been working on getting the TB vectors generated like presented here: http://crytek.com/cryengine/presentations/triangle-mesh-tangent-space-calculation (there is existing c++ code but I need to adapt it to the UTF Editor code in c#).
As you can see, nothing of interest for the normal user (who doesn’t understand anything of the above anyway). I will post progress here when I have to show something new
-
Schmackbolzen wrote:
I also have been working on getting the TB vectors generated like presented here: http://crytek.com/cryengine/presentations/triangle-mesh-tangent-space-calculation (there is existing c++ code but I need to adapt it to the UTF Editor code in c#).
As you can see, nothing of interest for the normal user (who doesn’t understand anything of the above anyway). I will post progress here when I have to show something new
Maybe you find this interesting: http://forge.the-starport.net/projects/utfeditor/repository/revisions/35/diff/UTFEditor/UTFForm.cs
(we also had to add tangent/binormal data for our normal maps etc. in Freeworlds)Or do you use the tangent data as provided by the UTF editor? Is it faulty?
-
Sry, I am again very busy due to university and my student job.
@Wodka: Yes, this implementation produces wrong TBN data. I have modified it locally and also added code so that new vertices can be inserted. Currently I recalculate all normals and duplicate vertices in case the angle between the normals is too large. But this is only a stopgap measure until I can convert the code I linked above, since there are still case where the TBN data is wrong. Plus everything looks very edged right now since the original normals were smoothed a lot. Maybe I also should have a look at your MAX plugin in case you have used a better algorithm there.
I hope that I can get a public beta test running after I had some time off during the upcoming holidays, but no promises. It will only work on our New Universe server so you would have to check out our mod. I’ll probably use the current ugly shadow implementation, but at least you could test it out. We will see…
-
You’d have to detail what’s wrong about it because it’s been in use with FW for years now without any issue whatsoever.
-
You can read about that in the linked presentation. Also I only tested the UTF version. Wodka once wrote to me that you don’t use that. As far as I remember there also was problem with references in the vector maths and thus wrong results. But since you don’t use it anyway I never committed it.
-
We’ve used both actually. New models use the 3ds Max exporter, but older ones were just upgraded through the UTF ed. I haven’t noticed errors with either.
-
It highly depends on the model (vertices and texture coordinates). Unfortunately FL has a lot which don’t go well with it
-
I have skipped them and worked on my master thesis instead since it takes days of calculations to test all the parameters for the evaluation and thus needed to finish the code for every test I need to do as soon as possible. It is looking good right now, but you never know what is coming next
Btw. you don’t need to ask all the time. If I don’t post I did not make enough progress (as I wrote before). I need to find the remaining bugs (e.g. fullscreen does not work correctly) and you never know how much time that will cost. I have done some small things (like using much better dds compression for the textures), but you won’t see that in a video.
-
Just dont forget to get some rest in between
-
Hey ! I did a render in xNormal and I wish some feedbacks.
Here are some pictures :
-
My question is where so I pick up the software? Groups I worked with in the past (2008-9) fell flat trying to get a .dds DXT5 implementation into the FL engine for at least some normals mapping. And your renders look good. Can you change the lighting angle a bit more oblique to show the height variation a bit more? Also does it stand up w\ lod distances? I’d shoot someone to get normal mapped textures on my ships. Whatever you’re doing is getting close. There are other people doing normals on other threads, but I think they’re running down the same paths that dead ended when the output worked only on a certain class of graphics card.
So again, what software and where do I filch it?
And is it on implemented in the modeler or through the graphics? -
There’s no “software”. Schmack created an OpenGL implementation himself, from scratch, which hooks into Freelancer and replaces the renderer in large part. All you do is feed the game the new textures it’ll need and that’s it, provided you have the renderer.
There are only two such implementations right now: his, and Freeworlds’. Neither are currently released for other modders to use, though Freeworlds is already out there to play with.
-
I don’t use Freelancer engine and open GL wrapper, I rather use xNormal, because I can’t use the wrapper. I give the textures to Schmakbolzen and he makes the adjustments.
You can find xNormal here : http://www.xnormal.net/
I put other screenshots as you wished.
-
Really that’s what I thought FF. Been modeling for Freeworlds and now updating ships in line with the new STWars look:
Sorry won’t upload .jpg
Edit: It lied it did upload X2
Anyway I just found and downloaded XNormals.
Am disappointed it’s another texture baker and not a a real fix for FL’s graphics implement. Seems like since Microsoft started the whole .dds thing in the first place the FL engine should play nice with all the beautiful .dds DXT5’s tools for normals, but in 2003 DXT1 was new and the the rudimentary DXT3 alphas for the nomads was bleeding edge.I still believe firmly the key to fixing this is some simple recode of the .dds implement to allow DXT5 normals mapping since all the tools are there and modders for games like Fallout and Elder Scrolls have been using them for over a decade. Plus what PS user does’nt have a .dds exporter or Nvidia’s .dds DXT5’s normal map-height map filter?
Baking a texture seems a bit clunky when there should be a direct implementation within reach.
Almost makes me wish I was a coder. (Almost).
-
I might take XNornal for a spin then becase that oblique looked really good and I’m loading in XNormal now and will have some downtime to RTFM.
At least I hope it will give my ships that “Something extra” as far as the texturing goes. Though the day someone gets real subpolygon displacement into the engine is day I’ll keel over.
-
There’s nothing that’ll “fix” Freelancer’s graphics short of actually replacing the renderer, which is what Schmack and I did. The texture format has literally nothing to do with this.
This isn’t Unity, you don’t just tick a box and give a texture and the engine magically does everything for you. The engine was never built with normal mapping support, therefore it cannot support normal maps. XNormals is just a tool to generate normal maps, it’s completely useless for Freelancer since Freelancer doesn’t know what the hell to do with them.
Now, with Schmack’s and FW’s renderers, we can support normal maps, but that’s only because we specifically implemented support for them ourselves, and you won’t be able to test that for a while longer.
Also not sure what you mean by “been modeling for Freeworlds”?
-
Sorry,that sounded wrong. I revamp freeworld existing ships cmps and mat files for myself and local users. Doest get seen by the server side. Getting a new ship into the game is nigh impossible as you must know but customizing existing ships is simple. I’m waiting for calls to update ships to the types in the new movies.
As for Normals Mapping it’s what I figured. I’ve tooled through XNormals enough to see it’s not doing anything I can’t already do without it.
