Posted Wednesday, 21 October, 2009 - 11:35 by the Fiddler

For better or worse, OpenTK is shipped as a monolithic dll. I can understand why a physics engine or a loader might not wish to reference a large dll just to use a small part of it, however:

this hasn't stopped anyone from referencing all of XNA just to use its math library, which also happens to be integrated into the main dll.

if size is a concern, this be solved using the Mono Linker. The resulting OpenTK.dll will contain only the code you are actually using (a few KB).

That said, I would not object to an OpenTK.Math project that contains just the math library - provided someone is will to create and maintain this. Math-only projects like loaders or physics engines could then reference this instead of the whole library, but it would be trivial to switch as necessary.

The math branch contains some interesting structs that could be pretty useful for such a project (I simply haven't had the time to clean them up and merge them with OpenTK).

Posted Friday, 27 November, 2009 - 20:42 by migueltk

Hello

Should be considered separately mathematics classes in a namespace such as "OpenTK.Math", currently under OpenTK version 1.0 beta-2, they are in space OpenTK root.
This causes extra work to avoid name collision when developing a mathematical library itself.

Posted Friday, 27 November, 2009 - 23:55 by the Fiddler

I am not following, how does this affect the development of a different math library? In fact, why would a mathematical library even reference OpenTK?

This might be slightly annoying for consumers of both OpenTK and the other math library - but this is also the case with XNA and any other similar project. Just remove the "usingOpenTK;" statement wherever necessary and the namespace clash will go away.

Posted Wednesday, 9 December, 2009 - 00:51 by pjcozzi

Hello,

I can imagine two uses for a separate math assembly. One would be because an application is divided into multiply assemblies itself and some assemblies want to use OpenTK's vector, matrix, etc but they do no want to depend on all of "graphics." You can imagine assemblies that implement spatial data structures or computational geometry algorithms would fall into this category.

Another use case could be an application that presents an abstract renderer interface. The interface may want to use OpenTK vector and matrix types but it doesn't want its clients to depend on all of OpenTK. Perhaps one implementation of its renderer uses OpenTK and another uses XNA or a software implementation.

Posted Thursday, 10 December, 2009 - 22:22 by the Fiddler

Yes, but what would you actually gain by using a separate math assembly? Reduced download size? In other words, why not include the whole OpenTK.dll and just use the parts you wish?

If this is actually about size there's more to gain using mono-linker, a tool that reduces dependent assemblies to their bare essentials (the resulting dlls only contain code you actually call).

Posted Friday, 11 December, 2009 - 12:49 by pjcozzi

the Fiddler wrote:

Yes, but what would you actually gain by using a separate math assembly? Reduced download size? In other words, why not include the whole OpenTK.dll and just use the parts you wish?

Actually, I wouldn't be surprised if the download size became slightly larger by creating a separate math assembly, unless the application only needed to include the math assembly. The real benefit is the added flexibility to an application's architecture. For example, an application might want to standardize on OpenTK's vector and matrix types, and it might contain an assembly that just does number crunching with those types (e.g. think computational geometry algorithms). This assembly shouldn't have to depend on "graphics", it doesn't need to know anything about OpenGL, etc. It should just depend on "math."

With that said, I'm not sure if the benefit outweighs the costs for OpenTK. Having one assembly is simple and clean. If an application really cares about the situation I describe, they could just make their own math assembly.

I am just describing the trade-offs; I'm not necessarily in one camp or the other.

Posted Friday, 11 December, 2009 - 19:02 by nythrix

This topic is being discussed in private as well:

nythrix wrote:

I get your points. As for math however, I'd like to outline that it currently shares namespace with all sorts of different things like exceptions, NativeWindow, DisplayDevice, InputDriver, FrameEventArgs, VSyncMode, KeyPressEventArgs, BlittableValueType and more unrelated stuff. Rather messy I'd say. Heck, INativeWindow and BezierCurve shouldn't be in the same namespace even if a project has 3 classes at most :) But you probably see where this is going already.

If for any reason, I'm using another math library (and let's be honest all of them have names like Vector, Matrix, etc.) I will face ambiguities while never explicitly asking for OpenTK math. Which isn't good. So I have to:
1) specify all of the above non-math items with OpenTK,
2) specify my own math structs with MyMathLib
3) or both of the above
because I can't just include the two namespaces. This introduces inconsistent looking code where some types are fully specified and others are not.

