OldUnreal (Engine)

Yeah, I am sure some of you have heard of it by now.  And it is not my bidding of course, but I use the ENB Series Shader 2.0 that was originated for Deus Ex.  And apparently it does work with unreal gold... so anyways, there are a few issues that may be able to be resolved or helped.  And if we can get them to be fixed, then possibly using this shader in your new version would put a smile on people's faces.  As of now, there is something in this shader that I am trying to use.  And it is called FOV [Field Of View] which blurs out objects farther away and sharpens up objects at a close range.  When using this enhancement, unreal gold looks just unbelievably mind blowing compared to ut2004 or ut3.  HOWEVER, the FOV will distort your text, menu, hud, console, and some other things that are not really expected.  But look down below for my thumbnails, this should shock you.  And if we could work on converting this shader for DX11 or DX10 then it could possibly make unreal look as good as something like Crysis or Far Cry.  My other question was just if we could try and work on fixing motion blur too... so that it would really give a tingling sense that your actually there.

::PHOTOS::
http://img215.imageshack.us/gal.php?g=shot0010je.jpg

imo

"FoV" in that highly unrealistic, if you were actually in unreal and looking at things, your eyes would focus on distant/close objects, not do it based on a static "distance." Bloom is far too ridiculous, motion blur is unrealistic as well just as in any game since your vision doesn't blur to that magnitude when just turning your head. I turn off any of these unnecessary and unrealistic settings off in any game that allows me to.

DX10/11 are useless for unreal unless they deprecate DX8/9 both AND OpenGL at the same time in the future.

tl;dr : Unreal is fine as it is

oh my god... that looks AWESOME, lemme replace my pants for a minute here...

okay wow... just wow, it seriously doesnt look unreal anymore, those shaders make it look stunning, these are the effects i've been trying to achieve with ENBseries... now how come ENBseries looks like bloated plastic crap on my pc... have any settings you could share with us?

i agree with casey that all of these things are merely a gimmick, and they detract from the normal gameplay, but really after playing unreal for so many years, any change in visuals is greatly welcome to me, especially stuff like this :p

Well, I am currently tweaking this for the most realistic aspect it can possibly offer.  To give this a more lucid look on unreal, sort of like gears of war.  And unreal would look way better with motion blur, and fov.  I play this ALL the time with it on, and I assure you that it is something you are missing out on.  Now, the photos I took are not currently up to date, and I have made the FOV weaker because it truly was too blurry.  So don't get me wrong, you CAN tweak this graphics mod to your liking.  Somethings I just left turned off because of choppiness, such as the Ambient occlusion.  Which causes memory leaks and just other karma I believe in.  Perhaps, whenever you guys release the new version of 227... the shadow cast and this shader would come together like glue.  I also think that with DX10 or DX11, if the game was rewritten to use this shader... it would make unreal totally bonkers.  Visually, physically, and emotionally

imo

"FoV" in that highly unrealistic, if you were actually in unreal and looking at things, your eyes would focus on distant/close objects, not do it based on a static "distance." Bloom is far too ridiculous, motion blur is unrealistic as well just as in any game since your vision doesn't blur to that magnitude when just turning your head. I turn off any of these unnecessary and unrealistic settings off in any game that allows me to.

DX10/11 are useless for unreal unless they deprecate DX8/9 both AND OpenGL at the same time in the future.

tl;dr : Unreal is fine as it is

I have studied and surveyed people on unreal, and few have given me this answer.  "Unreal doesn't need better graphics!"  But the other half says that it would make new players more interested, and it could attract a lot more people back to unreal.  And the shading, fov, and motion blur is only the beginning.  IF you've ever wondered why Epic Games hasn't remade unreal gold.  It is because they are lazy and bored, and a product does NEVER sell twice.  Therefor, the only was is for us to get off our a**'s and do the work for them.  But I will leave you to decide the fate of 227g, that is non of my business anyways.

