glebedev's picture

Separate Math into assembly

Hi, all.

Since other parts of library depend on math, but math is independent itself, it could be usefull to separate it.


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
the Fiddler's picture

What is the advantage of the current state?

It's simple, really:

using System;
using OpenTK;
z = Math.Max(x, y);

This didn't compile before the change. Now it does.


Then there's .NET's "give classes and namespaces different names". Still, any resulting clashes are restricted inside the library and can be avoided by simply using OpenTK.Math; in affected files.

Not true, see above.

In other words, OpenTK.Math caused a constant and irreversible namespace conflict with System.Math. Weighted against a potential conflict with a 3rd-party library, I think the conflict with a system class is much more significant.

nythrix's picture

Wait, what?
Just to make sure we're on the same wavelength here.
Let's say, I'm developing something on top of OpenTK. Then the following is perfectly valid:

// OpenTK.dll
namespace OpenTK
{ public class CoreClass { } }
namespace OpenTK.Math
{ public class MathClass { } }
// end of OpenTK.dll
namespace MyProgram
    using System;
    using OpenTK;
    public class Launcher
        public static void Main()
            int x = Math.Max( 1, 2 );            

So, the only place where we face the problem is inside the OpenTK namespace/library. Which means half of my statement still holds. But you're right in that, I can't fix it the way I said. I have to specify either OpenTK.Math or System.Math every time.

Now, suppose you're a postman delivering into a building that houses two guys with the same name/surname. In order to make your job easier you certainly don't shoot one of them and deliver all the mail to the other guy's box. But you could ask one of them to tell his mailers to add additional info to his address (apt number).

A nice solution to most problems would be OpenTK.Calc.

migueltk's picture

Hello everyone, ...

No math is necessary to move to another assembly, a solution may be provided by nythrix, create a namespace to avoid ambiguity OpenTK.Calc.
This certainly seems the best solution and what is done in XNA should not influence at all in this or another open source project.

Hortus Longus's picture
migueltk wrote:

... what is done in XNA should not influence at all in this or another open source project.


JeffM2501's picture

Having math in a seperate assembly would be a benifit for games that uses a network server.

It is rather handy to have access to the OpenTK math on the server, a place where you don't need any kind of graphics or openGL (in fact on a headless machine that may not even have X ). It would make it easier to create simulation components that use OpenTK math that get shared on both the client and server (player/shot positions etc..). Using a third party math lib would make it harder to take the results of said shared components and use them with OpenTK drawing code on the client (i.e. my player sim class on the client feeds it's computed position directly into the drawing system, and on the server it just tracks it in a state).

Math may be heavily used by the graphics, but it's also useful for other things that are totally separate from a drawing app :)

I understand that a minimal OpenTK could be built for the server (using Mono), but that adds more setup cost to the server, and gets away from one of OpenTK's strong points, ease of use/deployment.

Just my 0.02$USD

Jeffery Myers
A silly experiment in C#

Hortus Longus's picture


@the Fiddler:
Looks like as if you would have found the ultimative Math-solution. ;-)

Two things you can do to make it simple:
1.) build your own DLL from the Math-folder; or
2.) copy the Math-folder into your project, add "using OpenTK;" to your project and use it.
Where is the problem?

The most fundamental problem in software development is complexity. There is only one basic way of dealing with complexity: Divide and conquer.

objarni's picture

The documentation index says "OpenTK.Math" at least :)

golkeeper's picture

My vote is for separate math dll. IMHO if one develop graphical engine/renderer, he or she would prefer to encapsulate opentk/opengl interaction. Client interface of such renderer use various math types to specify transformations and so on. Conventions like "client app should not use any opentk functionality other then math" is not encapsulation.
Writing a math lib specially for this interface is boring and unnecessary:). Building Math lib from part of OpenTK source is not very convenient and looks like a hack.

So, what about leaving OpenTK.dll with math incorporated and providing math-only build option in OpenTK build system?