Previous Thread  Next Thread

chat icon Project Mojo ~ Blender on Mono

JesseM

Posted: Fri Feb 10, 2006 1:59 am
Joined: 10 Feb 2006
Posts: 4
Over the last several months I've gotten a growing interest in the Mono project. I've always been a fan of Blender, and I had noticed that there weren't a lot of high end graphics API's on the .Net platform as of yet. I had gotten the idea in my head to export the Blender scripting API to the CLI using much the same method that Blender already uses for Python, therefore launching Blender into the .Net world. This benefits .Net developers in general --and Mono developers in particular, by providing them with an incredibly rich modelling environment. It also benefits Blender in much broader way.

The Mono platform already supports Python scripts, so that all Blender scripts written in Python are instantly reusable. Having the Blender API in Mono also alows Blender to be scripted in any language supported by Mono, such as C# and Java (and the list is growing).

The one who benefits most are developers. Imagine: A game development company uses Blender for it's modelling. It's scripts are written in a combination C++, Python and C#, which are compiled into managed CLI bytecode, deployed and executable on any vm. The blend file format is naturally portable already. The developer could write an entire game using Blender and Mono and be able to deploy on any OS (Windows, Linux, MacOSX) with a single distribution.

I think there is sufficient cause for such a project to motivate it's undertaking. I myself am curious enough about it in theory to at least give it a best attempt.

The purpose of my post was not for motivation since I'm going about it regardless. I was hoping some developers more experienced with the Blender source code and scripting API could offer advice on where the best place to start would be. For example: how I might go about compiling the Blender source into shared libraries rather than executables, and what sections in the sources deal with the Python bindings (so that I may go about altering those).

I thank you in advance for any feedback.
Reply with quote


LetterRip

Posted: Fri Feb 10, 2006 3:52 am
Joined: 25 Mar 2004
Posts: 1462
Hmm, I have a hard time seeing how this would be of particular benefit to Game Devs or to Blender. As you note Blender is already completely cross platform. The hypothetical game developer would only be writing an exporter for Blender, the only benefit I can see from their perspective would be if they don't know python, but being able to write the exporter in their prefered language binding is of insignificant benefit. The game engine API is planned to be abstracted so that any GE can be integrated with Blender for ease of testing and development. Personally I would think that your other Blender plan of OpenML support for Blender might be a better use of your time.

Regarding your questions, python bindings are done in

source/blender/python/api_2_2

not sure how to compile dlls instead of .exe

LetterRip
Reply with quote


JesseM

Posted: Fri Feb 10, 2006 5:50 am
Joined: 10 Feb 2006
Posts: 4
The same argument could be made for Mojo as was made for Gtk#. We could be arguing "Why launch Gtk+ into Mono when it works well now?" And the obvious answer is "It enhances Mono".

