Just want to clarify some decisions.
- in MeshBuffer the return type of the Vertices property is Object and it returns an array depending on the vertex type, which is a copy
That is because vertex itself can be different type. And there is no templates in managed C++ (at least at point that i was writing it), so i decided to return Object and clarify this is the doc (intellisense). So basically user need to do annoying type-casting. The-not-bad solution would be defining new class like "VerticesArray", which will be a bridge from .NET to native C++ and which will be handle internally any type of vertices.
and there are UpdateVertices and UpdateIndices methods which were introduced, because there is no write access with the Vertices property
That's right. Some distinct class (like i described above) would cover this too easily.
- in SceneNode the Children property returns an array, which can give bad performance, if e.g. a user just wants to know how many child nodes a node has
This is something that i added for being quite .net-ish
One of the "magics" of managed world is an incredible ability to debug things. When you set a break point and get all the info on the variable you can think of. The debugging becomes an easy process. Ofcause, having this method will make noob people to use it just to iterate nodes. But you still can get node by its index, get total amount of child nodes (just like native Irrlicht has it). This flaw (a "Children" prop) can be covered by making distinc class, which will implement IEnumerable and other necessary interfaces. It will ask needed node just when its actually needed.
P.S.: I'm okay with everything you wrote. Just keep in mind following:
- do not overthink on stuff, don't make it to be huge; if something is small and simple, it should remain that; if you cannot find the way to do it - better don't do it at all, because once done, we need to support that;
- do not make changes in native Irrlicht source even if you need a very small modifaction; because we will need to support that change throughout any Irrlciht changes; you can bump a thread on the forum asking devs to make the change; also such approach will let us update Lime in easy way - Lime is dependent only on Irrlicht' header files (and never source files);
- before adding anything new, keep in mind, that thing must be easy to use in C#, the user must not be able to make mistakes (ideally), so the class itself well-written, when you don't need to read any docs, because it just works as most of us would expect;
- please test changes running examples and compilling in different modes (x86, x64, Debug/Release);
- please keep documentation (intellisence) up-to-date; if soemthing wasn't documented (like all GUI namespace) than OK, but if you change some behaivior of the class/method in Video or Core namespace, please do not forget update the doc; remmember, as a .NET-ish programmer you might (just like i) like intellisence and its fill great when all necessary info on the thing-you-just-typing pops up right before your eyes; that is something which is very important not only for novices