Math used to reside in OpenTK.Math and it was a much cleaner solution. Not that I'm propagating a dll split. But a math relocation inside the dll would be nice, I think.

Fiddler wrote:

Consider that XNA also places math structures directly to the root namespace, so this can't be that bad a design! Also note that OpenTK.Math (namespace) used to clash with System.Math (class) which was arguably even more evil (and against the class library design guidelines - linky).

Finally, the root namespace *is* a namespace, which means you can avoid namespace clashes simply by avoiding using OpenTK; wherever necessary:

using MyMathLib;
using OpenTK.Graphics.OpenGL;

Vector3 v = new Vector3(); // No problem!
GL.Vertex3(v.X, v.Y, v.Z);

The only downside is that you can no longer access the convenience overloads for Matrix4, Vector[234], etc - but there's nothing OpenTK can do about this.

While I'm absolutely neutral to the separate Math.dll idea, I would prefer having math out of OpenTK namespace and back into OpenTK.Math namespace. Just like it used to be before 0.9.9 (or 0.9.8?) came along. Maybe this is all subjective but as I pointed out before I find OpenTK quite littered.
The point that XNA has the same solution is pretty weak at best. That's implementation-driven progress and it strongly resembles the Unix' path to hell back in the days.
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 usingOpenTK.Math; in affected files. And, as far as I remember, this library has promoted outside-friendliness against inside-friendliness while delivering the same set of functionality.
[Edit]

Fiddler wrote:

This might be slightly annoying for consumers of both OpenTK and the other math library - but this is also the case with XNA and any other similar project. Just remove the "using OpenTK;" statement wherever necessary and the namespace clash will go away.

This is absolutely unnecessary. In fact, as I wrote before, there used to be no name clashes two or three versions ago because people with their own math modules safely ignored OpenTK.Math since it contained... well... only math.
[/Edit]
Maybe my points and other's are not so strong as we'd wish. So, let me backfire the question, Fiddler. What is the advantage of the current state?

## Comments

12next ›last »## Re: Separate Math into assembly

What would be the benefit of that?

## Re: Separate Math into assembly

Some other libraries could share same math assembly: physics engines, quake BSP loaders, some other similar stuff.

Math is stable for a long time, and other OpenTK parts are under development.

## Re: Separate Math into assembly

For better or worse, OpenTK is shipped as a monolithic dll. I can understand why a physics engine or a loader might not wish to reference a large dll just to use a small part of it, however:

That said, I would not object to an OpenTK.Math project that contains just the math library - provided someone is will to create and maintain this. Math-only projects like loaders or physics engines could then reference this instead of the whole library, but it would be trivial to switch as necessary.

The math branch contains some interesting structs that could be pretty useful for such a project (I simply haven't had the time to clean them up and merge them with OpenTK).

## Re: Separate Math into assembly

Hello

Should be considered separately mathematics classes in a namespace such as "OpenTK.Math", currently under OpenTK version 1.0 beta-2, they are in space OpenTK root.

This causes extra work to avoid name collision when developing a mathematical library itself.

Thanks, greetings ...

## Re: Separate Math into assembly

I am not following, how does this affect the development of a different math library? In fact, why would a mathematical library even reference OpenTK?

This might be slightly annoying for consumers of both OpenTK and the other math library - but this is also the case with XNA and any other similar project. Just remove the "

`using OpenTK;`

" statement wherever necessary and the namespace clash will go away.## Re: Separate Math into assembly

Hello,

I can imagine two uses for a separate math assembly. One would be because an application is divided into multiply assemblies itself and some assemblies want to use OpenTK's vector, matrix, etc but they do no want to depend on all of "graphics." You can imagine assemblies that implement spatial data structures or computational geometry algorithms would fall into this category.

Another use case could be an application that presents an abstract renderer interface. The interface may want to use OpenTK vector and matrix types but it doesn't want its clients to depend on all of OpenTK. Perhaps one implementation of its renderer uses OpenTK and another uses XNA or a software implementation.

Regards,

Patrick

## Re: Separate Math into assembly

Yes, but what would you actually gain by using a separate math assembly? Reduced download size? In other words, why not include the whole OpenTK.dll and just use the parts you wish?

If this is actually about size there's more to gain using mono-linker, a tool that reduces dependent assemblies to their bare essentials (the resulting dlls only contain code you actually

call).## Re: Separate Math into assembly

