Video Game Engines

[deanb]

Kinda wanted a thread like this for a while. Anywho, say hello to Unreal Engine 4

 

 

 

 

http://www.wired.com/gamelife/2012/05/ff_unreal4/all/1?pid=2549

(p.s I'll be reading the article when I'm back, but for now, pretty pictures.

[Yantelope V2]

I'm a little surprised to see this because weren't they going on about how long a life Unreal 3 still had in it? Wasn't that the point of the Samaritan demo?

 

[deanb]

Samaritan is Unreal 3.5 and a glimpse of "where they think next gen will be going" (it's a PC level demo that required SLI of the most top-end cards when launched). Unreal 4 has been in the works for donkeys now, just at the start it was like a couple people working on it and as 8th gen has crept up so will the demand for a new unreal engine and Epic are stepping forward to meet that.

[TheMightyEthan]

And from reading the article it sounds like a lot of what Unreal 4 is designed to do is to streamline development some teams don't have to keep ballooning.

[Yantelope V2]

I just don't know if there really is any way to keep things from ballooning. Just look at the credits of any movie now with tons of CGI. They go on for almost 10 minutes with hundreds of graphic artists and animators. I don't know how you can make your artwork more detailed without increasing the man hours it takes to produce. Maybe we need to teach computers to paint?

[TheMightyEthan]

With stuff like not having to hard-code lighting on objects, instead just letting the lighting engine handle it. The more stuff you can do in real-time the less work it takes from humans hard-coding it. Additionally they can see the results of any changes in real time without having to wait for it to render. Also stuff like making scripting way easier with visual, flow-chart-based coding rather than actually have to write it out in a scripting language.

[Yantelope V2]

I'd also like to add that my big hope for future game consoles is actually less focus on the poly meshes and types of texturing and such but I'd really like to see a much heavier focus on the post processing aspects of the engines. Typically things like motion blur and anti-aliasing really kill performance when done properly but in my opinion it's things like jaggies and simply not rendering images in a way to make them look natural which is really hurting graphics. Crysis was so exciting to me and in a lot of ways still looks better than most everything out there because of the procedural ways it handled lighting and motion blur and other post processing effects.

[P4: Gritty Reboot]

Unreal engine has always been a nice, steady graphics engine with decent flexibility. Personally I'm a fan of the way Source engine games tend to look. They focus on high-fidelity textures and duller colors rather than a boatload of post-processing effects that look nothing like real life. But that may simply be the way Valve handles their games as opposed to the technology itself.

[Yantelope V2]

Well, Portal 2 had a shockingly natural look to it and for it's day HL2 did as well. I don't think it was a lack of post processing though as much as it was like you said, an emphasis on high quality textures and it seemed to me at the time their handling of shaders and post processing was actually quite good.

[TheMightyEthan]

I think with the advent of FXAA and whatever ATI's equivalent is called we're going to start seeing more anti-aliasing on future consoles because it can be applied as a shader effect and doesn't require nearly as much processing power.

 

I agree those, effects like antialiasing, texture filtering, normal/bump maps, etc go a lot farther for me in determining how "good" a game looks than poly counts do.

[deanb]

As the processing grunt advances so does the tools. You've all seen the Photoshop CS5/6 stuff with the content aware fill n deblurring tools. That's just photos. It used to be back in ye-olden days you code the 3D elements in by hand. And that'd get you stuff like:

 

But then you got 3D modelling packages like XSI

and you could move the polygons about n such and you'd get stuff like this:

 

And for the most part it was fine. And then 7th gen cropped up and big scary words like "million polys".

 

And thus digital sculpting tools like zBrush cropped up

 

Which for the moment is doing pretty well.

 

You don't fiddle with polygons, you paint and sculpt like you're working with clay, not with origami and paper cut outs. (you end up throwing it back into stuff like XSI in the end mind since you still need to animate it n such). One person now can do much more than one person could 10, 20 years back. Making Adam Jensen through raw code or building the model poly by poly would be laborious work. What has changed is the scope. Games do so much more than they used to. You make a character model in about the same time, but you're not just making one character, you're filling up a room full with random trinkets and objects, you're making larger casts, tons of random NPCs etc. Thing is I bet you could get away with dropping a large amount of the fluff. The fluff doesn't really make the game. Especially since adding in the fluff means not working on stuff like giving processing power on the side to do stuff like AA, which does produce noticeable results.

 

As for Source: looks kinda nice (and it's definitely in the texturing) but it's terrible from a developer point of view. Don't forget the Portal 2 editor is custom made for Portal 2 to allow folks to make maps with it. The dev level tools for Source as a whole, FaceFX, Hammer etc are all generally panned as being incredibly sucky. Which is why UDK is used so much; it's much easier to use, much better documented, and there's a large amount of working results.

[P4: Gritty Reboot]

Yeah by all accounts Source is still stuck in 1998 as far as editing tools go. Likely why it's essentially a Valve-only engine at this point, aside from mod teams.

[Luftwaffles]

The problem I've always had with source is that it's optimized great for lower hardware, but pretty poorly for higher end hardware. When I upgraded my computer I expected all the studdering and menu freezes in TF2 and Portal 2 to just go away, but nope, that's just part of the engine. If anything, that's what I'd like to see Valve work on.

[P4: Gritty Reboot]

I don't have stuttering problems anymore. My only frustration is that it doesn't seem to be able to load extremely large areas into memory and so breaks it up with constant loading screens. Been like that since Half-Life 2 (and GoldSrc before it too).

[deanb]

Yeah given that's still in Portal 2 so I reckon that's a hard coded part of the engine that will most likely never disappear until a new engine appears. Kinda like the pop-in UE3 has upon loading a level.

[Johnny]

The problem I've always had with source is that it's optimized great for lower hardware, but pretty poorly for higher end hardware. When I upgraded my computer I expected all the studdering and menu freezes in TF2 and Portal 2 to just go away, but nope, that's just part of the engine. If anything, that's what I'd like to see Valve work on.

 

As someone who's stuck with lower-end hardware, I do not mind

[deanb]

Some more of the Luminous Engine.

[Yantelope V2]

Can anyone say what this was rendered in real-time on? 4 $500 graphics cards?

[deanb]

http://www.gamasutra.com/view/news/171899/Square_Enix_lifts_the_lid_on_its_nextgen_engine.php

 

http://www.agnisphilosophy.com/jp/index.html

 

the demo was running on a very high-end PC with off-the-shelf commercial hardware.

I'd guess similar to Samaritan, though maybe a bunch of 690's now instead of 670's.

[deanb]

I'm going to assume it's running on a Nvidia card. (Which makes the tags funny)

[Faiblesse Des Sens]

Impressive.

[deanb]

http://www.joystiq.com/2012/10/23/square-enix-becomes-first-publicly-confirmed-unreal-engine-4-lic/

 

Square are first studio confirmed for UE4. Likely for use with Eidos stuff.

[TheMightyEthan]

So apparently this is a thing:

 

 

If this isn't all just marketing BS, why isn't anyone else working on tech like this?

[deanb]

Wow I thought that died at least a year back, they re-peddling their shit again? It's perfectly awesome if you just want a non-interactive scene to move around in and don't care for the fact raster based polygon tech is what everyone is using. Also requires vast amounts of memory which isn't much of a common thing.

 

Also compare it with the tech demo of UE4 on the previous page (shifted this to the engine thread btw). You'll notice a lot more interactivity in in UE4 trailer because it has much more flexibility in allowing that, particle systems, physics, and even basic animation is much simpler and less processor intensive on polygon based engine. In medical imagery you don't need the motion and interactivity. Also video game levels tend to have a wide range of variety, whereas the "unlimited detail" engine instances a lot of itself so the landscape is pretty damn dull.

 

Also I'm not even sure who they're aiming for. They'd need cash from investors, and investors will look past a lot of their marketing bullshit. Or they need to get cash from developers buying into their engine, and developers aren't retarded and know what works and why they use polygons and raster based rendering and such. They say in the video on being interested in seeing what game artists will do with it when they put this engine in their hands, but here we are over a year later and they've seemingly never put this tech in the hands of any artists.

[TheMightyEthan]

Also video game levels tend to have a wide range of variety, whereas the "unlimited detail" engine instances a lot of itself so the landscape is pretty damn dull.

 

All your other points sound very valid to me, but this one specifically they said that they just made a whole bunch of copies to show how much shit it can render, which is why it looks dull and repetitive. If it were to be used in an actual game with actual artists then they could have every tree be different and whatnot.