the Fiddler.'s picture

Scope of OpenTK.Math

Continuing the discussion from the "Math module?" topic which has started growing too long.

Inertia said: This brings up an interesting question: What's the real scope of the mathlib?
I haven't really given this much thought, but the general idea was to build a set of functions useful for 3d graphics. Not physics or anything of that sort, but I can imagine it containing noise functions, geometric primitives (useful for bounding volumes, projections etc) or even a tri-strip generator. I don't have a concrete plan though, and this is not high priority stuff at this point.

What do you think the math toolkit should contain? Should it stay simple and focused (vectors, matrices, quaternions and that's it), or should it grow as needed by projects that use it?


Comment viewing options

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

To bump some concerns mentioned in the other thread:

  1. Immutable types
  2. Instance Methods
  3. Double precision floating point
  4. Dual Quaternions

From my perspective the mathlib's dimension is great the way it is, except for the few ref/out overloads and helpers mentioned in the other topic. Noise functions sound good too, especially a better random number generator than the .NET one would be a nice addition. What is the primary use for noise you have in mind? Heightfields for terrain?

I wouldn't turn down more complex primitives than my current plane/sphere/AABB testing, but be aware that it's alot of work.
The thing is, it's rather pointless to include geometric primitives without the ability to compare/test them for intersection. The permutations can become quite numberous if you go for more than just comparing them vs. planes (Frustum). This gets even more work if a simple boolean result is not enough and you're approaching collision detection.

To keep it a short Offtopic: If you are using VBO, triangle strips are nowadays less efficient than indexed triangle lists. With tri-strips it's not possible to fully utilize the graphic card's vertex cache without inserting alot of degenerate triangles into the mesh. tri-lists on the other hand do not care about topology of the mesh and allow the mesh to be further optimized for self-occlusion (e.g. draw torso first so that extremities - occluded by the torso - fail Z-test) all without inserting degenerate triangles.

the Fiddler.'s picture

It is my understanding that tri-strips are faster exactly because a) discarding degenerate triangles is trivial and b) even with degenerate triangles there is a net reduction in the number of indices (thus more data will fit in the vertex cache). I'm quite sure this still holds for newer cards but I don't have the tools to test right now. Will have do that at some point (XNA does have a test, and I think the Ati and Nvidia SDK's have some tools, too).

True it's a lot of work and there are more important parts to implement, but they would be nice to add some point (ray, plane, AABB, sphere). Some of these are already implemented in Mono.Xna so it is possible to lift some parts from there.

I've had to implement noise functions countless times over the years, so having some enhanced perlin at hand would be nice for heightmaps/clouds. I don't actually need this right now, but at some point I (or someone) probably will so sooner or later it will be implemented.

[Instance Methods]
This, along with the missing interfaces (IEquatable, IComparable) are the most important missing parts right now. The bad part is that I have my hands full at the moment (a large documentation release is coming). The good part is that these are quite easy to implement, so I'll probably do at some point soon.

nythrix's picture

from the other thread:
Should it become a full replacement for Math.Net or Collision/Physics SDKs?
Collision, physics and primitive handling, you say? I smell game/graphics engine here. Is OpenTK going that way? I mean, sure all this stuff is useful but will you actually use it in your own code? Or will you replace it with something that suits you better? We all need low level OpenGL. But not everyone needs (standard) collision detection or primitive handling.
This is not a hot issue so I think we can wait for now.
[dual quaternions]
Rotation & translation is all I need. In fact, I'm removing scaling support from my engine. I get slightly faster execution, happier normals and cleaner teeth :D

I say stay simple.

Inertia's picture

a) You are still assembling a primitive just to cull it and with the added degenerate triangles the Indicies count is higher than n+2 for n Triangles. It's also problematic with unculled transparent geometry, since you will see the lines. This could maybe be worked around with a geometry shader.
b) I wish there was some good documentation about the vertex caches to quote from, but AFAIK the data stored in GL_ELEMENT_ARRAY_BUFFER is never cached anywhere. The GL_ARRAY_BUFFER itself would be identical for a tri-strip and tri-list. There's the Pre-T&L-Cache (around 64k entries on GF6, preferably 32 Bytes aligned) whos only purpose is to keep a copy of the memory block - where the requested vertex was located in - in fast memory, because more accesses to it's neighbours are expected (like the CPU's L2 cache). The Post-T&L-Cache (24 entries for GF3) is the more interesting one, since it will skip the whole vertex processing in case of a cache hit.
Long story short: This is a rather vivid area of research and what's awesome today is outdated in a month or 2. I wouldn't really recommend including this into OpenTK. nVidia provides a nvtristrip tool and Ati provides Tootle for this task.

Don't forget the 2D versions, which would be in demand too. I'm not certain if it should be OpenTK's responsibility to provide this.

...full replacement for Math.Net or Collision/Physics SDKs?
That was a bit exaggerated to show some extremes, not a demand. You're using OpenGL for realtime 3D and not performing any broad Frustum culling? I see that not every app needs collision detection, but most apps need some sort of visibility culling.

[dual quaternions]
Rotating a vector3 by a quaternion is slower than rotating it by a matrix. It sure is more compact in memory, but considering the amount of matrices sent to the graphics card per frame the bandwidth used is imho neglectible.

nythrix's picture

You're using OpenGL for realtime 3D and not performing any broad Frustum culling?
It's large-scale terrain culling in my case. Should OpenTK provide the means for it?

[dual quaternions]
You have a point here. However a) matrices need heavy reorthogonalization from time to time and b) interpolating dual quaternions should be faster. Disadvantage is, I have to convert them to matrices anyway and feed the graphic card. I have to do some testing to prove all this though.