Motion blur and DoF (because you're actually taking about DoF here) are very distracting and limiting, and so is bloom. We don't see motion blur like that in real life, we have our own DoF when we look at the screen, and we don't see that much bloom as well.
But normal maps, now that's another story. They would enhance Unreal for sure if made right. There were attempts at that earlier, but it was never finished AFAIK.

Parallax mapping is up and running in DX10 driver. As for post-process effects I have 'em up and running for Residual Decay and Dead Cell (both are UT total conversions). And TBH ENBSeries DoF looks terrible and it would do far better job if it'd be integrated directly into rendering device. Motion blur/bloom are very easy effects to achieve, but then again they are all overused . Here's how few effects looks in game:



and http://turniej.unreal.pl/portfolio/?blog,s,1,p,1 and http://turniej.unreal.pl/portfolio/?blog,s,1,p,4 are details about implementation.

I have studied and surveyed people on unreal, and few have given me this answer.  "Unreal doesn't need better graphics!"  But the other half says that it would make new players more interested, and it could attract a lot more people back to unreal.  And the shading, fov, and motion blur is only the beginning.

I think that was not was he meant. Indeed, if you look at the wiki and the forums here we implemented ~150 new things and fixed even more. If that is not attracting people then I don't know and most of these things are fairly unused yet. The new maps from some of the testers use these things and the results are overwhelming.
If, or if not a specific feature is used or implemented depends on many things.
We are a very small team here. I have the sources but my abilities are limited due to my bad health (I'm sure Dots and Casey are pretty annoyed by it, but it can't be changed).
Dots is working his ass off with the limited headers to implement new engine/rendering stuff and Casey is providing the test suites, does scripting and also is working on some c++ parts - That's the "Core Development Team".
SMPDev always keeps us up to date with his UTGLR and Raven is providing from his projects external additions which I can implement. Other contributions are rare nowadays. Anyone can contribute since this is an open community project as much as possible although its limited to public headers.

Of course there are many other important people in this project, but that's it pretty much for development (at least for currently active).
So its always a question of what we want and what we are able to do.

I won't leave WinXP as stable and known development platform until 227g is out to avoid new problems, since stability and reliability is most important before anything else.
If someone wants to go into this direction to implement the things you mentioned it will happen after 227g probably as I don't see who could do it right now and 227g is way over schedule already.

In some possible 227h or maybe 228- who can tell? Also maybe as external project like UTGLR now or the upcoming DX10/11 stuff can be implemented with new features.

Currently I tend to agree that these things are overused and before we can really use such things we would have to change all rendering, light/shadows etc to use the graphics card instead doing all in engine. We really maxed it out now and its eating up a hell of performance.
But this is no easy step and currently I wouldn't bet that it ever happens, many things to learn, many things to try, many changes, many hours of bugfixing and testing and Epic not really willing anymore to support me (or us).
Lets concentrate on releasing 227g now, let us do it right and if people are happy then everything is possible.

I like to think that the visuals we see in games are being viewed remotely by a camera because, let's be honest, it doesn't matter what the game looks like, you'll still always feel like you're remotely controlling something like a Mars rover (in the case of console games, anyway) instead of feeling like you're actually in the game.

If you don't what I mean by the above, all of the effects you see in more recent games can be obtained in real life by the use of video cameras. Motion blur, bloom, DOF, etc. are all present.

EDIT: And also, those people are only half right that Unreal doesn't need better graphics. It doesn't, but it would be nice to have if it can be accomplished. If it can, cool. If it can't, oh well.

it would probably be optional too, not?

I don't like to see ANY artificial unsharpness on my screen. No matter if it is motion blur or depth blur or whatever. It reduces visibility and decreases my FPS.

It is my opinion that unless the map author has full control over these FX, it will end up looking terrible in many places where the overlays are rendered.

I don't see that kind of functionality anywhere near an easy task for the 227 team.  Getting the FX in Unreal is one thing... getting them to work properly is an even harder thing.

If done right, people could definitely use these tools to make their maps look much more professional and more up-to-date with current engines.  That is simply fact.

nedm.

That's the reason I didn't like ENBSeries. But making controllable by mapper is trivial task - just make some variables changeable by UScrtipt, few triggers etc (having per-zone shaders is also very easy). It's only compatible with OGL ATM (D3D9 support in plans) but it's not that hard.

Now that I think of it, bloom and blurring of the screen would be better off being used for temporary effects, like emerging from water or going from a dark place into sunlight, where the effect is there for a second and then goes away completely until the next occurance. Game devs can't seem to get this idea into their heads and just apply the effects to the whole game.

I don't really like that blur and shaders.

Shaders still make Unreal look like wrapped in plastic and it's very unrealistic that our eyes go blur when watching far away. Unreal players will need glasses like nerds. And the popular problem: Too much contrast and too dark.

Some kind of shader would be cool, but not that powerful. Self-shadowing (with shaders) is awesome when correctly used. Real-looking water is awesome (check Half-Life 2). Textures with dynamic sides or cracks (they react light) is awesome when slightly used. Blurring effects would be cool in camera-scenes, or when taking damage and or in big explosions, but nothing else.

There are a lot of things in the mesh code that could be improved as far as higher poly count and more hardware friendly goes, but some of these things also not easy to do, and more so if don't want to complicate support for the older render devices like Glide, D3D7, and software.  If nothing else, faster CPUs over the years help quite a bit, but without a number of major changes it remains in the low poly engine category.

May be worth looking at adding a new render device capability / feature request flag called something like WantMeshClipping that defaults to enabled, but could be disabled by render devices that want higher level mesh clipping to be skipped.  Could use it to also select an alternate path to help with performance, but this one has the other important use of making sure the render device can get mesh triangles with good normals instead of junk data in new verts if higher level code clips these triangles.  Would need to check that this clipping never ends up important for anything that wouldn't be covered by standard clip planes for whatever projection is set up, but if no problems there then much faster to let hardware deal with clipping.

If able to release new headers, then option to get mesh triangles with good normals and no special case complications for the current clip cases could be useful to help with implementing certain special features in the renderer.  Doesn't really matter anymore for TruForm since ATI dropped this a long time ago, but if happen to remember that, clipped verts and junk in the new clip created mesh vertex normals was what made TruForm in the renderer do bad things when mesh triangles hit the edge of the screen.

DrawGouraudPolygon not good at all for efficient high vertex count.  A function with 6 stack params and some exception frame setup with the guard / unguard for in most cases every single triangle, and the various other checks it needs to do for state changes, is not insignificant overhead.  Even the option for a simple Begin/Buffer3/End immediate mode like interface design could be much more efficient (and much simpler than reworking higher level code to provide large block of verts and index information for draw elements style).

Some nice features in the newer graphics APIs, but D3D9 and most Shader Model 3.0 level or better hardware fairly capable and flexible, and should be able to handle a wide variety of things fairly well.  Should be possible to do a lot without giving up XP D3D compatibility, though for some things not necessarily as easy and/or fast.

Also have the OpenGL 3 option for getting access to newer features but on an older OS like XP.  I'm still not liking a few things about ATI's GL3 drivers though.  As of their 10.5 drivers on XP, and close to half a year after put together a prototype GL3 renderer, I'm still seeing a specific major performance loss issue.  Eventually traced this back to if add a single glGenVertexArrays() call then my timedemo benchmark goes almost 30% slower (note that this is only if add the call to generate the name, but not actually trying to use it yet...).  Wasn't running in any very high resolution either, and UE1 not exactly known for high poly / low CPU time in general, so they must be doing something so very, very slow to pull the overall benchmark down that far.  I was thinking of maybe trying the geometry shader tile optimization and seeing how a mostly clean slate new API renderer that could throw out a lot of the old junk looked, but as long as this issue around I don't much point in doing much more with it.

At least can think of one good thing about further delays before I'd see any reason to release this one.  Looks like now I can change it to requiring GL 3.3 and finally get sampler objects.  In its current form got it to the point where it could use a GL 3.2 core profile and forward compatible context (and before GL 3.2, I didn't have much interest in doing anything with GL3 with how that came out initially...).

Well to be frank, unreal isn't very realistic at all... with the shader enabled, the extra effects would make it seem a little more different than just a blank set of bumpmap textures.  Textures should bump out, and with little effort fade at long distances.  When looking at the ground you will notice things in the background are out of focus.  The closer objects are, the more focus.  With the focus and motion blur, it makes unreal pop out at you and it makes you say "woah" ....  It is naked with out them, it feels great to have all of these wacky effects.  Makes things a little more interesting, and almost shows a generation above unreal engine 1.0.  That was the true point of this thread, the way things look are extraordinary.  And overall, a bit more vibrant and less bland.  Whether or not the human eye does not blur out this much, it really makes unreal more enjoyable to play WITHOUT a thousand different mods.  It is in fact why I have it, so I can enjoy playing single player.  The lower the brightness, the more scare is involved.  It is funner.