[DotGNU]DotGNU support for 3D and components?

[Martin Baker]

Hello,



My name is Martin Baker and I have just found this list, so please don't be
too hard on me if I my questions are not appropriate for this list.



I would like to ask:

1)     If DotGNU will be useful for my program?

2)     If I can contribute to DotGNU without diverting myself too much from
the field I'm working in?



My program is a 3D editor, I have two versions of the program, one written
in Java and another written in Managed C++ (.NET).

It is free software, and runs on local computer (not server based/web
services) see:

http://www.martinb.com/
http://sourceforge.net/project/showfiles.php?group_id=39341&release_id=80843



I'm interested to know if it will run with DotGNU? But more importantly I
would like to know if DotGNU will support a component architecture? And if
not, can I suggest it?

The reason I ask this is that conventional 3D editors (such as Blender for
example) tends to be a massive piece of software which causes a big barrier
for users and contributers. A potential contributor not only has to
understand 3D maths, 3D geometry, OpenGL concepts, the language that the
program is written in, etc. but also this massive piece of software.

What I would like to build is a set of components with well defined APIs.
Perhaps a core component, which contributors can use and support without
having to understand the internals of how it works. The writers of both the
core software and the additions can work as independent projects.

As an example of this, I am interested in 3D physics simulation. I would
like to be able to build a plug-in physics simulator which could interact
with other plug-ins written by other people which would control the way that
these models interact when they collide. I would like the plugins to be very
efficient (not a scripting language) and to be compiled independently of the
core components.

Would it be possible for people working on Open Source VRML editors such as
White Dune, CyberToolbox and myself to build a common core? Based on DotGNU
technology?

Other technologies which might do this.

On what technology/middleware should a common 3D graphics component should
be based? Currently my application is a set of java classes, where possible
using the java Beans standards.

In theory CORBA would be a better framework for a component 3D project,
because:

  1.. It is OS and language independent.
  2.. It works across networks, so it could be used for both single user and
multi user projects.
  3.. It allows new components such as new interfaces, to be discovered and
added at runtime.
  4.. Writers of add-on components do not have to re-compile the whole
project.
I have not experimented with it, but I suspect that it may not be practical
as:

  1.. Its complexity would discourage developers from working with it.
  2.. The remote procedure call interface would be a big overhead, and so
would not scale up to allow big meshes and textures to be sent between
components efficiently.
  3.. There would be a lot of setting up for end users, to set-up an ORB on
their local system. If its difficult for end users then it won't take-off.
Are there any lighter weight alternatives?

  1.. I quite like Java Beans, but it is single language and it is aimed at
adding components at build-time rather than run-time.
  2.. JINI ?
  3.. .NET technology (such as SOAP) which may be suitable as a lighter
weight component system but I have not investigated them.
  4.. Another alternative would be to define an API of our own, which would
specify a core functionality and a plug-in architecture. I think it would be
very difficult to make this language independent.
  5.. Another alternative would be, don't go for run-time plug-ins, but to
compile together the bits you want at build-time, for instance write
everything in C++ and distribute in the way Linux programs are?
  6.. Write everything in one language Java or C++. Then allow scripts to be
interpreted at runtime in other languages such as Python or JavaScript. I
suspect that runtime interpreters would not be very efficient for real-time
parts of the program if big meshes or textures were involved?
Although 5 and 6 are the conventional way of doing things, I dont think it
solves the problem described above.

Any ideas?

Martin