LocationHiding in a cake, left in green city called New A... something.
Posted 16 August 2013 - 11:12 PM
Purlana, on 07 July 2013 - 08:05 AM, said:
I always wondered why the zoom module didn't function like the regular zoom...? (But more powerful / higher magnification) Maybe I am missing something?
People were highly voceal about them having to do it the same way as in MW4.
They were told how it is and they complained about PGI even further and since it was at the time PGI listened more than nowdays, they've bitten the bullet and gave them what they wanted...
I know that a lot of players try to old PGI as the party responsible for why DNF was so bad. However, PGI's role in DNF was rather minor. They were given a bad task (tacking on mutiplayer because all games have mutiplayer now days) and did the best they could.
This image uses the exact same technique Piranha is using - they are "reusing" the image they have rendered already as a texture and apply it to the scope. So this is NOT rendering the image twice. If AA was not enabled you could detect the pixels in the scope, as they are simply upscaled. I am 100% certain of that.
Now onto "Rendering in a second Viewport". I will try to make some generalizations so that non-geeks might understand it.
Why can old engines like Unreal 2 or Source do this without a real hassle, why the ultramodern CryEngine 3 can't?
Well actually it can, see here: http://www.crydev.ne...p?f=314&t=76779
But it is not very feasible. And the main reason is performance.
Basically CryEngine 3 is a "deferred rendering" engine, while CryEngine 2, Source, Unreal etc. are "forward rendering" engines (the great majority of Unreal Engine 3 titles is).
A forward rendering engine basically operates like this: You have a light and an object. If the object is in the light's radius, you compute the texture changes/lighting on the object for each polygon (triangle) of the object and apply the change.
Now this happens per-frame for dynamic lights, but engines like Source or Unreal have most of this precomputed, so that the lighting is "baked" into the object's texture, making it permanent.
Regardless of dynamic or precomputed lighting: realizing a second viewport, which is roughly in the same area as your first one, will work without greater problems. Because the lighting is computed for the whole object, it does not matter whether you stand on the exact opposite of the main viewport, everything will look great.
And the cost is manageable because the diffuse lighting and shadows have been computed for all objects already.
Now onto deferred rendering. The term is broad and every engine uses other parts of this overall method, but what you need to know is this.
Before rendering a frame, a so-called "G-buffer" has to be set up, which is usually quite expensive to compute. This is basically an image which stores information (like depth) from the current view which are needed for correct lighting computation. With the G-buffer and the position of the lights, we can calculate the resulting color values for each pixel on the screen.
So that means that the lighting we calculated is only valid for our viewport, because we calculated for each pixel instead of each object.
Now if we were to create a new viewport, we could not recycle any of the lighting computed, because it was tailored specifically to the pixels of the main viewport. A new G-buffer is needed and all lighting has to be recalculated. If the second viewport was the same size as the first one, we would cut our FPS in half, unless we run out of video memory, which would worsen the whole thing immensily. And even if the second viewport was much smaller, setting up the G-buffer is still quite expensive.
I hope it was understandable so far. And these which know more specifics, please don't kill me with 'OMG deferred shading and lighting are not the same'.
So the point which i wanted to make so far: Implementing a second viewport would probably be possible, but the FPS drop (without heavy modifications) would be way too significant to justify the thing.
And please, even if your computer runs like a ferrari - you would not be pleased to suddenly have 40 frames instead of 70 when trying to have super-accurate aim.
What would be much more feasible for instance was to render the zoomed area in double resolution, so when upscaled the pixels match the screen resolution. Technically this should be possible, but I imagine it to be quite a bit of a hassle for the rendering engineers.
----------------------------------------------------------------------------- "Wait - but aren't the ocean reflections also technically something like a different viewport?"
Yeah but no direct lighting is applied to objects, apart from the sun, which is still forward rendered afaik. No shadows, no fancy effects at all. And the objects are limited to very big objects (short viewdistance). But the flaws are very hard to spot with all the wave distortion. This is totally not the quality needed for another viewport.
----------------------------------------------------------------------------- "So why did Piranha chose CryEngine in the first place? If it is so expensive to render everything and we can't even have another viewport and all the netcode...
Deferred rendering has disadvantages, yes. But there are some big advantages. Once the G-buffer is set-up, calculating lighting for individual point lights is very cheap. You can have hundreds of dynamic lights in your scene without too much of a hassle. And the lights also do not care about how many objects are lit or object complexity (well apart from bump/normal mapping). This allows CryEngine to render every light on screen dynamically with ok performance.
Which also means that you do not have to precompute anything, really. Which means that when a level designer builds a map, the map will look exactly like that in the game. In Unreal Engine 3 you would have to compute the lighting each time you change anything in your map. Which takes quite some time, even if you have a server-farm attached to the process. So basically as long as you do not "build" lighting you do not really know how the level is going to look like.
In CryEngine 3 every light is calculated for each frame, everything looks in the editor as it does in game. For a designer this is much more convenient. He does not loose time while the lighting is computed and he instantly sees results when changing stuff.
Also CryEngine 3 has a very competent level editor overall. Setting up terrain is incredibly easy and quick, and modifying the day-time and sun light is very convenient.
So one could say CryEngine 3 is more developer friendly, while Unreal Engine is more gamer-friendly in terms of performance.
Finally I want to make clear that I have indeed some idea about CryEngine and the sorts.
You do realize that the weapons you fire travel a lot faster than 150kph right? Especially weapons you fire while travelling 100+ kph.
Yes. Weapon calculations have all variables set the moment a weapon is fired. This is obviously not true for mechs. Nor do mechs behave as points in space -- the structure to keep track of is at least an order of magnitude more complex. Captain Obvious, etc...
Yes. Weapon calculations have all variables set the moment a weapon is fired. This is obviously not true for mechs. Nor do mechs behave as points in space -- the structure to keep track of is at least an order of magnitude more complex. Captain Obvious, etc...
Actually.... you'd be surprised. The supposed issue is latency tracking, not the functionality of the frame moving.
0
Purlana, on 07 July 2013 - 08:05 AM, said:
