#1
Posted 16 May 2018 - 06:41 AM
#2
Posted 16 May 2018 - 06:48 AM
#3
Posted 16 May 2018 - 07:01 AM
#4
Posted 16 May 2018 - 01:58 PM
If CryEngine handles materials anything like Unreal Engine, it's probably just a simple material function on a cube. Any one of the buildings would have a larger memory footprint.
#5
Posted 16 May 2018 - 06:33 PM
RelativeQuanta, on 16 May 2018 - 01:58 PM, said:
If CryEngine handles materials anything like Unreal Engine, it's probably just a simple material function on a cube. Any one of the buildings would have a larger memory footprint.
thats not exactly true. the math to figure out if something needs to be rendered is non trivial, but z-buffering is cheap. by the time you know if the pixel in the frame buffer is occluded or not youve already done most of the work needed to render it. most you can do is frustum cull, clipping planes, and backface cull at the polygon level. and thats after you have already done all your transforms into screen space. but what do i know i only wrote my own software renderer.
Edited by LordNothing, 16 May 2018 - 06:39 PM.
#6
Posted 16 May 2018 - 08:09 PM
LordNothing, on 16 May 2018 - 06:33 PM, said:
thats not exactly true. the math to figure out if something needs to be rendered is non trivial, but z-buffering is cheap. by the time you know if the pixel in the frame buffer is occluded or not youve already done most of the work needed to render it. most you can do is frustum cull, clipping planes, and backface cull at the polygon level. and thats after you have already done all your transforms into screen space. but what do i know i only wrote my own software renderer.
The fact that math is non-trivial doesn't mean it's unsolved. It has very much been solved and every single major 3D engine has it implemented in some way.
Here's the documentation: http://docs.cryengin...lling+Explained
Stuff that isn't on the screen isn't drawn.
#7
Posted 16 May 2018 - 10:34 PM
#8
Posted 16 May 2018 - 10:41 PM
My beef with this map is that it's
1) Too dark - shame to have to use nightvision to see properly, when so much work went into neon signs..
2) Too crowded - I get that it's a city.. so is River city.. and yet, on river city, a mech can move and shoot and LRM and do all kinds of things.. On Solaris, you always feel cramped, and if you end up there in a LRM boat, you might as well disco-out.. you will be just as effective..
I don't get it.. Why do you hate LRMs PGI?
The last two maps, for which we have waited an age to get, are totally anti-LRM..
Contrary to popular belief, people do actually play LRMs!
Edited by Vellron2005, 16 May 2018 - 10:42 PM.
#9
Posted 16 May 2018 - 10:46 PM
That being said, it's a good map. Just not for you.
#11
Posted 17 May 2018 - 02:19 AM
RelativeQuanta, on 16 May 2018 - 08:09 PM, said:
The fact that math is non-trivial doesn't mean it's unsolved. It has very much been solved and every single major 3D engine has it implemented in some way.
Here's the documentation: http://docs.cryengin...lling+Explained
Stuff that isn't on the screen isn't drawn.
of course the math is solvable. we wouldnt have 3d games if it werent. its just you can get around the trouble of dealing with it if you throw memory at the problem. then an n^2 problem becomes an n problem and you can render things really really fast. culls are part of the render pipe and they do eliminate a lot of render time when you get to the rasterization phase. but it takes a lot of work to get to that point.
when you use an api, like opengl or d3d a lot of this stuff is done for you, you just say heres what i want to render, heres how, now get to work. game engines usually wrap one or more apis with an abstraction layer of sorts and a bunch of pre-defined classes to work with. then that array of processors we call a video card breaks up the work between them. of course when you write your own software renderer you dont get that amount of power (and mine was a single thread renderer on top of that), so everything needs to be very tight. so you cull things as fast as mathematically possible. things like eliminating geometry not in the render area, and checking the z buffer before handling blending can save a lot of time.
#13
Posted 17 May 2018 - 02:55 AM
Vellron2005, on 16 May 2018 - 10:41 PM, said:
I don't get it.. Why do you hate LRMs PGI?
The last two maps, for which we have waited an age to get, are totally anti-LRM..
Damn near every map in the game features open terrain, long lines of sight, or both.
You get Tormaline, alpine, polar, and frozen to spud spam at the very least.
Please don't cry about the one map that is a foil to your playstyle, the one map where lights excel.
Remember all those times where you told people to stop telling you how to play the game/have fun? Full circle my dude.
#14
Posted 17 May 2018 - 03:23 AM
LordNothing, on 17 May 2018 - 02:19 AM, said:
of course the math is solvable. we wouldnt have 3d games if it werent. its just you can get around the trouble of dealing with it if you throw memory at the problem. then an n^2 problem becomes an n problem and you can render things really really fast. culls are part of the render pipe and they do eliminate a lot of render time when you get to the rasterization phase. but it takes a lot of work to get to that point.
when you use an api, like opengl or d3d a lot of this stuff is done for you, you just say heres what i want to render, heres how, now get to work. game engines usually wrap one or more apis with an abstraction layer of sorts and a bunch of pre-defined classes to work with. then that array of processors we call a video card breaks up the work between them. of course when you write your own software renderer you dont get that amount of power (and mine was a single thread renderer on top of that), so everything needs to be very tight. so you cull things as fast as mathematically possible. things like eliminating geometry not in the render area, and checking the z buffer before handling blending can save a lot of time.
I'm not sure what your point is here. Are you just saying that you can trade memory size for algorithm complexity? I don't argue that at all. That you wrote your own software renderer? That's really cool!
However, CryEngine does cull objects that aren't in view. The documentation shows that. A large water plane below an opaque ground surface should have a very minimal impact on performance.
#15
Posted 17 May 2018 - 03:57 AM
#16
Posted 17 May 2018 - 01:51 PM
Brain Cancer, on 16 May 2018 - 10:34 PM, said:
#17
Posted 17 May 2018 - 04:16 PM
RelativeQuanta, on 17 May 2018 - 03:23 AM, said:
Hey there. Would it be ok if I rewrote what you said to this:
"However, CryEngine does constantly engage in a decision making process as to which objects are rendered and which are not depending on whether the object in question falls inside field of view. This decision making process can translate to decreased FPS and lower performance which suggests that completely deleting unnecessary layers or objects can reduce the amount of decision making and selective culling an engine makes which translates to better performance."
I feel like we're having a discussion on CPU branch prediction where we assume that cache hits play no role in determining overall performance. Yes the process of branch prediction may appear seamless and smooth from a transitional perspective but that doesn't mean it doesn't carry a negative malus on performance? If that makes sense. The same principles could apply to rendering engines although I'm too n00b to say whether or not this is the case.
#18
Posted 17 May 2018 - 07:51 PM
IIXxXII, on 17 May 2018 - 04:16 PM, said:
Hey there. Would it be ok if I rewrote what you said to this:
"However, CryEngine does constantly engage in a decision making process as to which objects are rendered and which are not depending on whether the object in question falls inside field of view. This decision making process can translate to decreased FPS and lower performance which suggests that completely deleting unnecessary layers or objects can reduce the amount of decision making and selective culling an engine makes which translates to better performance."
I feel like we're having a discussion on CPU branch prediction where we assume that cache hits play no role in determining overall performance. Yes the process of branch prediction may appear seamless and smooth from a transitional perspective but that doesn't mean it doesn't carry a negative malus on performance? If that makes sense. The same principles could apply to rendering engines although I'm too n00b to say whether or not this is the case.
No, this isn't the case either. Running the culling algorithm is already a net savings. Then there are thousands of things that the culling algorithm is checking. A water plane is just one of those things to check and its even simpler than the majority of the stuff like lamp posts that you push over with your mech. The time cost savings would negligible.
#19
Posted 17 May 2018 - 08:19 PM
It seems like Solaris City has a lot of extra little details that could be cut down a smidge. They may also have too high of detail on some of the invisible meshes, like occluders and collision mesh, that can be trimmed down.
I'm assuming those types of fixes are going to happen soon*.
#20
Posted 18 May 2018 - 06:30 AM
Vellron2005, on 16 May 2018 - 10:41 PM, said:
People have been asking for a cramped city map for years, myself included.
Give people who wanted one a break. it's one freaking map!
Edited by Mystere, 18 May 2018 - 06:30 AM.
3 user(s) are reading this topic
0 members, 3 guests, 0 anonymous users