If you are looking at it from the perspective of a Blender user (which I'm sure you are) then it doesn't provide any immediate benefits or feature enhancements (other than the ability to script in C# or Java which is of greater credit than you give it).

From the vantage point of a Mono user there is now a whole arena opened up. Without it a Mono developer is forced to reinvent the wheel by writting a scene graph from scratch in some CLI language. Why do that when an extremely rich and powerful tool already exists in Blender? Although the benefits to Blender may not be immediate, it does open Blender up to a larger arena, and certainly does nothing to hurt Blender in the short term. Given time both parties will have benefited from their mutual trade.

The broad scope behind this is integration, which seems to be the way the industry is moving, as is evident by both the coming of .Net and the actions of the Mono project. We take the best of what already is and give them greater scope by porting them to a new platform. If you know Mono at all then you know it is an incredibly robust development platform.

What I'm concerned with primarily is not the above, but whether or not it can be done, simply because I think it's a cool idea. Isn't that the guh-noo way?
Reply with quote


stiv

Posted: Fri Feb 10, 2006 7:17 pm
Joined: 05 Aug 2003
Posts: 3645
Quote:
Having the Blender API in Mono also alows Blender to be scripted in any language supported by Mono, such as C# and Java (and the list is growing).


The biggest fly in this ointment is that there *is* no Blender API.

Python scripting is done thru an embedded interpreter that directly manipulates Blender's database.
Reply with quote


an-toni

Posted: Fri Feb 10, 2006 10:01 pm
Joined: 17 Mar 2004
Posts: 250
yep, Blender is an application and not a library, so it can not be compiled to a .so or .dll

i started experimenting with compiling it to a Python module (i.e. a c written library) 2,5years ago but only tested a little .. i think it is possible, but even then as the internal code relies on globals and is context dependent it wont work like libraries usually.

luckily the app is nice Smile

~Toni
Reply with quote


JesseM

Posted: Wed Feb 15, 2006 10:42 pm
Joined: 10 Feb 2006
Posts: 4
The biggest fly in this ointment is that there *is* no Blender API.
As I've already stated, I'm refering to Blender's Python interface.

yep, Blender is an application and not a library, so it can not be compiled to a .so or .dll
If I haven't stated this explicity yet: I expect to have to modify the source to accomplish this. The first relevant hurdle to overcome is in how fundamental or supperficial the changes need to be. Blender would not be the first application to be abstracted into a library (e.g. how libglade emerged from Glade2).

Consider how much of Blender has changed in the "2,5years" since your attempt. Even if there is a few globals lingering around (which are bad practice to begin with), if the project leaders properly encapsulated everything (as is good practice) the code changes would trully be supperficial. Given this information from the first respondent The game engine API is planned to be abstracted so that any GE can be integrated with Blender for ease of testing and development. I would say that this particular task wouldn't seem terribly difficult.

The second great hurdle is on the .Net side of things; constructing an object model around the interface which properly reflects the way managed code operates, and working around the idiosyncrasies that mount when dealing with pointers. As I've been told from the Mono forums regarding this same subject, such foreign imports (i.e. OpenGL, OpenAL and Ode under Tao) are managable because they do not operate with memory references directly. Conversely the Gtk# bindings are complex. In this regard I can still deal with the C-API headers which Blender uses to wrap it's C++ functionality, make those modifications as necessary, and permit Mono's 'DllImport' 'Marshal' and 'Platform Invoke' to build the CLI portions. The object model would be familiar to that of the Python API so there would be little learning curve.

The problems involved in this project are logisitical, not fundamental in their nature. So far I have not come across any prohibitively complex issues, nor have I lost heart for the merit of this project (or the motivation to pursue it).

A similar project to what I have in mind is the Axiom Engine (http://www.devmaster.net/engines/engine_details.php?id=81) which is a .Net porting of the Ogre Engine using Mono. There are only two differences between that and this: (1) Ogre is written in pure C++, which actually makes the binding more difficult in one sense (2) Ogre was intended to be a library, which makes it easier in the other sense.

At it's most basic, if you wish to think of it this way, it only really involves an abstraction and a binding, both of which are entirely reasonable. The benefit, as I've endeavored to explain, is portability --not necessarily between platforms, but by scope, as Blender would reach more developers and more targets.
Reply with quote


an-toni

Posted: Fri Feb 17, 2006 12:52 am
Joined: 17 Mar 2004
Posts: 250
ok. i dont know if i will ever need Blender# but who knows - good luck with the project, and feel free to bug ppl about it here Smile

~Toni
Reply with quote


cseder

Posted: Wed Sep 26, 2012 4:20 pm
Joined: 01 Jun 2012
Posts: 10
I think it would be a great thing to have Blender#

Combine this with MonoGame, and we have a nice platform I think.
_________________
Remember, the time is NOW!
Reply with quote


stiv

Posted: Thu Sep 27, 2012 12:16 am
Joined: 05 Aug 2003
Posts: 3645
Are you aware you are replying to a six year old post?
Reply with quote


cseder

Posted: Thu Sep 27, 2012 12:39 am
Joined: 01 Jun 2012
Posts: 10
stiv wrote:
Are you aware you are replying to a six year old post?


Yes.
But there are still no Blender#

Rolling Eyes
_________________
Remember, the time is NOW!
Reply with quote


 
Jump to:  
Powered by phpBB © 2001, 2005 phpBB Group