Looks like a popular topic this one :D

## Re: Separate Math into assembly

the Fiddlerwrote:Yes, but what would you actually gain by using a separate math assembly? Reduced download size? In other words, why not include the whole OpenTK.dll and just use the parts you wish?

Actually, I wouldn't be surprised if the download size became slightly larger by creating a separate math assembly, unless the application only needed to include the math assembly. The real benefit is the added flexibility to an application's architecture. For example, an application might want to standardize on OpenTK's vector and matrix types, and it might contain an assembly that just does number crunching with those types (e.g. think computational geometry algorithms). This assembly shouldn't have to depend on "graphics", it doesn't need to know anything about OpenGL, etc. It should just depend on "math."

With that said, I'm not sure if the benefit outweighs the costs for OpenTK. Having one assembly is simple and clean. If an application really cares about the situation I describe, they could just make their own math assembly.

I am just describing the trade-offs; I'm not necessarily in one camp or the other.

Regards,

Patrick

## Re: Separate Math into assembly

This topic is being discussed in private as well:

nythrixwrote:I get your points. As for math however, I'd like to outline that it currently shares namespace with all sorts of different things like exceptions, NativeWindow, DisplayDevice, InputDriver, FrameEventArgs, VSyncMode, KeyPressEventArgs, BlittableValueType and more unrelated stuff. Rather messy I'd say. Heck, INativeWindow and BezierCurve shouldn't be in the same namespace even if a project has 3 classes at most :) But you probably see where this is going already.

If for any reason, I'm using another math library (and let's be honest all of them have names like Vector, Matrix, etc.) I will face ambiguities while never explicitly asking for OpenTK math. Which isn't good. So I have to:

1) specify all of the above non-math items with OpenTK,

2) specify my own math structs with MyMathLib

3) or both of the above

because I can't just include the two namespaces. This introduces inconsistent looking code where some types are fully specified and others are not.

Math used to reside in OpenTK.Math and it was a much cleaner solution. Not that I'm propagating a dll split. But a math relocation inside the dll would be nice, I think.

Fiddlerwrote:Consider that XNA also places math structures directly to the root namespace, so this can't be that bad a design! Also note that OpenTK.Math (namespace) used to clash with System.Math (class) which was arguably even more evil (and against the class library design guidelines - linky).

Finally, the root namespace *is* a namespace, which means you can avoid namespace clashes simply by avoiding using OpenTK; wherever necessary:

using MyMathLib;

using OpenTK.Graphics.OpenGL;

Vector3 v = new Vector3(); // No problem!

GL.Vertex3(v.X, v.Y, v.Z);

The only downside is that you can no longer access the convenience overloads for Matrix4, Vector[234], etc - but there's nothing OpenTK can do about this.

While I'm absolutely neutral to the separate Math.dll idea, I would prefer having math out of

`OpenTK`

namespace and back into`OpenTK.Math`

namespace. Just like it used to be before 0.9.9 (or 0.9.8?) came along. Maybe this is all subjective but as I pointed out before I find`OpenTK`

quite littered.The point that XNA has the same solution is pretty weak at best. That's implementation-driven progress and it strongly resembles the Unix' path to hell back in the days.

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. And, as far as I remember, this library has promoted outside-friendliness against inside-friendliness while delivering the same set of functionality.[Edit]

Fiddlerwrote:This might be slightly annoying for consumers of both OpenTK and the other math library - but this is also the case with XNA and any other similar project. Just remove the "using OpenTK;" statement wherever necessary and the namespace clash will go away.

This is absolutely unnecessary. In fact, as I wrote before, there used to be no name clashes two or three versions ago because people with their own math modules safely ignored

`OpenTK.Math`

since it contained... well... only math.[/Edit]

Maybe my points and other's are not so strong as we'd wish. So, let me backfire the question, Fiddler. What is the advantage of the current state?

12next ›last »