Re: [DotGNU]DotGNU support for 3D and components? [LONG]

[Gopal V]

If memory serves me right, Martin Baker wrote:
> so please don't be too hard on me if I my questions are not 
> appropriate for this list.

Hey, don't worry ... we never wage war on newbies or tough guys :-)

Note: A long mail deserves a long answer :-)

> 1)     If DotGNU will be useful for my program?

I will a "How" part below ... 

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

Of course , you could try to find out the bugs you encounter (if any)
Or implement critical peices of the library you need.

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

Does it use OpenGL or DirectX ?. (DirectX does not seem to possible here)

If the program is in Managed C++ , does it use Microsoft.VisualC.dll
too much ?. (/me does not understand what "too much" is in this context)

> It is free software, 

you're one of us :-)

> I'm interested to know if it will run with DotGNU? 

Managed C++ uses a lot of the pointer instructions , but these are
part of the ECMA spec (IIRC) ... So apart from the Microsft.VC.dll
you should have relatively few issues with the IL code.

> But more importantly I would like to know if DotGNU will support 
> a component architecture? And if not, can I suggest it?

I don't really understand what you mean by component architecture ...
Personally modular code with functional seperation between the C#
assemblies does the component stuff for me :-)

That allows you to specify an abstract design and extend inside a
class and obtain that object from a static method somewhere in that
assembly ... (which is what COM does for C++). Inhertiance can be
used to acheive this if properly handled... 

> 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.

Yow !! ..

> 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.

I think you are on the right track here .... (Hey, I'm poor on planning
and design , but I know a good developer when I see it :-) ...

For example I do not understand fully how the Portable.Net compiler works
but I'm able to put a feature here and there (10-50 lines) thanks to Rhys'
design and "Aspect Oriented" tool Treecc to manage the C code in a well
defined hierarchy ... (so when I hack ILNode_ForeachCollection , I can 
ignore how the compiler handles class definitions and do my patch and 
most of the time it works well ;-)

> 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. 

Something like a sort of Object1.Collide(Object2) will automatically
sort out the velocities , angles and elasticity coefficents for both bodies ?

So you could declare a abstract SolidObject and allow everyone to extend
it to behave as they like it .... But with a definite API for getting
the collision variables ... (/me hopes you like my class names)

Read down for plugin API stuff....

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

Of course if you do agree on an API  (of course ... everyone should sit down
and design ) ...

> Currently my application is a set of java classes, where possible 
> using the java Beans standards.

Well you could have similar standards if you propose them for DotGNU 
and use stuff like Attribute support for C# to optimal use :-)

/me doesn't like the Managed C++ idea (A java guy would go for C# first)

>   1.. It is OS and language independent.

DotGNU "Portable".Net ? 
(From Cygwin to Hurd with Solaris , HPUX and others on the way)

Unfortunately it revolves too much around C# :-( .. But we'll
figure out some way to solve that problem soon.

>   2.. It works across networks, so it could be used for both single user and
> multi user projects.

DotGNU Portable.Net still has to support Remoting .... that would make
it possible to use C# over Corba/XMLRPC without Java's complications ..
I'll leave experts to talk about this in more detail ......

>   3.. It allows new components such as new interfaces, to be discovered and
> added at runtime.

Slows life down quite a bit , doesn't it ?

>   4.. Writers of add-on components do not have to re-compile the whole
> project.

Well you could compile each addon component as a seperate assembly ... 
and achieve this same purpose ... 

>   1.. Its complexity would discourage developers from working with it.

Dunno about that , it seemed too complex to even take a look :-)

>   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.

Binary data ? (that is a problem for XMLRPC/SOAP to transmit....)

>   3.. .NET technology (such as SOAP) which may be suitable as a lighter
> weight component system but I have not investigated them.

Why go in for SOAP when you could dynamically load any class/assembly 
from file ?

I think Rhys's I18N code uses dynamic loading of the correct encoding 
at runtime (correct me if I'm wrong)

>   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.

Not if it is in IL , but that would tie life down to C# and other .NET 
languages ... And always you can wrap C in C# without much difficulty
(PInvoke == just keep the name same :-)

>   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?

Well that is a practical possibility when your code is GPL'd and anyone
can compile it on their box (and taking 1 hour to do it fully)....

I wonder if a big project like Mozilla would try this approach ;-)

>   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?

> Any ideas?

[-OUT-OF-THE-WAY-IDEA-]

How about embedding the C# runtime in the C++ engine ?... And calling
the C# plugin methods via a helper function in C .. See my efforts
at bridging C# and Python with C ...

http://symonds.net/~gopalv82/code/pnet-python.tgz

Python => C => C# (IL)

But that might be a complicated example due to python's function invocation
model (VAR_ARGS, as a tuple and unpacking it).

[-END-OUT-OF-THE-WAY-IDEA-]

[-PRACTICAL-IDEA-]
The other idea is to use an openGL platform for C# (I remember something
called CSGL) .

Make all the plugins/components as pluggable with a configuration file 

<Foo:Bar:Conf>
<Foo:Bar:Physics image="Foo.Bar.ParticlePhysics.dll" 
name="Physics Simulation Module" sp_name="physics"/>
</Foo:Bar:Conf>

/me might be a wee bit obsessed with XML namespaces ;-)

Or maybe use a compiled .dll to hold this file ?. (I have used that with 
Java). Foo.Bar.Conf.dll would hold the compiled configuration file...

Maybe if Reflection.Emit is fully functional , we could even use a custom
program to generate the .dll rather than .conf->.cs->.dll pathway....
(I have used Serialization for that in Java)

Perhaps someone from DotGNU-Base might just dream up a Registry or 
similar class for storing hierarchical databases (in XML ?) . That
would make it a little bit easier on your part for configuration
management.

And for the plugins maintain a PluginInfo class for each assembly to
store the information about the plugin classes and all that .....
(as well as the library entry point, consider it as a dynamically loaded 
BeanInfo class)

Last but not least use csdoc or similar tools to document like you did
with Javadoc (now look back and realize that C# is a cheap ripoff of Java)

[-END-PRACTICAL-IDEA-]

Hope that helps you , 

Gopal

PS: If you want some more info , please mail me offlist or onlist 
    and read my "certified to be crazy" ideas 
-- 
The difference between insanity and genius is measured by success