Wishlist

Sorry, SF is counter-productive >< Should probably use IRC/IM to discuss such topics rather than using the forum.

Thank you very very much! At least static models render properly now :-)

http://opentk.sourceforge.net/home/system/files/Coke.jpg

P.S. you should probably delete this topic, I cannot edit the cited source code which is not working.

Yeah, the link is correct. I can only edit posts without replies, and the initial post if I started the topic. Thanks for changing it.

The image is correct, it shows 2 layers. The solid can and a couple of LineLoops drawn ontop of it (the centers of all triangles connected in order of appearance to visualize what the Vertex Cache optimization changed). It works fine with "ref Vector4.X".

Regarding the Matrix4 struct containing errors, I'm heavily using the Rotate function to convert from Quaternions. This could explain the bad animation keyframes, I'll check this out once it's released. It's a bit weird tho that the Torusknot app doesn't seem to suffer from the Rotate function's bug?

6) Will fix.

Off topic, but this is not an officially sanctioned enum. It seems the ARB implemented it, then left it out of the specs with a comment in the spirit of: "Maybe we should use this?" I'll never understand the logic behind the current specs...

7) Just checked and the SGI ones are different. The ARB ones were promoted to core in 1.4 (they exist in "Version14") - the SGI ones shouldn't even be there, just one of the many inconsistencies in the specs. Provided they don't break anything else I'll add these to TextureParameterName, for convenience's sake.

[forum]
I'm hoping to add this functionality in the new site (currently under construction at http://opentk.ath.cx -- obligatory here be dragons, not ready yet, angry hamsters etc etc warnings)

6) Guess so.

[links collection]
It's still there, somewhere. Maybe it would be better suited to the manual, where it can be edited and updated by anyone.

[links]
Agreed. I'm still looking were to put them (they currently reside in the main menu).

[who's online]
This block was slowing down browsing on Sourceforge, so I've set it to update only once every ten minutes (on another server, a timeout of 1-3 minutes would be more reasonable). I'll make it toggleable in any case, so you can always hide it if you don't like it :)

[poll/survey]
These weren't possible on Sourceforge (memory limits), but I'll be adding them on the new site.

[logo]
II'm not sure what you mean by "horizon"?

[GL3 specs]
I've asked this question on the OpenGL board and was told that some kind of specs will be available. OpenTK/Tao use the latest available spec files (February 2007 IIRC), which should already contain SM4 functions.

Even if the specs files aren't published (and I can't think why they'd do that), the generator can still parse the C headers and generate the specs from that (the very first version did just that, actually). Unfortunately we wouldn't be able to generate enums information in that case, which is annoying. Hopefully they'll just publish an XML file & it's schema, and make our lives easier.

[logo]
Ah, I think I see what you mean now, thanks. I'm not an artist (the logo was created by someone much better in design than I ever was), but I'll try a few more variations to see what fits.

[GL3 specs]
Extensions are added to the spec registry regularly. AFAIK, IHV's keep their own headers with experimental extensions (which are included in ATI's or Nvidia's SDK's) and propose some of these to the Khronos group for inclusion. If two or more vendors agree on a common spec, this is added in the EXT namespace, otherwise it stays vendor-specific (NV, ATI, MESA, etc). Once an an EXT function is approved by Khronos (former Architecture Review Board) it is moved in the ARB namespace and there is a good chance that it will become core in the next GL revision.

All OpenGL functions are defined in the gl.spec file (the latest version is included with the OpenTK source, under Source/Bind/Specifications/GL). Khronos uses a custom program to scan this and produce the official gl.h and glext.h headers (an old version of this program is available in the public SGI repository, I think). Tao/OpenTK do the same so we just need an up-to-date gl.spec file; the same will probably hold true for GL3.

7 continued) I've now run multiple times into similar problems, where I had to go through versionX enums to find a token, or use the search function to figure out where the token is located. Am I missing something obvious how to find them faster? Or do I really have to remember which extensions were introduced in which version of OpenGL? I was under the impression that all extensions available to OpenGL 1.2 would be available in 1.3 up to 2.1 too.

I can c&p examples if you need to know where specifically the problems were, but it turned out they were all solvable by using search. However the code isn't pretty when casting from one enum to another, thus my question if I'm missing something here?

