The saddest and funniest part about MWO is the Atlas is roughly the size of nanosuit soldiers in Crysis yet we still have the lamest visuals, maps, scale and everything else.
I find this interesting,
I once tried to make a thought exercise about how exactly the battlemechs are scaled compared to a soldier rendered in Crysis, and basically got called a moron.
Unbound Inferno, on 06 July 2013 - 02:34 PM, said:
No, but I bet its a different graphics and mechanics requirements for the game. Probably different basic program engine too, so different problems and different solutions.
I used Tribes as an example for games that go over 150kph to show you its not the internet, as you said.
Tribes have not that much hit zones for a single model, but it has a lot more players and vehicles and generators and forcefields and turrets and other stuff and some of it can reach speeds over 300kph. Thats more traffic and stress for your connection then 12vs12 in mwo will ever have.
The saddest and funniest part about MWO is the Atlas is roughly the size of nanosuit soldiers in Crysis yet we still have the lamest visuals, maps, scale and everything else.
Because that's technically how it works in Battletech. And no, there is no PiP in those videos... it's doing EXACTLY what MWO does now, so yes, it's an engine problem. I'm surprised Crytek hasn't fixed this. Even unity supports PiP and in insanely simple way. Seriously, It's about 3 lines of code and 1 more camera.
Because that's technically how it works in Battletech. And no, there is no PiP in those videos... it's doing EXACTLY what MWO does now, so yes, it's an engine problem. I'm surprised Crytek hasn't fixed this. Even unity supports PiP and in insanely simple way. Seriously, It's about 3 lines of code and 1 more camera.
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.
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
Ahh yes,
I remember moonlighting that in and hoping we'd see the freelook image enhancement that exsisted in MW3 before beta.
Sadly it would seem PGI is incapable of Carmack-ing a work around or even considering some sort of artistic liberty.
And worst of all they seem to refuse to just drop it into a more extreme zoom and deviate from their failed attempt at PiP.
Regardless of technicality, it would seem there are infact ways to get a PiP going and the fact we've been baking this game for over a year and a half with reductions instead of additions makes me raise my brow.
What will happen when the DX9 jury rigging meets the DX11 update if and when it comes along I wonder.
That's sad. TheUncle's post basically reads: The earlies we can expect working cockpit screens , or *sight* the compressed 360 view so essential to BT ( but no BT games ) is 3 or 4 years, when hardware progression of the average non-competitive player ( like me) has negated the questionable engine choice of the devs.
And yes questionable, since performance is pretty low compared to the graphics you actually get and the ease of mapmaking you mentioned does not really result in that many maps for MWO so far.
I remember moonlighting that in and hoping we'd see the freelook image enhancement that exsisted in MW3 before beta.
Sadly it would seem PGI is incapable of Carmack-ing a work around or even considering some sort of artistic liberty.
And worst of all they seem to refuse to just drop it into a more extreme zoom and deviate from their failed attempt at PiP.
Regardless of technicality, it would seem there are infact ways to get a PiP going and the fact we've been baking this game for over a year and a half with reductions instead of additions makes me raise my brow.
What will happen when the DX9 jury rigging meets the DX11 update if and when it comes along I wonder.
Its stated in that link that it (PiP) can be done, but not without massive FPS decreases... It has nothing to do with PGI's inability to code within the Cry 3 engine. That it is indeed a limitation in the engine due to the type of rendering used.
They should drop the PiP altogether and just give another layer of zoom tbh.
That's sad. TheUncle's post basically reads: The earlies we can expect working cockpit screens , or *sight* the compressed 360 view so essential to BT ( but no BT games ) is 3 or 4 years, when hardware progression of the average non-competitive player ( like me) has negated the questionable engine choice of the devs.
And yes questionable, since performance is pretty low compared to the graphics you actually get and the ease of mapmaking you mentioned does not really result in that many maps for MWO so far.
But thanks for taking the time to explain it
Not quite..........
Basically what he's explained is that The old way lighting was copy and pasted from what was already rendered in your main screen and plastered onto the little PiP you were zooming with.
With Deferred the game literally handcrafts and corrects the lighting in real time and when you attempt to do the standard method of PiP you start rendering the game twice down to the teeth.
Saxie, on 07 July 2013 - 06:26 AM, said:
Its stated in that link that it (PiP) can be done, but not without massive FPS decreases... It has nothing to do with PGI's inability to code within the Cry 3 engine. That it is indeed a limitation in the engine due to the type of rendering used.
They should drop the PiP altogether and just give another layer of zoom tbh.
Except crytek had made a nice little work around to do it in crysis 3.
Graphics are literally smoke and mirrors and there is always an alternative, if there wasn't PC gaming wouldn't exsist.
Basically what he's explained is that The old way lighting was copy and pasted from what was already rendered in your main screen and plastered onto the little PiP you were zooming with.
With Deferred the game literally handcrafts and corrects the lighting in real time and when you attempt to do the standard method of PiP you start rendering the game twice down to the teeth.
Your point being? All I was saying was, that if the game survives a few years you could introduce it because the same game would be played on more powerfull hardware.
Of course that is not an ideal sollution
Your point being? All I was saying was, that if the game survives a few years you could introduce it because the same game would be played on more powerfull hardware.
Of course that is not an ideal sollution
With todays physical limitations of processors and video cards I would doubt such an exponential growth would occur.
With todays physical limitations of processors and video cards I would doubt such an exponential growth would occur.
Actually, graphene might help break the current limitations on manufacturing processes at and below the 10nm line (where quantum tunneling becomes an issue) which is estimated the manufacturing process is to break this barrier at 2017. We are currently at the 14nm process today, but not mass produced yet for the market.
I always wondered why the zoom module didn't function like the regular zoom...? (But more powerful / higher magnification) Maybe I am missing something?
With todays physical limitations of processors and video cards I would doubt such an exponential growth would occur.
Ah, ok, yeah, might be an issue. Didn´t think of that. But you never know, there might come a breakthrough. Optical computers.. but then again..that´s probably about a decade or two away.
0
KhanHeir, on 06 July 2013 - 11:48 PM, said:
) is 3 or 4 years, when hardware progression of the average non-competitive player ( like me) has negated the questionable engine choice of the devs.
