GE Demo Videos And Pics
-
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?
-
It depends on the type of CSM you’re using. A “fit to scene” implementation will have the near clip at the same value, allowing you to do what we’re doing. A “fit to cascade” implementation will have no overlap and then yes, it won’t work or at least it’ll need more work to behave properly.
Since we’re stuck with FL’s really inflexible culling, we’re using fit to scene.
-
I will try doing that, it was one of the methods I had intended on testing, since it works for you then I know it’s possible. I had attempted to restrict rendering to a portion of the texture but it wasn’t working as intended. It still rendered to the entire texture. I haven’t messed with stencils much so I need to look into using them…
-
-
NeXoSE wrote:[…] but more people may make greater success. Isn’t it?
Only if they share the same views.