1. Agreed, commonly used things like Multitexture, Blending, Texture Compression, Shadow & Cube Maps, VBO, FBO, 3D Textures and Shaders could really be integrated. Besides the 3D Textures that's pretty much standard for years now. It should still be the user's responsibility to check for availability for extensions before using them, but make them all available by default. An additional bonus would be the possibility of inline documentation, ideally referring to chapters in the book if available.

   Basically merge all versions together, I dunno for others, but personally I prefer 1 enum with 30 options over 3 enums with 10 each. The Sgi extensions aren't imho that bad, although they would be better legible when uppercase since it's more clear that it's the vendor name and not part of the parameter name.

   GetTextureParameter.TextureMaxLevelSgis
   GetTextureParameter.TextureMaxLevelSGIS

2. Some random quotes:
   
   (TextureTarget) Version13.TextureCubeMapPositiveX   & Co.
   (TextureTarget) Version13.TextureCubeMap
   
   (EnableCap) Version13.TextureCubeMap // yes, this is correct. it's both Texturetarget and Enablecap
   
   (GetTextureParameter) Version13.TextureCompressed
   
   (TextureParameterName) Version12.TextureBaseLevel
   
   (TextureParameterName) Version12.TextureMaxLevel
   
   Glu.Build2DMipmap(TextureTarget, (int) PixelInternalFormat, ....  // cast

   Not really exotic functionality, mostly from the port of my DDS manager to OpenTK. I've never really liked DevIL's behaviour when working with dds files (namely no ability to flip images) and made the manager completely independent from Tao by writing a custom dds loader that can handle flipping images upside-down for OpenGL. This allows for future inclusion of loading cube maps or volume textures and eases adding formats besides S3TC, like ATi's 3Dc Normal formats or the GF8 Lumina formats.

3. I've also noticed that many of the SGI extensions have the same hex-value as their core/ARB pendants, i'd recommend to comment out all duplicate tokens. Here's an example of what I had in mind:

   From current Enums.cs from OpenTK 3.13
   

   GetTextureParameter.TextureMaxLevelSgis = ((int)SgisTextureLod.TextureMaxLevelSgis)
   TextureTarget.TextureMaxLevelSgis = ((int)SgisTextureLod.TextureMaxLevelSgis) // incorrect TextureTarget, should be in TextureParameterName, same for LOD
   SgisTextureLod.TextureMaxLevelSgis = ((int)0x813d)
   SgisTextureLod.TextureMaxLevel = ((int)0x813d)
   Version12.TextureMaxLevel = ((int)0x813d)
   All.TextureMaxLevelSgis = ((int)0x813d)
   All.TextureMaxLevel = ((int)0x813d)

   What I had in mind:
   

   // This enum is the only one where actual values are assigned.
   public enum All : int
   {
   TextureMaxLevel = 0x813d;
   TextureMaxLevelSGI = 0x813d; // add this at all for compatibility? Noone would ever use it imho, since there's the v1.2 core one.
   }
   
   // These enums ideally never assign any numbers, they take them from All-enum
   public enum TextureParameterName : int
   {
   TextureMaxLevel = (int) All.TextureMaxLevel;
   }
   
   public enum GetTextureParameter : int
   {
   TextureMaxLevel = (int) All.TextureMaxLevel;
   }

   What do you think?

   I don't know really how much your generator can help here, but If the All-enum could be sorted by ascending/descending values, it'd be pretty simple to find duplicate tokens (there's really no point keeping the SGI ones in the example above, since they hold the same value. If vendor and core extensions aren't equal, they'll be listed ofcourse).
   Regarding the All-enum, I personally try to avoid it and rather find the the proper OpenTK enum as parameter. Ideally you could write programs without using that All-enum at all, but rather the specialized enums, or not?

4. Another issue would be that some OpenTK-functions do expect a parameter from the Version15 enum (VBO), how would this be handled?
5. "can not be attached to this post, because the disk quota of 512 KB has been reached." cannot upload any more images ><
6. Another Enum that should be created is one defining integer types for GL.Draw(Range)Elements(Instanced), currently one function uses All, one uses Version12, etc.

   GL.Ext.DrawElementsInstance( BeginMode.Triangles, Indices.Length, ExtDrawInstanced, Indices, primcount ) is just wrong, the way I understand it that function is merely GL.DrawElements with primcount added, and returns gl_PrimitiveID in the Shader which is the current iteration of primcount. Both should use the same type enum, and as GL.DrawRangeElements. Quote from the redbook on glDrawElements: "type must be one of GL_UNSIGNED_BYTE, GL_UNSIGNED_SHORT, or GL_UNSIGNED_INT"
   

   public enum IndexType : int
   {
     UnsignedByte = (int) All.UnsignedByte,
     UnsignedShort = (int) All.UnsignedShort,
     UnsignedInt = (int) All.UnsignedInt
   }
7. One more thing I'd appreciate is if the enum OpenGL.Enums.PixelInternalFormat would contain a non-OpenGL value, which would be "Invalid = 0". In my Texture loading I do examine pixel formats, and if there is any error with TexImage the pixel format returned is 0 (which could then be compared as PixelInternalFormat.Invalid rather than comparing with (PixelInternalFormat)0.)
   Something like this would probably make sense for a few more enums, which can be queried from OpenGL and where 0 is unused.

Wow, lots of material here. Let's see:

[1. Naming]
AFAIK the idea in the original specs was that enums defined in one version wouldn't be updated on later revisions. That's why there are things such as the Version15 enum, when several of its values should appear in more specific enum types. (It seems this rule was introduced by the ARB, so earlier SGI enums are littered everywhere)

I don't think it's a good idea to capitalize SGI, ARB etc in enums (against the naming conventions), but I'll add a rule to omit the SGI member if a plain one with the same name exists (see also [3])

[2. More naming]
The reason for these is the same as above (these enums were added later). If we say that OpenTK targets GL2.1 (and I think this is reasonable), we can just go in and update the original enums. It's a lot of work, but it can be done gradually.

[3. Enum members]
It would be possible to use the All enum to define everything, but a) the current way works and b) the user would never see the difference anyway. It is easy to drop duplicate entries though (prefer the plain one over any SGI, ARB etc when both appear), so I'll add that.

