We know that most of the rendering stuff will be on the client side, which obviously means we'll need to have a good graphic card in order to handle all the rendering workload. If we look at Team Fortress 2, we have a very good proof that it's possible to render a game without consuming too much resources (I'm speaking about the rendering part only, not anything related to vertices). Is such rendering alternative considered at UBER ? In the meantime, very simple question i guess : when computing the scene, which part of the stuff does consume most of the graphic card resources ? Is it possible to increase the number of polygons rendered by having cell/cartoon shading instead of heavy textures ? Thanks
At this point there isn't likely to be any definitive answer as he engine is still far from feature complete. Mike
No. It's actually other way around. "Heavy" textures are the cheapest way to to achieve nice graphics since you can increase texture resolution as much as you want without having an impact on render time, ONLY limit for texture size is the GPU RAM. Second-cheapest are polygons, you can increase the polygon count, but there is a limit of like 10-100.000 polygons per scene, you wouldn't notice much of a difference if there would be more. With proper use of instantiation techniques (which can be used in an RTS where models DON'T use bones but consist of static structures), even 2-3 years old graphic cards can render scenes with up to 5 billion polygons(!) in realtime. So whats expensive? Shaders, this goes from "realistic" metal and water up to cell shaders. Yes, cell shaders don't save computing power, on the contrary. They only help hiding low polygon models and allow for a graphic style which also doesn't use other expensive features. One of the worst things are particle systems. Real volumetric fog looks awesome, but is also quite expensive to calculate. If worse if a particle system produces real light sources, like flickering flames. Because that affects yet another expensive features: Dropshadows. The more lightsources you have, the more expensive shadows become. Why are shadows so expensive? Look at how shadows are computed: You have to render the scene from the direction of every light source and project the resulting depth map back onto the scene. And now do that for every single light source in the scene... Now there is one last step: Post processing, like blur filters, refraction when looking though water or hot air etc. This is also quite expensive.
Thanks for you answer . So, Is there any alternative to shaders ? I mean cell/toon shading could be used as a valide alternative (so no shaders) and we would have a cartoon rendering. The video POC looked like more a cartoon. As i'm not a coder, i hardly imagine what would be the additional cost in terms of time/money if different rendering alternatives were used.
Uber should just license the Quake 1 engine, if it can run a rally game it can run an RTS. Might be bit brown though.
Honestly, I'd go with the Dwarf Fortress engine. ;-) (Thank god I have nothing to do with the engine)
Hmmmm mod maybe? Typically this is simply done in the shader. Also 3d engine design is a fairly complex and deep topic. I'll be going into more detail about ours as we get further along and things come online. I wouldn't take anything said in this thread as gospel as it's very difficult to make definitive statements about graphics performance bottlenecks in a general way.
Since the advent of the programmable graphics pipeline, shader programs are the way modern GPUs (approximately the last decade) draw things. Whether it's the most realistic AAA game on the market, or the most cartoony AAA game, or the crappiest 2D game, it has to use shaders if it's running on the GPU. Sort of like a program has to exist in order to run on your CPU. In general, GPUs render triangles to the screen. GPU cost of a game is generally bottlenecked by one of the following things: 1. Vertex processing 2. Fragment processing 3. Draw calls Most vertex processing is usually just a matter of transforming positions from object space (the way models are stored) into view space. This means that vertex processing cost goes up pretty much linearly with the number of vertices that the GPU is asked to handle in a given frame. With appropriate LOD systems, it's usually pretty reasonable to keep this cost down, regardless of how complex the scene looks. There can be additional vertex processing costs if you're doing fancy things in a vertex shader, like distorting a mesh. This isn't very common, though, and rarely do games have heavy vertex shaders on more than a few models. Fragment processing (sometimes referred to as fill rate) happens once the GPU has transformed a polygon into view space, and decided which pixels it covers. Fragments can be thought of as pixels, but the reason they aren't called pixels is because multiple fragments can contribute to the final colour of a single pixel on the screen. For instance, you might have a solid object in the background contributing to a pixel, as well as a partially transparent overlay adding to its colour. Fragment shaders use textures and vertex colours, plus other information like the lighting environment and any specific material properties, to decide the colour contribution to a given pixel. A fragment shader can be very simple (say, "always green"), or more complex, involving multiple texture lookups and some heavy math in order to calculate realistic (or unrealistic, because you can do whatever you want!) lighting. Thanks to something called the depth buffer, fragment processing for all the opaque objects in view is pretty cheap. This is because only the visible (front-most) fragments need to be drawn. Where things get expensive is with transparent and full-screen effects. This is why particle systems can really slow down a game: if you aren't careful, you can end up asking the graphics card to draw many times over the same area of the screen. Even if the transparent effect uses a relatively cheap fragment shader, this "overdraw" can add up quickly. The weirdest of the three (to someone who has never dealt with graphics cards) is draw calls. GPUs are insanely fast, but they need to be fed properly. Essentially, there is a cost to every state change on the GPU. The best thing you can do with a graphics card is tell it to draw really big list of similar things in a very similar same way. Every time you switch shaders or models, you get what's called another draw call. Even on modern GPUs, too many draw calls can completely kill graphics performance. Luckily, through things like batching and instancing, it's almost always possible to make sure that draw calls are not your bottleneck. If an engine is properly optimizing its draw calls, exactly the same visual effects can be achieved more quickly by minimizing the time the GPU is switching states. As Jon says, though, 3D engines and rendering are complicated. What I've written is really just a high-level overview of where costs can lie.
Thx for the answers. I may not have clearly expressed what was my concern. I was not asking for pa rendering to be crappy or old-school. I was just concerned about possible rendering options That would keep the game looking awesome without struggling the gpu. To me, but i might be wrong, the video poc rendering was such rendering that would not struggle the gpu compared to the rendering which is used in forged alliance. Dont' get me wrong, i'm not asking for low end rendering engine when Team fortress 2 came out, many people stated that it was the best proof that you could have a very looking good rendering without killing gpu performance because of cartoon style rendering.
By the way, and just for fun, minecraft pixel style can be very nice http://www.dailymotion.com/video/xcv6dv ... n_creation
Except that this movie was rendered using raytracing and a illumination model which can't be used for real time applications like games. Every single frame of the movie takes several seconds or minutes to compute. And it would look awful if it did just use the same rendering techniques as Minecraft...
Are you sure? TF2 is an older game, so it will run very quickly on most machines right now. I'm pretty sure its performance was on par with other Source games of the time, though. It featured things like dynamic lighting and shadows, as well as soft particles. None of those were cheap effects in 2007. In any case, the point is that cartoon-style rendering does not necessarily equate to cheap rendering. You can make arbitrarily complex fragment shaders no matter what style you're going for, and post-processing effects can get similarly expensive. RTS games also have to deal with far more independent objects than FPS games, so the comparison to TF2 wouldn't have been that useful even when it was current.
