As I read through Unity docs and attempt to try-out features and understand the overall-architecture, I am surprised to that there are very, very few diagrams that are not screen-shots.
It would be nice to have an overall-architecture diagram of how “Scripts” interact with the “Game Engine”.
Data-flow between Unity3D Editor and the programming-dev-environments (mono, VS) is not entirely apparent. Diagrams would help.
Apologies for cross-posting it on the “getting started” group as well. Thought it’s relevant to both. I hope this is not in violation of any of the etiquette on these forums.
Thanks for the feedback, we’re always looking to improve existing areas of the docs so these are useful comments, and I agree that we could do with more diagrams. Do you have any specific examples of pages where you think these are most urgently needed?
We are developing a 3D oriented App in the arch-viz domain. (ghar3d.in). It’s focussed on the India market. Our App was earlier based on bscontact (as an ActiveX component) from bitmanagement.com. It was based on Vrml / X3D which in turn had their graphics rooted in the phong-model.
We have turned to Unity in part due to the more modern pbrt. (Physically Based + Global Illumination ).
However, I am finding a lack of flexibility w.r.t GUI. For e.g Ideally I would like to port our C# / WPF based UI to Unity. It appears the out-of-box Unity C# stuff is DotNET 2.x based. (correct me if I am wrong on this ). In general the lack of diagrams and detailed technical description makes the understanding of architecture/data-flow a bit tricky.
It appears that Unity in it’s quest for a cross-platform solution has ended up with a very old, LCD’is (Lowest Common Denominator ) type of solution w.r.t UI & related widgets. This is naturally constraining.
However if good diagrams are offered coupled with sound technical knowledge we could try to push the boundary a bit and meet our requirements and hopefully help the Unity platform as well.
You’re correct that Unity does not support .net’s WPF gui system. We have two main GUI systems in Unity, the newer one being the main recommended system for most cases.
Our main UI system is not old, and in my opinion cannot realistically be described as a “lowest common denominator”. It is designed to meet the needs of UI systems for games and interactive content across all our supported platforms, with their wide variety of resolutions, aspect ratios and input methods.
You can start reading about how to use our main UI system in the manual, here.
We also have an older UI system which works in a completely different way. It is code based, and is an “immediate mode” system, meaning the code to draw the UI needs to be called each frame. It should generally not be used when building traditional UIs for games or apps, but it is used when developing editor extensions within unity itself, and in fact the whole of Unity’s own UI is written using it. It can also be useful for developers to make quick in-game UIs for the purposes of testing.
You can read about the older code-based immediate mode GUI system in the manual, here.
If you really like WPF and XAML layout, checkout the Noesis Engine http://noesisengine.com/ and se what they are working on in their Trello board - Trello
It has a large portion of the WPF control set, bindings, styles, low level Visual layer, all in Unity, all in XAML.