[4. GL enums in OpenTK functions]
Undecided... Probably create a new enum outside the GL class, but I'm leaving that for GL3.0. What do you think?

[5. Attachment limit]
Space limitations, unfortunately. Try hotlinking from some other server (use the img tag).

[6. GL.Draw(Range)Elements(Instanced)]
I'll have to check the manual, but it isn't unlikely that the .specs define the function incorrectly (the error wouldn't show up in the C-headers, so it went unnoticed).

[7. Invalid member]
Pretty easy to fix. If you know of any other such functions, post and I'll fix them.

[8. Shader-related functions and the All enum]
It seems the policy was changed around that time, for reasons unknown. These should all have actual enums (or at least Version20 etc) - if you can find the correct types, I'd be very grateful! I'll be adding those as time permits.

[9. Even more naming :)]
Well, if something is blatanly wrong or the name is misleading, ok. Otherwise, probably best left as is, to avoid breaking programs.

10. GL2.1, agreed. Personally I find the "clean start" as the biggest feature of GL3.0, but who knows when it will become a viable development platform.

Actually the biggest reason I started working on OpenTK was because I felt programming OpenGL could be so much nicer. Most of the hard work is done now (the generator takes care of most glaring problems/inconsistencies), so we just need to clean up the source material to provide a more intuitive API. One more reason to do this sooner rather than later, is to move the library in beta status and attract more users (and potential developers :) )

1. Maybe tweak the rule so it comments out all duplicates starting at the top of the hierarchy core->arb->ext->vendor. (assuming value is really equal)
This pretty much answers 2 & 3. Thanks. defining only values in All-enum was just an idea so one could go through the list by hand finding duplicates.

4&8. In my opinion all Version 12-21 enums should be removed, as in put in appropriate enums for each function.

5. maybe you should cleanup that folder then, I had uploaded the image twice and deleted one. I'll fix a jpg version of the primitive table later.

6. The function is defined correctly, just the enum "ExtDrawInstanced" is misleading. See original post

7. Will do :)

[Renaming]
What I wanted to suggest is refactoring BeginMode into something more appropriate like GeometryType or PrimitiveType. This will still make sense when used with GL.Begin and definitely looks better with GL.Draw*

Thanks, one more question though. You don't want to include texture manager into OpenTK, but how about texture loaders? Well, it's basically only 1 Function