Kind of ironic, I don’t like people with an attitude that the software is to blame for poor quality work.
well, the software is to blame sometimes, I believe cryengine 3 and unreal engine 4 looks better in terms of global illumation, ambience and shadows, but reason I use use unity is because I feel the only thing that is wrong with it (in my opinion) it does not look AS good as the triple A ones and it cant use C++ for general scripting (I have a weird disdain for C#) other than that, Unity is near-flawless.
They’re just as problematic as the ones going around endlessly calling other peoples work (certainly not their own work) poor quality, crap, and such.
Prettiness aside that demo doesn’t really prove much in terms of graphics capabilities for games … a single, static, model that causes serious jerkiness when the camera pans.
Yeah, the real question is… can Unity compile a whole racing game with those graphics, and not crash the fastest of computers? We’ll never know!
Well, maybe someday someone will release a AAA title (whatever that is) and put the debate to rest.
I agree that it is very awesome that Unity provides access to the underlying DX11 stuff.
It would suck terribly if Unity put limits on what you could do. If I want to write my own fancy shader, I don’t want the engine saying “no you must only pick from the shaders we provide”.
I also agree that technically it isn’t necessary for an engine to provide shaders. But you’ve started down a slippery slope. Is it necessary for an engine to provide networking? Is it necessary for it to provide support for loading meshes? Is it necessary to support scripting? Where do you draw the line? Is it really enough if all an engine does is get out of your way and let you program as if there was no engine? Not in my opinion. An engine should do things for you so you don’t have to. That’s why you buy it instead of writing your own. If I want to write my own shaders, I will write my own shaders.
But there are some standard graphics algorithms that have been developed and refined by brilliant researchers and programmers over the years. For example, ambient occlusion, soft shadows, real time variants of photon mapping, subsurface scattering, etc etc etc. Unity may be flexible enough that you can roll your own scripts to pull off all of those. But that results in the game developer needing more time and expertise, just to re-implement something that other people already figured out. If you just want to make a game and don’t want to spend all your time reading and implementing SIGGRAPH papers and GPU gems, then you want to pay someone else to implement the graphics code. It makes logical sense that such code is part of or comes with the engine, at least for standard effects that many people will want. Others could be add-ons in the asset store. All else being equal (obviously in reality nothing is equal), an engine that comes with the latest SIGGRAPH papers already implemented is better than engine where you have to write your own. Folks on this forum often come across as saying “Unity is better because you have to code everything yourself”. This is where I get concerned.
I’m not saying that Unity is a bad choice, I think that for a huge variety of games, it is a great choice. But Unity is not perfect. If it was perfect, it would come with every effect you could ever want, and you just have to learn how to activate it. My problem is with the people on these forums who are so eager to defend Unity that they think saying “Unity stays out of your way and lets you code your own effects without limitation, the only limitation is your own skill” is going to convert people who were actually asking “does Unity come with a good implementation of X effect out of the box”. You are unfairly deflecting the question. This is like the common open source meme: When somebody asks, “I think open source program X should have Y feature”, they get a snarky response “sure it does, you just have to code it yourself”. You are answering the wrong question. Some people just want to buy something that works, not everybody wants to re-invent the wheel. For those people, Unity might be the wrong choice. If you try to say otherwise, you might fool someone into wasting time with Unity when it doesn’t serve their needs. This just makes the community look overzealous and unprofessional.
Examples != functionality. Providing lesser amounts of examples does not in any way hinder the ability of the engine, as I said above. Not supporting actual features greatly hinders functionality. There is a line between a feature and an extra. Extras are not integral to performance, like packaged shaders, character controllers, light cookies, or even the example project.
But by your logic, you may as well just sit down with visual studio and write your own game in raw DirectX. After all, you have all the functionality that your computer has to offer, every feature of the GPU is exposed. Nothing hinders you from writing anything you want. But everyone on this forum seems to agree that writing your own engine is a waste of time. When comparing game engines, you need to evaluate what features that engine gives to you that visual studio alone does not. I would argue that for everyone to do their own implementation of voxel cone tracing would be a waste of time. It would be better if it was a feature of the engine that you could just turn on. The cone tracing isn’t simply an example of what can be done with the engine, it might one day be considered a core piece of functionality that any decent game engine has to provide. Would you say that MIP mapping is just an example of what can be done, and that you don’t have to include it, and that you should code it yourself with shaders? Of course not, it is a core feature that all engines support. (I know this is a bad example since its built into the hardware. Shadows might be a better example.) If Unity added the latest and greatest effects, they would be ahead of the curve.
All of the extras Unity offers have been created in the Unity engine itself. The features within the engine have not.
And this is relevant to a game developer how? When the Unity team wants to expose some functionality to the game developer, that functionality might be hardcoded into the engine C++ source code, or it might be done with scripts, or it might potentially take a combination of both. This is an internal decision that the Unity team has to make. Some things might have to go into the core engine, other things are possible as scripts. Maybe some things are possible as scripts but are more efficient if baked into the engine at a deeper level. All the game developer cares about is what he can do with Unity, and how easy it is to do it. The purpose of a game engine is to save the game developers time. The more things the engine can make easy, whether it be core functionality or extras, the better.
You can’t expect Unity to just package everything with the engine. Why should they do your work for you? If you want to easily make good shaders, use Strumpy. If you cannot write shaders yourself, buy some from the asset store or hire somebody to make them. There is no necessity in Unity packaging more shaders with the engine. Why don’t they just package an entire RPG system or MMO system with the engine as well? That would make the engine more convenient for some people. One of the biggest overlooked differences between the big three engines is that Unity Technologies is a company that makes an engine, not games. Unreal and Cryengine are both from companies that also create games. They have teams specialized in fantastic shaders and graphics, as they have Unreal Tournament and Crysis respectively. What you’re asking is for a game engine company to make your game look pretty for you. The ones you should ask for nice shaders and graphics would be a game development team with people who specialize in shaders, not a game engine development company.
Thank you for that comment, this clarifies where we really disagree. The issue here isn’t whether graphics features are good, but rather what features are part of the engine vs. what features are part of the game. What is a game engine? Here is my point of view: A game engine provides systems that are common to many games. You buy a game engine so you don’t have to start building everything from the ground up. The engine involves rendering, physics, networking, and input, for example. Using those tools you can add artwork and gameplay. The artwork and gameplay are the game, the rendering, physics, networking, and input are the engine.
The current discussion is rendering. When you make a game, you want to hire artists. The artwork will be custom for the game. The artwork has to get rendered. The game engine should do that for you, that’s the purpose of the rendering portion of the engine: to transform a mesh + textures + lights + shader selection into an image that looks great and renders fast. In the really old days you’d have to write all the rendering code yourself, there was no engine unless you made your own. But why should every game have to have its own implementation of rasterization and lighting and texture mapping? These are common to all games, so build an engine and let the game developers reuse the renderer. The engine should do them for you because you want to focus on the art and gameplay, not the rendering.
Over the years, computers get more powerful and new algorithms are invented. There was a time when wireframe rendering was all there was. Then flat shaded polygons. Then smooth shaded, then texture mapped, then programmable shaders, shadows, global illumination, and whatever else.
At any point in time, you could invent your own rendering algorithms, or read the research papers and code your own implementation. But if you just want to make a game, you want an engine to make life easy. You want to just take the artwork and tell the engine “go render”, and it comes back in 1/60th of a second with an image that is as photorealistic (or cartoony, as the case may be), as the current technology allows.
Every year new GPUs come out with new features. Every year new SIGGRAPH papers come out with new rendering techniques to run on those GPUs. My point of view is that the rendering engine should stay current with support for the latest GPU features and the latest SIGGRAPH algorithms for rendering cool things on those GPUs. That way you can always create some art in Maya and toss it in the engine and out comes the best possible looking result. I don’t consider rendering to be part of the game, I consider rendering to be part of the engine.
A really good rendering engine like that in Unity goes beyond offering up a selection of good rendering options: it allows you to code your own by writing custom shaders and multipass rendering methods via render-to-texture. This is fine, but it is really a last resort, only to be used when a feature is missing from the engine.
How would YOU decide which rendering functionality is part of the engine, vs. what is up to the game developer to implement?
Personally, if I want to write better rendering code, I’ll go work for a game engine company and improve their renderer.
If I want to make a game, I’ll use an engine where all the rendering is already done for me, so I can focus on gameplay while letting the artists do their thing.
If I want to write my own renderer AND create my the art and gameplay… I’d have to be a large, well-funded game company that creates their own engine for their own games. But that’s not what Unity is about.
I too see where you are coming from now. This is mostly just an argument of when rendering should be considered a feature once boiled down a bit. You consider the shaders to be an integral part of the rendering pipeline that Unity should have previously laid out. I tend to think of shaders as a form of customization that build on top of the integral rendering features. I think it is an artist’s job to make custom shaders while you think they should be there in the beginning so they can be used by an artist. Graphics-wise, my definition of an engine is just one layer lower than your definition of an engine.
Another thing that may be confusing this discussion is that shaders nowadays are so versatile that the term “shader” can mean different things to different people. To me, a shader is a program executed on the GPU, whether as a pixel shader, geometry shader, compute shader, tesselation shader, or whatever. A shader can perform any computation you want, if you know how to parallelize the task. Shaders can sort lists, perform fluid simulations, and solve differential equations. From that point of view, some shaders should be part of the engine, others are part of the game. Just like any other code that plays a role in a complete game+engine, somewhere you have to draw the line, and yes it is somewhat arbitrary.
The original intention of shaders, and hence the word “shader”, is derived from the idea of doing the math to assign a color to a pixel. You find the shade for that pixel by consulting stuff like light sources, material properties, and texture maps, then combining them according to a formula of your choosing. I would say that an engine should include basic shaders to do texture mapping, normal mapping, and basic lighting. If you want something exotic, then you can write your own. But if you want something fancy-yet-difficult-yet-standard, like parallax mapping, it wouldn’t hurt for that to come with the engine.
On a different but related note, it is interesting to consider what is part of the graphics driver vs. what is part of the application.
A modern GPU does not have fixed-function shading hardware. Even something as basic as flat shading with no texture must be done with a shader.
The shader will just take the dot product of the normal with the light, and output a fixed color with a modulated intensity. But why should the app developer have to reimplement that basic functionality? That shader is inside the driver, even though you can also write it yourself.
No kidding, it can take me weeks to design a good looking 3d model in Blender.
I just want to know guys, should I make a separate post completely dedicated showing how good unity can look, I really want to get some more exposure out there.
This so much. Unity has most of what you need to make a very pretty game right out the box, it’s just that you’re expected to put things together yourself and provide the assets. I imagine that a lot of those people who complain the most don’t make the connection that in Cryengine/UDK they’re often using ready-made assets developed by professional artists working with high budgets. It saves time no doubt, but it’s not fair to turn around and say Unity has bad graphics when 90% of what makes a game look good is having good assets and art direction.
You know, that actually might not be a bad idea. The “The most awesome Unity titles you’ve seen” and “Cool images for the Unity3d.com gallery” threads have sort of gotten overrun; a thread dedicated to nothing but the most high-end visuals pulled off in Unity would be kind of cool.
I think it’s some cruelly if say " Unity Cannot Produce Good Graphics…"
Because we can see the games made with unity and have good graphics , we can’t say unity is perfect and every time AAA because other engines some times have better Graphics , in my opinion unity graphic is not 100 and not 0 it’s about 40-70 but variable.
My problem with unity graphics is :" why it’s should be some time’s too hard often time consuming for the medium and semi-professional game developers to produce good and perfect graphics with it? "
From other side problem is really galling because you take your time to invent a wheel (for example) that is invented frequently by many others and many times used but you can’t access their wheel and you should consume your golden time to do it again and again and maybe finally can make some thing like other invented wheels.
I think it’s a BIG problem for unity beginner and medium users and that really annoy me and some of other people.
unity should think do a work for this issue. 
I think the issue is that there are more Unity devs than most other engines - it is easy to use and quick. Many of these developers are also independent/beginners and release their games without AAA-like graphics. The sheer number of these indie games vs the number of professional games may create the stereotype that Unity cant produce good graphics.