[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DotGNU]DotGNU support for 3D and components? [LONG]
From: |
Gopal V |
Subject: |
Re: [DotGNU]DotGNU support for 3D and components? [LONG] |
Date: |
Sun, 28 Jul 2002 21:50:55 +0530 |
User-agent: |
Mutt/1.2.5i |
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