Sometime in July Unity 3.0 will be released. Unity is a game development middleware engine. The latest offering has recently been released in beta form for those that pre-ordered and I have had a week now to experiment and use many of the new features. It is an amazing update and offers substantially more then the previous release.
Being a programmer there are quite a few new art / asset pipeline features that I have not had the luxury of testing , I urge you to try them out for yourself!
Deferred Rendering / Reworked Shader system
Looking at all the marketing spiel for Unity 3 there is a lot of talk about the new deferred render that has been added, but not much talk about the reworked shader system. Both are great and easy to use. The deferred render is provided as an option for moderate level hardware (dx9+), and like all deferred renders decouples geometry scene complexity from lighting. Except for all but a few corner cases (many full screen lights will kill fill-rate limited hardware) this means that you can have hundreds of lights in your scene with very little performance implications. A fallback path is provided that uses a single dominant directional light and spherical harmonics for any object that is transparent or where deferred rendering is not supported. The one downside that I believe exists with the fallback path is that spherical harmonic lighting is calculated at a per vertex basis instead of a per pixel basis. If your mesh has low tessellation this may lead to some lighting artifacts. I assume that the spherical harmnonics are of a low order, and that is why lighting is being calculated per vertex.
The new shader system takes a surface description approach to lighting (think BRDF’s). Instead of describing ‘what’ happens you describe the surface in terms of properties. This is then processed by the shader system into a series of shaders that have lighting permutations calculated. The move towards surface description shaders is due to unity now primarily using a deferred renderer. Multiple explicitly written shaders would have a high probability of causing unseemly scene issues as deferred expects geometry to be only rendered once (i.e a multi pass shader where verticies are changed between passes would be bad). This removes some degree of freedom when rendering illuminated objects, but it is still possible to render non illuminated objects using the ‘old’ method. I think the move towards surface description shaders is a definite positive for the engine as a whole and will allow for faster scenes and better engine support in future.
Beast / Lightmapping
Beast is a great solution! I have used / implemented it before in a work project and I have to say that unity have done a great job with it! Beast adds tremendous value to the worlds that you can create. The integration in unity seems quite good, especially for the first release, but there are a few features that I would like to see. Specifically the ‘light environment’ baking and implementation into the render pipeline (as the shaders do support spherical harmonics now this should be a logical next step). I would also like to see more of the XML configuration exposed in the unity GUI (Environment texture is a good example). For a very new feature I think that unity have done a great job.
Monodevelop / Source Level Debugging
Monodevelop is now the default source editor in unity. It’s a big improvement. Unity also allows for source debugging in scripts. This has already saved me many hours of fruitlessly adding printf’s to see where things are going wrong. The ability to debug scripts while the engine is running is a great addition!
Things I think are missing / Not quite there
I will preface this by saying that Unity3 is not released yet and is beta, and it could all be wrong. I will also say that these (small) issues I have are pretty corner case and 95% of users will probably never have any issue. But I still feel they are worth mentioning from development point of view.
Rendering shortcomings
Unity has a great render, but there are a few fundamental features that are not exposed to 3′rd party users, which would make life much easier. Currently unity only supports rendering of the current scene. This is done via rendering a camera. It is possible to ‘hook’ this camera, but it will still requires scene lights and scene objects. There is no way to render a few arbitrary objects with arbitrary lights without adding them to a scene and then rendering that specific scene. I would very much like to be able to something like the following:
<code>
var utility = new OffscreenUtility();
utility.Camera = Camera;
utility.Lights = LightArray;
utility.AddMesh( position, rotation, mesh, material );
Texture render = utility.Render();
TextureCube render2 = utility.RenderCube();
</code>
I notice that this is similar to how the current preview windows are rendered in Unity… but more on that in a minute.
There are a large variety of cases where I would like to do something like this now. It is a very frustrating process to render something into an ‘offscreen’ buffer. I have to either configure a scene with layers and use camera masking (not a good solution as it is not cross project / package import compatible), or add my objects to the world with use replace shaders to only render those objects, and even then they will use the scene lighting and I can not specify my own lights.
Editor API shortcomings
I believe pretty strongly that any inspector / api window that comes with unity should be able to be created by end users using the editor API’s that are provided with the engine. For the most part this is the case, but there is no way to generate a few of the inspector types that exist in engine currently. This is not helped by the fact that the current documentation / example code for editor extension is quite weak. A great example of this is the handles class, I could find almost no documentation on this class in either unity2.6 or 3 or online. If I was Unity I would probably put together an example project showcasing editor extension, demonstrating how to use many of the handles and inspectors that exist in the engine.
Conclusions
Unity 3 is a great step forward! If you are making games (and not messing with tech rendering stuff like I do). Then you will be right at home. It feel like a natural evolution from unity 2.6. Similar, but enhanced! I would easily recommend that you upgrade as soon as you can.
{ 1 } Comments
Hey Tim
Thanks a lot for the kind words. We’re very excited about this release and working hard on beating the kinks out of it to make it our most solid release to date.
We’re aware of the editor API documentation shortcomings and I personally would like to have some resources dedicated to rectify this in a not too distant future.
Until such a time, regarding handles and general editor API resources, I’ve got some articles and open-source projects you might find useful.
Articles:
http://angryant.com/category/general/tipsandtricks/
Path-GPL:
http://github.com/AngryAnt/Path-GPL
Sketch:
http://github.com/AngryAnt/Sketch
In particular you should find Sketch useful as it’s a small project I did in a few hours with short, simple scripts using the handles API.
Path-GPL is a different beast. Written as a learning experience and as a result overly complex, but it shows some good pointers on using custom assets and throttled co-routine based workers in Unity.
Post a Comment