Will Xenko work for project with low-level access?

#1

I am redoing a project that I originally created in DX9 using the raw DirectX API for .NET so that it uses multi-threading and DX 11 It is mainly for experimentation in developing algorithms for simulating geologic processes. I wanted to focus more on the simulation than the graphics programming so I am considering a high level engine. The problem is that I need low level access to the models since I am using a custom high resolution sphere based on an ISEA grid with custom coloration. (Example: http://www.pyxisinnovation.com/pyxwiki/images/ISEA3H_Grid.jpg). I am not using textures or materials at the lowest levels… simply colored vertices (textures may eventually be used for very close-up views). For zooming out (LOD textures), the texture is developed using the grid itself, drawn at a lower grid resolution (for resolution details on this kind of grid see http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.558.9838&rep=rep1&type=pdf page 34). In my project, the color of each hexagon from moment to moment is determined by the simulation’s outcome.

I don’t want to deal with external scripts that are separate from the project or that use a different language from the project itself. I want to deal with .NET languages only (I use C# for simplicity and speed and am also capable of using C++).

#2

Yes, that should be fairly easy to accomplish. Xenko has an excellent low level api that is similar to raw DirectX. You can also write shaders and draw them on your own.

I’ve made an example of that on GitHub:

#3

Thanks for that. If I go with c# I will probably use it. I am still deliberating whether I will use .NET or going to c++ (non .net).

#4

i think C# is a much more productive language. you will be able to iterate and refactor much quicker with C#.

#5

Yes. I am familiar with the plusses and minuses of both languages. The bottom line is that I am probably going to end up translating the algorithms to C++ eventually anyway because it is more likely that the software that will use them will be in C++ because that software will prioritize processing speed and memory efficiency over refactoring time; so it is a factor of weighing the quickness of getting a working program (c#) versus the time it will take to rewrite the code for C++.

#6

C# has quite good interop with c++, you could do the setup and high level code in c# and do the heavy lifting of the algorithms in c++. That way you can re-use them later in the c++ application.

You only have to find good points to make the cut…

#7

You aren’t going to make any headway trying sell me on languages or engines in regard to the final target products. I have already told you the only issue that really matters in my scenario for the immediate future. My decisions regarding the eventuality of the target platforms is based on experience, needs, and a LARGE amount of research.

  1. I am already developing a graphics engine (with a custom memory manager) in C++ based on a modified version of Irrlicht for a platform that will eventually host a plugin which will be one use case that will involve the algorithms. This engine will have a plugin interface for C# but since the geologic processing itself requires “heavy lifting” as you say, there is no point in building an interface between C++ and C++. This platform will necessarily be built for Windows, Linux, MacOS, possibly OpenGL ES (for web browser integration), and possibly iOS (for use on Tablets, not phones).

  2. I have already built a program with an interface similar to the one you describe and it took nearly as much time and effort to develop it as it would have if I had wrote the entire thing in C++ (because it is already partly in C++ and one must add the wrapper classes).

  3. Another immediate use of the algorithms I am trying to develop is for commercial games that generate maps. When it comes to commercial games (or even large enough indie games), c# is just not as performance friendly as C++ so again, the graphics engines are generally in C++. Again, no point in developing in C# since the algorithms themselves will be faster in C++, unless the time necessary to get it up in running in C++ is too lengthy for my patience (which I am still debating).

  4. Other uses exist but they are not as immediate, are not part of my personal plans, and may or may not use c#.

My original question was posted because I had just made the decision to redo the original project and I was conducting research. I was impatient and wanted to get to work on it. However, the more I think about it, the more I think the smartest move in terms of saving time is to be patient.