Inertia's picture

Should OpenTK provide the means for it?
Never the hierarchy itself, the only thing I would consider are simple AABB/Plane types as building blocks for your custom (tree) hierarchy. I'm very unsure if this is desireable to include into the mathlib tho, the implementation itself is trivial but the kinds of primitives required will vary from app to app and can quickly become numberous. It will be quite some enterprise trying to satisfy everyone's needs.

[dual quaternions]
Misunderstood you there, I was assuming you're sending the Quaternions as uniforms to a shader instead of a matrix.

JTalton's picture

* Immutable types
* Double precision floating point
I currently have an implementation of an immutable double precision class which I am using. I would rather use something that is built in nicely with OpenTK. (i.e. you can current pass a OpenTK.Math.Vector to GL.Vector3) While most people are not going to be using double precision, I am making a model editor that needs it. If no one else if planning on working on it I would be interested in doing both of those.

* Collision Detection
I would like to see basic collision detection algorithms. I have a few already written in C#. Basic line to plane intersection and such.

* Noise
I have some C++ implementations of perlin noise, both repeating and non-repeating. I was planning on porting those to C# and contributing them.

objarni's picture

I think this is a really interesting and important discussion.

What is the scope of OpenTK?

I have two words to say in this discussion: avoid bloat. It is the killer of libraries..

For me, OpenTK should be a thin, idiomatic (enums and such) wrapper around OpenGL+OpenAL+windowing/os-events. Nothing more. While I view linear algebra types handy for communicating with GL (and AL in the future I guess), I can't see what perlin noise, AABBs or any mid-to-high-level algorithms and structures has any place in OpenTK.

Keep it simple, please. If I wanted a feature-rich library, I'd go for Irrlicht, Ogre or Torque. But I want the basics, the rest I'll code myself.

One way to do this is by separating such things into, say, OpenTKU (utilities).

my two cents,

the Fiddler.'s picture

I feel that code which interacts directly with OpenGL functions belongs in the core library (this includes for example double precision vectors, but excludes collision detection). Splitting into core + utilities libraries is , I think, a good idea. What belongs were might be a little debatable but something like the following could work:

  • OpenTK.dll: OpenGL, OpenAL, Platform (contexts, input) and core Math (Vectors, Matrices, Quats)

  • OpenTK.Utilities.dll: Fonts, geometric primitives, noise functions etc
  • OpenTK.GLControl.dll: Windows.Forms integration
  • OpenTK.GLWidget.dll: GTK# integration.
  • OpenTK.GameWindow.dll (?)

The reason for splitting the windowing toolkits out is that a) they bring additional dependencies and b) you are unlikely to use more than one at the same time. On the other hand, it would be nice to have a single integrated dll that is useable on its own (which should include at least one way to create an OpenGL window).

The thing is, OpenTK aims to be more than a simple wrapper but short of a 3d engine. That is, it should include commonly used functionality (like fonts!) but be low-level enough that it doesn't get in the way of building a higher level system. It's a fine line to tread, hopefully it will work out in the end.

@JTalton: do contribute the code you have!

objarni's picture

Thumbs up. Making dependencies explicit is a good thing.

Of course, the price to pay is the lost dream of "one single dll to suit them all". Maybe it's worth it? I don't know. Maybe both worlds can coexist via build script: giving rise to OpenTKBundle.dll? I don't know how much work this is either.