@Destrania,
The nature of this tech inherently means it can produce more accurate global illumination than Enlighten can.
That's not what this engine is about. Brigade uses path-tracing for lighting, instead of traditional real-time rendering techniques.
It can produce very realistic lighting as it aims to simulate the rays of light bouncing around the scene as you would see occur in real life. It's very taxing to calculate this sort of lighting in real-time, which is why this and all the other Brigade engine clips are really quite impressive.
@MWong,
Yes, the Enlighten middleware has been used by DICE since Frostbite 2. More recently it has also been integrated into the Unreal Engine too.
In fact, with the exception of Eve Online by CCP Games, every other game in that video is running on either the Unreal Engine 3/4, or Frostbite 2/3.
EA do not own Respawn Entertainment. At the moment the Frostbite engine is being kept in-house for EA dev's only.
In what way is he a "has been"?
Indeed.
Near enough all games on the current consoles have had to rely on pretty heavy resource streaming to keep hot data in ram at all times. This may just be a case of simplified streaming, or no streaming at all. It doesn't just have to be "higher resolution textures" or "poorly optimized code" as the only two reasons being thrown out there. (In fact, this is pretty far from poorly optimized code I would say - inefficient code doesn't automatic...
@threefootwang,
What?!
If you really want to believe that DICE would scrap every line of code for FB3, by all means, go ahead and stick with that. In reality they haven't.
http://www.frostbite.com/ab...
"The engine has been refined and tuned".
"It has also allowed the core team and its partner game teams to rapidly evolv...
@Hammad,
I do agree with your last paragraph. If anyone could afford to do a complete re-write it would be one of Activision's leading studios. However, that really is a completely different point.
The point that so many people, yourself included, seem to be swinging is the "it's not a new engine..." put-down. I'm targeting that, and my response to it is it's not surprising, it is quite normal in software development, and it doesn...
You do know that a games engine is built up of a whole wealth of low and high level systems, right, most of which won't be dependent on the capabilities of the renderer? Developers will rarely come out with a new iterations of their engine by re-writing everything from scratch. Why do you think that's any different here?
It could be classed as a brand new re-written engine with lots of old code in it, or a really old engine with a mass of new code in it. The argument ...
The shooting mechanics won't really be what they're talking about here.
An engine that is designed to be used on multiple projects will typically see a dev team keep as strict a separation between gameplay code and engine sub-systems as possible. In Naughty Dog's case, they will be mostly referring to those engine sub-systems themselves (that run at a lower-level than the gameplay stuff), as well as the supporting dcc tools for it, rather than specific gameplay fe...
Just about every engine architect and game dev worth their weight will intelligently design the layout of, and communication between, engine sub-systems to allow for maximal ease in maintaining the engine as well as in minimizing the time/work-load/money cost involved in code changes over time. All software developers, myself included, want to avoid as much coupling as possible to hardware, operating system, or 3rd party apis. Keeping the underlying platform intricacies wrapped up and hidden ...
Umbra 3 is an impressive piece of middleware tech. It is used for s/w occlusion culling, which is where in-game renderables are culled out based on whether or not they are completely hidden behind other objects in the visible scene. If they are completely hidden, the engine can avoid doing unnecessary graphics api calls, which are quite costly, as well as to avoid doing gpu processing of geometry that will end up hidden.
As you can see, this is one particular problem within g...
@Utalkin2me,
You want to quiz me? Ha! Fair enough. However, you are asking a vague question on a broad topic. I'm a C++ programmer. I do this stuff every day and I know what goes into building games tech like this, so I don't know what you want by way of an answer.
With regards my previous comment and your question I can tell you this, any decent engine does not need to be built from scratch again to take account changes to the things you mentioned. T...
Most game devs will create a new iteration of an engine by re-using code and upgrading only systems and libraries that require it. A games engine isn't one massive bulk of code (unless developed poorly), it's a huge collection of individual systems all designed to do specific things and communicate in any number of ways that promote easy maintaining over time. Why would they write everything from scratch, including the stuff that doesn't need re-writing? This really isn't unus...
There's nothing special going on here. For years we've had 64-bit processors that use the x86 instruction set, but with 64-bit extensions. That's what will be inside the PS4 and XB One.
If you are confident in your ability to self-teach you will find a wealth of information available on the net that can take you all the way to where you want to go. Even for a topic such as games programming, you'll find masses of info.
You need to figure out your overall direction first, and then devote time to picking up a programming language. The professional games industry will use C/C++ (C plus plus) for pretty much all areas of development. C# (C sharp) may also be...
I've always wondered how Epic were going to pull off their SVOGI. I mean, the original Cyril Crassin work that Epic based SVOGI off of highlighted just how limiting it would be even on high-end h/w. It gobbles up gpu and memory resources. That's not to detract from how innovative this real-time GI solution is though. Cyril et al. have done fantastic stuff, but I've struggled to see where they could pull back performance at the levels necessary. Excited to hear more as Epic progres...
Roll back time to when I did my thesis and I would have jumped at the chance for something like this.
I would get my thesis done as I would have anyway, but I'd also come away with 'triple-A' dev experience, a bunch of contacts in the industry, a foot-in-the-door, and all the knowledge I could soak up from a group of highly talented individuals. It's just a win-win in my mind. Good on DICE for offering up what I see as nothing other than a golden ticket.
Just wanted to point out that a lot of games will not calculate animation poses at a rate dependent upon render speed. In fact, it's often unnecessarily taxing to calculate animation poses and blending at anything greater than 30fps. Transformations in world co-ordinate space may of course be calculated at a rate determined by the rendering system, such as 60fps, or queued at a lower fps and then interpolated with each render presentation (typically increasing input lag). The local joint ...
I wholeheartedly agree.
I spent a lot of time researching and studying the AI in FEAR as part of my thesis quite some time ago. Put together by a guy called Jeff Orkin, it used something called 'Goal-Oriented Action Planning'. It was quite an ingenious way of doing Game AI. A lot of folks shy away from it these days due to the difficulty of using it during development. Either way, it's a great feat to have achieved for AI in games.