GE Demo Videos And Pics
-
Actually this video is in preparation for the next release. I am in the process of adding in the mission related stuff and building the foundation for the empire related items (HQs, miners, living quarters, populations, etc) so it will most likely be at least another 2 weeks to a month before I post it for download. Also it will be a simple ‘play with it’ type of game, there is no save or load features added since the game is constantly evolving. I had that at one point but it no longer works since so much has changed, this includes even the server code. Once the code has stabilized I will go back and revamp that part of the game.
-
That’s a great idea LS
I’m thinking i’ll run it on my spare PC… just sitting there… being a world for a few weeks lol… i’ll look at what available code on my main PC and also look at trying to convert some ships for you
once i get my head out of modding X2… i recon im gonna be able to mod almost anything now, something i’d like to give back m8
I’ll talk to ya latter’s closer to release.
-
Well nice thing is there is plenty of moddability to the game. I didn’t pack away the ini’s in an encrypted format even though that is possible with the script reader. Also I have nearly completed the construction code after 2 days of working on it. Just a few more things to add to it and it will be working the way I want it to.
I am also looking into adding a day/night cycle for the planetary maps. If I do add it then most likely it will be an excellent addition to the weather system. Especially if I go with the procedurally generated skybox method.
I will be offering for download soon a .bip file (Max biped file) for those whom wish to make their own characters. All you will need is a pre-rigged char model to attach it to. This file has all of the in-game char animations in it so you can use the pre-existing charanim.ini settings to add your own chars. Changing which char model the player starts with is as simple as editing the config.ini file.
-
I have been working on implementing soft shadows into the game and here is the result of 4 days work…as always, click the image for a full size view.
-
New city scape model
-
Perfect! Use antialias - it will be better for showcases
-
Thanks guys, that one was a pain to convert. The UV map didn’t hold properly when converted even though it looked fine in the modeller. Since I already have UV tiling built-in to the engine, it was simply a matter of finding the right values. BTW anti-aliasing is turned on thru the NVidia panel. Since I use render targets it can’t be turned on thru DX. What I see rendered doesn’t have any jaggies but it seems Fraps captures the pics before it’s applied (FXAA)…
For the tool pack, here is one by Alex
http://dl.dropbox.com/u/10971457/Freelancer/Digital Brilliance backup.tar.gz
-
I’m not sure what you mean by that, LS, but RTs don’t preclude the usage of any form of AA. Freeworlds has built-in AA and we saturate the DX9 RT limit.
-
I thought you did it thru the use of a post processing filter? I worked on trying to get MSAA to work but I ran across some info on the MS site that said it doesn’t work with render targets. Once I turned it off the render targets worked properly. Unfortunately this is the main issue with doing deferred rendering. I just haven’t gotten around to adding a smoothing effect since FXAA is working good, the jaggies only show up when its being captured. I may do it once I implement SSAO since I already have a depth and normal render targets implemented. Haven’t decided which type of blur yet, I would use a guassian type but it’s a bandwidth hungry format. It’s what the shadow map uses. It’s based loosely off of this page…
And here is another shot of that cityscape
-
We’ve implemented FXAA directly in DirectX, which lets everyone benefit from it and not just Nvidia users.
There are also more advanced techniques for doing deferred MSAA, or even other, better techniques than FXAA like SMAA.
-
I haven’t really studied the different forms of filtering yet. I had heard the same that SMAA was better though. What other types of effects did you add to your render engine?
-
Had to compile a fairly exhaustive list a few weeks ago, so here you go:
- Deferred shading
- Lambert shading
- Blinn-Phong shading
- Normal and specular mapping
- Cascaded shadow mapping
- Shadow map filtering using temporal reprojection
- Shadow map percentage-closer filtering
- Dynamic lighting with stencil buffer optimizations
- Cube mapping with variable glossiness using pre-filtered environment maps
- Soft particles
- Distortion mapping (heat haze)
- Detail mapping
- FXAA 3.11
- Scene-dependent bloom post-process
- Lens flare post-process
- Color correction post-process
-
Nice collection of features added into it. BTW, how many passes did it require for the cascaded shadow mapping? Been trying to figure out a method of doing it it one pass to no avail…
EDIT:
Lol, I was looking into SMAA implementations, the first entry on the google list was…http://www.gamedev.net/topic/623655-smaa-implementation-weights-pass/
-
Yeah, SMAA’s a bit tricky, but our hacked together engine doesn’t help matters.
We’re rendering CSM using one pass per cascade. The overhead of trying to render it in a single pass, at least on DX9, just isn’t worth it. There are enough advantages to using separate passes for it to be worthwhile, though, and I’ve implemented a stencil buffer to avoid rewriting the same pixel twice.
-
I did the same because without a depth/stencil buffer the shadows showed thru objects. I have also been looking into using TSM (trapezodal shadow mapping) since it works well with a single pass method. Since it already requires 4 passes (depth,screen space shadow, gaussian vertical and horizontal passes) I am trying to avoid any more rendering.
Anyways, it’s still pretty impressive for a hacked together engine.
-
CSM works much better than any other form of shadow mapping really. It’s less prone to edge cases, which space sims have a lot of. I wouldn’t recommend using another technique when the vast majority of the industry is using it.
Also, I’m not speaking of depth buffering, which is a given. I’m speaking of a stencil buffer used to mark pixels that have been rendered as part of the current cascade, which lets me use the most precise cascade outside of its expected boundaries if the perspective allows it, thus maximizing the use of the data we have. It’s slightly costlier than splitting by depth but the results more than make up for it.
Finally, fullscreen passes are cheap. Implementing a much more complex algorithm just to save one or two passes is insane.
-
Well my understanding of CSM is each cascade has it’s own set of geometry to be rendered. So how are you able to use the same stencil buffer for all? Each cascade afaik would have it’s own view frustum or are you using the largest frustum for the stenciling?
