Implement Basic File Loading Into OpenGL's Standard.

As we all know geometry has vertices, normals, textures, etc as part of the basic mesh, and there are many file formats out there today people work with importing and exporting to and from various content authoring/editing tools.

Many formats now cram extra information such as scene, camera, and animation information into the file formats and also make overly bulky and uneccessarily complicated systems such as XML based formats.

When you compare a basic format such as an OBJ to a DAE or LWO file you see a huge difference, however, the most basic information needs are the same for the most common programming tasks, and many of the standard file formats have been around so long now and useful today, it’s kind of ironic that OpenGL hasn’t by default already included in the spec functions which handle the basic loading and exporting of such formats all these years, and we know JPG’s, BMP’s, and PNG’s have been around a really longtime.

The basic needs and core data remains the same, and an internal Universal Mesh Format could be applied the information is loaded into and processing performed on much as the current VBO and VAO’s etc., but a step simpler, assuming that the standard mesh to be imported and exported is the standard triangular mesh, and a future addition might include converting such meshes into 2D graphical pixels stored in arrays.

The OBJ file format is perhapes the best example of such implementable simplicity that would eliminate the repetitive and complicated random mistakes when always needing to code importers and exporters.

DirectX is already a technology which has been implementing even their own file format, but it’s not really another external file format we need, it’s we need the optimized import and export capabilities built into the existing spec from the start.

And this is what I’d like to see in a future addition.

Example of the Wavefront OBJ File Format:

Even if the importing and exporting was added to the OpenGL spec and data was in a universal format stored internally, we always have the option to do things manually and make changes, but let’s face it, the OBJ file format has been around a longtime and doesn’t change very often if at all.

However, formats such as Collada more advanced, but as it’s XML based unless you really know what you’re doing with node handling, coding the importer and exporter can be a challenge and developers will often make a bunch of programmatic mistakes along the way which impacts performance as well, and since OpenGL is a high performance graphics standard, it might enhance development of both content and applications if the such base functionality were included.

The below is really what basic standard meshes boil down to and have for a very longtime.

The Basic Mesh Format (Triangular Mesh):
Name (User/Program Supplied Mesh Name for This Mesh/Geometry Object)
InternalMeshName (Mesh Base Name)
Vertices (Physical Points of the Geometry)
Normals (For Standard Mesh Lighting)
UvTextureCoordinates (For Applying Textures To Surfaces)
Indices (Describes Surfaces/Faces of Geometry Vertices and for Optimizing)
Materials (To Apply Vertex Colors and Textures Onto Geometry Surfaces)
Textures (Assigned to Materials and Applied to Surfaces)

Very simple optimizations and simplification of texture loading:
When textures loaded to prevent duplicate loading of existing loaded textures into memory you simply check texture names in a hashtable or vector array during load and reuse storing the ID’s/Names.

Other:
Most all the standard data should load in the background like textures and use OpenGL’s optimized functions already. Today there’s other things such as shading technique’s, but this is usually applied secondary in the form of post processing techniques that modifies coloring and the outer shell appearence.

As you said, OpenGL should be the multi-platform standard for the high-performance graphics. In order to be such, it has to be thin (we all remember the flosculus lean-and-mean from GL3.0 announcement). What you are asking for is a high-level utility library. It should not be a part of the core.

It’s important to realize here that a comparison to .x files is not valid. Direct3D does not have it’s own file formats, and does not contain image loading routines; they’re included in D3DX, but D3DX is a separate library. It’s packaged and shipped with D3D for sure, but it’s not the same library and should not be viewed as the same library. The fact that you can even use many D3DX routines in an OpenGL program (such as it’s matrix routines, or it’s vertex cache optimization calls) should hammer that point home.

So your request really boils down to asking for a separate library to handle these things - but you already have plenty of choice in that regard. Libraries for all of these already exist, and there’s no need for the ARB to get involved in defining yet more. Time spent doing that is time not available to further enhance the core capabilities of OpenGL.

[QUOTE=mhagain;1242962]It’s important to realize here that a comparison to .x files is not valid. Direct3D does not have it’s own file formats, and does not contain image loading routines; they’re included in D3DX, but D3DX is a separate library. It’s packaged and shipped with D3D for sure, but it’s not the same library and should not be viewed as the same library. The fact that you can even use many D3DX routines in an OpenGL program (such as it’s matrix routines, or it’s vertex cache optimization calls) should hammer that point home.

So your request really boils down to asking for a separate library to handle these things - but you already have plenty of choice in that regard. Libraries for all of these already exist, and there’s no need for the ARB to get involved in defining yet more. Time spent doing that is time not available to further enhance the core capabilities of OpenGL.[/QUOTE]

It would be nice if the ability to load this data was already included so you don’t need to have so many different libraries for each operating system or device as the OpenGL spec is more independant.

On DirectX that itself could be used for example, .x is their form of mesh file with the same information and then some, it’s a part of DirectX and it is a mesh file format that also contains basic text in the ASCII version (non-binary) of the file that is readable and it contains like most any other the same triangular mesh, color data, indices, texture links, and optional animation information that wavefront object files and any other’s do, that is why it’s comparable and my point in that was that DirectX already includes a default way to import, optimize, and export mesh data, materials, and textures etc… and rendering them after you have that data is the easy part, which is why all these years it’s been easier to work with from some respect besides the fact many of the 3D Math library functions are already included to perform various operations.

But as for OpenGL itself, complete mesh loading I wish it was already included into the core OpenGL a longtime ago or in some extensions, not strictly speaking of any particular format only but atleast the Open Sourced or freely available ones or definately the Wavefront OBJ/MTL, and Collada.

If you know anything about computer graphics and basic geometry you know what a mesh is and it’s not new, also the history of computer graphics and things such as images and other formats like PNG, TGA, BMP, JPG, etc…

There is no excuse for waiting decades to implement features to do things that make a huge positive impact saving time eliminating bulk code error and re-development while maintaining performance and overall impact of usable features that is very useful.

And it’s a waste of time to constantly reinvent the wheel spending 80% of the time creating things to work with than to actually just use the API to do greater things, and that’s something that has been happening with DirectX for awhile now.

I dunno how long SGI has had links to Mesh File Formats such as Wavefront Object and Alias but I definately know great tools such as Lightwave and Maya have been created using such things and modern graphics.

The improvement in gaming and the quality of graphics with the introduction of meshes enabled many authoring tools and more sophisticated looking charactors and 3D objects, a mesh provides a foundation or building block storing the main data that makes up the geometry etc… and you don’t need to have to manually code each part of a mesh you can use files to create and store geometry and related information, the rest is done in content authoring tool.

It is highly important and definately not trivial at all.

If it had been already included many years ago I’d have already been working on other really advanced things, I could’ve already had better and simpler work flows established with Tools like Google Sketchup, Poser, Lightwave, Maya, 3DS Max and Blender models to already handle more sophisticated things such as animation and optimized tasks and even visual or more automated programming, shaders, and physics (which even basic physics should already be included, why is there always 3rd party library needs for the basics what is so commonly used???).

There would have been a much easier workflow and integration sending authored content to and from the various authoring tools to polish things off, needing less tools and research to convert already existing and commonly used and stored files just so that they work with the graphics and are rendered to the screen as is in the authoring tools.

Ultimately getting that data from the common file format to the screen would have been a much smoother and natural process with less of the human knowledge and research bottleneck.

Take this game for example, they used Google Sketchup to create things:

It uses the DAE Collada file format but can also export to OBJ with plugin or premium version of program.

But the thing is, once you finally got that mesh into Collada file you need to read that data to display it into the graphics and perform other tasks, now you need to spend time developing the importer and program how to handle all the base graphics routines for not only managing, but also storing the basic mesh data and texture data using OpenGL.

SGI used to work with storage and graphics, and OpenGL is a high performance graphics standard that also includes storage features and things which works with the hardware, if more advanced things such as shading can be added and GPU programming and the rest, you’d think the less complicated basic stuff everybody needs at somepoint you’d think would already have been included by now to make developers lives easier on that including the extended math functions, currently the basic operations included in OpenGL are a huge help in that regard as are easily accessible matrix operations, but the missing part are more commonly used things such as the basic math operations for physics.

OpenGL’s job is not to do your work for you. D3D’s job isn’t to do your work for you either. D3DX is a separate library from D3D, and it’s D3DX that deals with meshes (among other things). D3D itself doesn’t handle that stuff.

OpenGL’s job is to be a relatively low-level interface to graphics hardware, which can be implemented across multiple platforms and hardware devices, thus creating a uniform interface that one can use to access a range of hardware.

It is not there to make your life easier. It’s not there to be convenient or provide 100% of the features that you personally need to get done what you’re trying to do. Mesh loading, image loading, shader loading, none of these have to do with interfacing to the hardware. And thus OpenGL should not handle any of them.

If you want a mesh loader, use the Open Asset Importer library; it’s able to load pretty much anything.

Also, please stop randomly bold-facing words in your post. It makes it really hard to read (though your lack of willingness to use periods doesn’t help either. Periods separate sentences not paragraphs).

This is not a comic book; you don’t need to bold every other word. If you absolutely need to emphasize something, use the less distracting italics instead.

If that were the case then we wouldn’t have lighting, texturing, normals, and certainly not shading, fog, or various type of light sources or loading of specific data types with RGBA colors, no TGA or PNG or BMP support, we wouldn’t even have mouse or keyboard input via Feedback and seperation of the buffers to perform non-graphical processing, in today’s modern computer graphics we’d be stuck recreating pong over and over again and everyone would need to be a professor in math to implement lighting and other algorithms with 2 color options, for dark or light.

Today even a tiny mini PC has 700MHz ARM processor and 256MB video memory and gigs of storage high speed via SSD or flash or SD card and installing Linux or Windows 7 supporting OpenGL, I don’t see how adding extremely useful commonly used things the equivalance of when they added lighting and texturing and blending, it’s like everything is included but the basic file stored data loading, a file format such as these are certainly platform independent in that it definately could be included into OpenGL and bring new possibilities and further simplification to developers, adding an extra image copy function duplicate functionality is one thing, adding support for commonly used formats into a powerful high performance graphics API such as OpenGL is what would set the bar even higher and makes using OpenGL a bit more attractive option if it becomes easier to use and maintains that level of quality.

So we have today:
Image/Geometry/Color and Memory Storage and Processing.
Multiple Lighting Options
Input Handling for Mouse and Keyboard, Etc…
Geometry and Pixel Blending Operations
Rendering/Compositing
Shading
Camera
Viewport
Image Data Support for BMP, TGA, PNG, JPG, Etc…
But we lack of Mesh Data Loading From a File that includes this data???

Mesh Data fits into all of the basic categories of the basic components of what OpenGL is used for.

I don’t see how we could have the kind of great 3D games we have today without the geometry file storage, graphical, and animation authoring tools built from using OpenGL all these years and definately in gaming and entertainment industries.

These files they have to be loaded and the data has to be extracted and OpenGL has to work with the data and it’s the same repetitive base cycle.

Without a mesh file containing this information and without the ability to use useful graphical functions to display this data to the screen OpenGL wouldn’t be a useful graphics API, but instead we have that ability to do many things but the bar needs to be raised a little bit higher to include some important missing components that probably should’ve been included in the earliest releases when the first storage buffer concepts came out.

It’s like why add page flipping/bitflipping/bufferswapping(double buffering)?

Because it’s useful to the majority and produces important results and people use it.

Example API Functions/Subroutines Idea and Usage (VB.NET Sample):


'LOADING THE MESH FILE AND RETRIEVING THE DATA FOR MANUAL DATA HANDLING.

'Load the mesh file data from mesh file. (Automatically loads OBJ with all the basic data, geometry, MTL file and Textures as well.)
Dim strResult as String = API.OpenGL.Functions.glLoadMeshDataFromFile("C:\Data\Meshes\Table.obj", API.OpenGL.Enumerations.MeshType.OBJ) 

'User Defined Storage Variables.
Dim arrVertices() As Single
Dim arrIndices() As UInt32
Dim arrNormals() As Single
Dim arrTexUVCoords() As Single
Dim arrTexNames() As String
Dim arrSurfaceNames() As String
Dim arrGeometryColors() As Byte
Dim arrSurfaceIlluminationModel() As Byte

'Make sure mesh loaded successfully before proceeding.
If strResult = API.OpenGL.Enumerations.MeshLoadFlags.Loaded Then

'Get Mesh Data From Temporary Internal OpenGL Global Mesh Data Buffers. (Nothing more than a few basic re-usable int32/uint32/float/string/byte arrays, etc.)
arrVertices = API.OpenGL.Functions.GetMeshDataGeometryVerticesArray()    'float/Single or Double Array.
arrIndices = API.OpenGL.Functions.GetMeshDataIndicesArray()                   'Int32 or UInt32 Array.
arrNormals = API.OpenGL.Functions.GetMeshDataNormalsArray()                 'float/Single or Double Array.
arrTexUVCoords = API.OpenGL.Functions.GetMeshDataTextureCoordsArray() 'float/Single Array.
arrTexNames = API.OpenGL.Functions.GetMeshDataTextureNames()             'String Array.
arrSurfaceNames = API.OpenGL.Functions.GetMeshDataSurfaceNames()        'String Array. (NOTE: Surface Name is also Material Name.)
arrGeometryColors = API.OpenGL.Functions.GetMeshDataGeometryColors()    'Byte Array.
arrSurfaceIlluminationModel = API.OpenGL.Functions.GetMeshDataIlluminationModel()   'Byte Array.

'And so on for the other surface/material values or settings....

End If

For More Sophisticated Sub Mesh Mesh File Formats Containing Multiple Objects or Hierchy Structure:

'Get Sub Mesh Vertices.
arrVertices = API.OpenGL.Functions.GetSubMeshDataGeometryVerticesArray(0) 'The function parameter number indicates the index identifying the array to return for a specific geometry object.

For returning hierchy name data:

strNodeNames = API.OpenGL.Functions.GetSubMeshDataHierachyNodeNames(0) 'Data Return Example: "MESHPARENT:HEAD"
strNodeNames = API.OpenGL.Functions.GetSubMeshDataHierachyNodeNames(1) 'Data Return Example: "HEAD:EYES:MOUTH"

For Rendering:

strDataToReturn = API.OpenGL.Functions.RenderMesh("Sparky") 'Render the sparky mesh that's loaded for rendering into memory. Return Example Text String: "MeshHit:Tree5@Impact Point:17.0,3.0,16.0"

Data returned could contain anything such as collision hit information, multiple textual information, or nothing at all.

'Optionally: Internally OpenGL could have the data loaded into the buffer objects as you would do manually but instead in the background already, and optionally edit the data on the fly, make copies, or apply shader processing and matrix or physics operations without the need to get this data out of memory and handle it manually in code, but also the option to do so remains if needed.

Piecing things back together for rendering can be handled either automatically or manually with the data assembled and processed same as you normally would.

Surface/material information could be read or set into buffer objects of the appropriate type to re-piece things together.

If the mesh data contains other information such as animation keyframes or other information specific to the format an appropriate array can return this information and the same concepts be applied and the loading function can automatically seperate the data after loaded, if specific data isn’t present and attempt is made to retrieve that data then the function should return Nothing/null, since not all formats may include such data or the data might not be saved to the file from the authoring tool used to create it.

Advanced/Bulkier File Formats:
Formats such as DAE or FBX are loaded with extra data, nodes of hierachy data structures, but the core data is always the same you always have vertices, indices, colors, normals, texture coordinates, materials/surfaces, etc…, though there might be multiple sub mesh objects seperated into the same mesh file, or even extra camera, lighting, scene information or animation, the data is readable and still maintains standard values that OpenGL can use. These objects can be stored as defined as they are as Sub Mesh’s, bringing down this complication working with these things and keeping it simple would be a big development benefit.

If OpenGL loaded this data normally in the background then the developer already working with the file could focus what he knows about what is stored in the file and take it from there not focusing so much on the complicated or more technical aspects.

This is all just an example and not as a final idea, just so long as the data is loaded and you can work with it more in OpenGL on the fly if need be then there’s a difference made.

[b]Some File Format References:

OBJ (Wavefront Object Mesh File):[/b]

MTL (Wavefront Object Material File):
http://people.sc.fsu.edu/~jburkardt/data/mtl/mtl.html

DAE (COLLADA Multi-Purpose Digital Asset File):

Lastly, that Collada file format is very complicated, I know they tried to pack everything in it possible and it’s XML based and many things with organized HTML type tags and with Khronos, but it’s so bulky in fact and feature packed that would definately be a format and reason to implement loading of such files into OpenGL in a more automated way. It’s so complicated in fact that you have to practically read an entire book on it even for just the basic data structures, I love it but it’ll drive you crazy thinking omg this will take years and years to figure it all out, in fact I think it’s got everything but the Titanic packed in it and then some.

Without even reading what the others have written all I can say is: Nope. This isn’t stuff for core OpenGL but for seperate libraries like assimp or your own lib. And please, please, don’t compare DirectX to OpenGL. They have never been nor will they ever be comparable. If you compare Direct3D and OpenGL that’s ok to some degree but even Direct3D doesn’t give you any file format support.

I give up, I’ll go against my research and development code and be close minded about suggesting improvements from now on to such technologies, clearly there’s nothing more to suggest adding it’s fine as is no more need for improving no matter how old it is, Bill Gates wants Microsoft to shift and retire the desktop and bulk machines anyways now and clearly there are struggles here already, the point is not getting through of why it’s important or relative to the OpenGL API and the post is being mistaken or misread.

And no I’m not being lazy and wanting the work done already, in fact quiet the opposite, I’m making a future feature suggestion for a feature for future release of OpenGL API and that fits under the category it was posted under.

It wasn’t meant to be an argument between developers to have major debate.

This is depressing for me and discouraging.

If the idea needs to be shot down or destroyed before it is even realized then so be it, it’s a shame and I think it’s sad.

I will continue working with OpenGL but I won’t feel the same about it now.

It’s like a person can’t even go to forum in a section with the right topic and make a proper post specific to the category anymore.

And you can’t tell me when you rotate a vector 3 around a custom axis and it’s included in DirectX too and all the vector and matrix functions samething that there wasn’t some comparible things in it, they both write graphics to the screen and access the hardware.

3 by 3 4 by 4 matrix all the same.

Transpose this, normalize that, inverse matrix that.

Go to Walmart pickup a green basketball, go to a sports shop pickup a orange basketball, they both bounce, but one likes to bounce in 1 basketball court for some reason.

Samething GLEnum really just equals UInt32 yet some people insist it be defined as just an Unsigned Integer, and yet don’t forget the 32 bit part.

Sorry but none of this makes any sense at all now.

Let’s define some things first.

OpenGL is a low-level API for providing 3D graphics functionality.
Direct3D is a low-level API for providing 3D graphics functionality.
DirectX is a bunch of different libraries which are shipped together.
D3DX is a supplementary library for Direct3D that provides some additional higher-level functionality.

OK, so what you can see from these is that OpenGL is directly comparable to Direct3D. Not DirectX, not D3DX, just Direct3D only. So it doesn’t even make sense to talk about wanting features in “DirectX” to also be in OpenGL, because “DirectX” also includes sound, input, networking, setup and other things.

So first of all, please limit the scope of your request to something that it actually makes sense to compare; i.e. OpenGL and Direct3D.

Now look at the specific things that you’re asking for: higher-level model and image format handling routines. Are these in Direct3D? No, they’re not. They’re in D3DX. Is D3DX part of DirectX? Yes, it is. Is D3DX part of Direct3D? No, it is not.

Let’s see what Microsoft have to say on the matter: D3DX (Direct3D 9) - Win32 apps | Microsoft Learn

D3DX is a library of tools designed to provide additional graphics functionality on top of Direct3D.

And: Mesh Support in D3DX (Direct3D 9) - Win32 apps | Microsoft Learn

D3DX is a utility library that provides helper services. It is a layer above the Direct3D component.

So even Microsoft agree here - “D3DX is a utility library that provides helper services” - not a core part of the API, helper services.

The same applies to OpenGL. This functionality does not belong in the core API, it belongs in a utility library that provides helper services.

Your posts are not trolled. We just want to tell you what is the weakness of your proposal.

Well, before proceed I need answers on two questions:
How long have you been programing using OpenGL? What version are you using?

There are more “serious” problems novices have to face with than mesh loading.

  1. You cannot access OpenGL core functionality without acquiring function pointers. It can be done bu using additional library, like GLEW, or by manual programming (which I prefer).

  2. You don’t have elementary 3D math in OpenGL, (like dot or vector product, projection, matrix multiplication, quaternions, etc). An additional library should be used (like glm), or do it yourself (which I prefer).

  3. You cannot even upload image from the file into the texture. That’s where DevIL suites fine.

  4. There is no camera objects. That’s the part of the scene graph, not of the graphics API.

  5. There is no mouse or keyboard, or any input device manipulation. You have mention it, but it is not the par of the graphics API either.

  6. There is no lights (you have mentioned it also) in modern OpenGL. You have to implement lighting in your shaders now by yourself.

And you ask for mesh loading function in the core of OpenGL, where even matrices and 3D math operations are discarded.

I compare them because they are both comparable and I have no particular bias and not afraid to talk about the technologies.

The thing is, you talk about technologies when talking DirectX. When talking OpenGL, there is only one. DirectX is a compilation of different APIs designed for different purposes, Direct3D and related libs included. You can’t compare anything seriously except for OpenGL and Direct3D. That’s it.

Why are my posts being trolled?

Your post isn’t being trolled. It is rejected because the ideas you convey aren’t feasible for “the next release of OpenGL”. Just because you make suggestions doesn’t imply that the suggestions are valid and good and can or should be realized in the core specification. In fact, most suggestions made here aren’t worth considering at all. Extending the spec isn’t something to be taken lightly and any addition should have a sturdy foundation and an actual reason that necessitates it. Loading unrelated data representing geometry or image data isn’t one of them.

Microsoft did work with this and they broke off at a later date, just like NVidia and ATI had varying OpenGL development process and support in a time when neither was perfectly in line, I’ve experienced the impact of the NVidia and ATI and Microsoft DirectX and OpenGL differences.

Microsoft broke of with what? OpenGL? I can’t fathom what this paragraph has to do with your proposal.

[QUOTE=Alfonse Reinheart;1242973]OpenGL’s job is not to do your work for you. D3D’s job isn’t to do your work for you either. D3DX is a separate library from D3D, and it’s D3DX that deals with meshes (among other things). D3D itself doesn’t handle that stuff.

OpenGL’s job is to be a relatively low-level interface to graphics hardware, which can be implemented across multiple platforms and hardware devices, thus creating a uniform interface that one can use to access a range of hardware.

It is not there to make your life easier. It’s not there to be convenient or provide 100% of the features that you personally need to get done what you’re trying to do. Mesh loading, image loading, shader loading, none of these have to do with interfacing to the hardware. And thus OpenGL should not handle any of them.

If you want a mesh loader, use the Open Asset Importer library; it’s able to load pretty much anything.

Also, please stop randomly bold-facing words in your post. It makes it really hard to read (though your lack of willingness to use periods doesn’t help either. Periods separate sentences not paragraphs).

This is not a comic book; you don’t need to bold every other word. If you absolutely need to emphasize something, use the less distracting italics instead.[/QUOTE]

Italics is not my style sorry.

[QUOTE=mhagain;1242997]Sorry but none of this makes any sense at all now.

Let’s define some things first.

OpenGL is a low-level API for providing 3D graphics functionality.
Direct3D is a low-level API for providing 3D graphics functionality.
DirectX is a bunch of different libraries which are shipped together.
D3DX is a supplementary library for Direct3D that provides some additional higher-level functionality.

OK, so what you can see from these is that OpenGL is directly comparable to Direct3D. Not DirectX, not D3DX, just Direct3D only. So it doesn’t even make sense to talk about wanting features in “DirectX” to also be in OpenGL, because “DirectX” also includes sound, input, networking, setup and other things.

So first of all, please limit the scope of your request to something that it actually makes sense to compare; i.e. OpenGL and Direct3D.

Now look at the specific things that you’re asking for: higher-level model and image format handling routines. Are these in Direct3D? No, they’re not. They’re in D3DX. Is D3DX part of DirectX? Yes, it is. Is D3DX part of Direct3D? No, it is not.

Let’s see what Microsoft have to say on the matter: D3DX (Direct3D 9) - Win32 apps | Microsoft Learn
And: Mesh Support in D3DX (Direct3D 9) - Win32 apps | Microsoft Learn

So even Microsoft agree here - “D3DX is a utility library that provides helper services” - not a core part of the API, helper services.

The same applies to OpenGL. This functionality does not belong in the core API, it belongs in a utility library that provides helper services.[/QUOTE]

Ok so I guess ARB should remove all the lighting algorithms, texture files data support, geometry storage rendering and processing, and the input/feedback features, because you know it’s in OpenGL, come on I know the difference in the technologies, we could say yeah OpenAL is different and specific to audio, but hey don’t forget it’s now Khronos managed, just like DirectX is Microsoft managed, but I’m still gonna compare the 2 because I’ve worked with them both and also during the history making, and yes it was OpenGL stuff. I even had the microsoft employee’s tell me it was themselves, that was the lead visual studio developers and DirectX development team, right when they broke off shortly after saying it too.

And then the fabled API wars.

Look no arguments on this alright?

I don’t care, the Khronos package and DirectX are the standard that work on the hardware for graphics, alot of graphics hardware includes audio now, we have APU’s which are processors that go onto mini ITX motherboard systems to add videocard functionality on platforms which don’t implement the upgradable PCI-Express slots and more, Khronos and Microsoft stuff they both include near identicle naming convensions for their standards and that is not a coincidence look at the math libraries and it was nice Microsoft still includes OpenGL Windows interface documention reference on their website.

[QUOTE=mhagain;1242997]Sorry but none of this makes any sense at all now.

Let’s define some things first.

OpenGL is a low-level API for providing 3D graphics functionality.
Direct3D is a low-level API for providing 3D graphics functionality.
DirectX is a bunch of different libraries which are shipped together.
D3DX is a supplementary library for Direct3D that provides some additional higher-level functionality.

OK, so what you can see from these is that OpenGL is directly comparable to Direct3D. Not DirectX, not D3DX, just Direct3D only. So it doesn’t even make sense to talk about wanting features in “DirectX” to also be in OpenGL, because “DirectX” also includes sound, input, networking, setup and other things.

So first of all, please limit the scope of your request to something that it actually makes sense to compare; i.e. OpenGL and Direct3D.

Now look at the specific things that you’re asking for: higher-level model and image format handling routines. Are these in Direct3D? No, they’re not. They’re in D3DX. Is D3DX part of DirectX? Yes, it is. Is D3DX part of Direct3D? No, it is not.

Let’s see what Microsoft have to say on the matter: D3DX (Direct3D 9) - Win32 apps | Microsoft Learn
And: Mesh Support in D3DX (Direct3D 9) - Win32 apps | Microsoft Learn

So even Microsoft agree here - “D3DX is a utility library that provides helper services” - not a core part of the API, helper services.

The same applies to OpenGL. This functionality does not belong in the core API, it belongs in a utility library that provides helper services.[/QUOTE]

Yeah the comparison you showed has the mesh support, ok and the OpenGL reference equiv would be for what mesh support now?

Microsoft did work with this and they broke off at a later date, just like NVidia and ATI had varying OpenGL development process and support in a time when neither was perfectly in line, I’ve experienced the impact of the NVidia and ATI and Microsoft DirectX and OpenGL differences.

Well from what they told me at the time in early versions of DirectX that they were using OpenGL to develop DirectX and that it was actually linked to the GDI and GDI+ projects and for 2D accelerated rendering and things such as page flipping and buffering as well as pixel and screen display such as the swapping technique, and was converting the mathmatics operations like the matrix operations and things like transpose, oh an inverse.

And then they wanted to take care of the lag issues and rebuild DirectX from the ground up and get rid of bottlenecks and customer support complaints.

Anyways back to topic “Basic Mesh File Data Loading” suggestion…

Look at the SGI documentation (Wavefront Technologies OBJ/MTL) and look at the Khronos documentation (Collada), full feature support but not data loading support from file???

Now look at the dates, now look at the Nintendo 64 chip presentation video, and SGI’s hardware phases and leading to eventual release of OpenGL and why.

Now look at Khronos and count the years gone by since, and now look at what specifically changed computer graphics, and think about why texture loading was added, and then think about why we have meshes and programs for 3D content authoring and 3D editing.

And ask yourself why when all this effort was put into creating a new file format and technology such as GLSL for data manipulation and processing, why there hasn’t been some effort put forth to actually load the data as OpenGL knows how?

We even have OpenCL now and other things.

Again, I quit.

Ok so I guess ARB should remove all the lighting algorithms[…]

The ARB already has - just like Microsoft…

[…]texture files data support, geometry storage rendering and processing, and the input/feedback features, because you know it’s in OpenGL[…]

Why would anyone remove low-level features like texturing and buffers? By feedback you mean transform feedback (or stream out in D3D parlance)? I have no idea what you mean with input.

we could say yeah OpenAL is different and specific to audio, but hey don’t forget it’s now Khronos managed

It is. It’s a pure audio API. OpenAL has never been and never will be Khronos managed - it has been invented by Creative and is licensed by Creative under the LGPL.

I don’t care, the Khronos package and DirectX are the standard that work on the hardware for graphics, they both include near identicle naming convensions for their standards and that is not a coincidence look at the math libraries and it was nice Microsoft still includes OpenGL Windows interface documention reference on their website.

Wrong, just flat out wrong. There is no Khronos package. The only technology specified by Khronos that’s discussed in this forum is desktop OpenGL. Nothing else. Furthermore, not all of Khronos’ API are targeting graphics hardware. There also is no math library by Khronos. There is no handler library for input devices. There is absolutely no basis for comparing OpenGL and DirectX and there is no basis for comparing the Khronos group and Microsoft. None - what so frickin’ ever.

The resistance you show and the ignorance forced on us after having explained to you multiple times the inaccuracy of your statements - thatactually borders on trolling.

[QUOTE=thokra;1243007]The ARB already has - just like Microsoft…

Maybe deprecated but the system contains lighting and via shader shading, still works for me.

Realtime phong shading and interpolation with OpenGL default lighting, so you saying this has been removed including all that MIT text document lighting algorithm stuff?:

Why would anyone remove low-level features like texturing and buffers? By feedback you mean transform feedback (or stream out in D3D parlance)? I have no idea what you mean with input.

See that’s my point, same as why wouldn’t they add it?

Yep there sure is input, input for picking aka selection, etc…

For example, GL_SELECT, unless that was removed.

OpenGL Selection via Framebuffer example, so you’re saying you don’t do it like this anymore? Seems to work to me.:

It is. It’s a pure audio API. OpenAL has never been and never will be Khronos managed - it has been invented by Creative and is licensed by Creative under the LGPL.

Ah there now you did get my typo on that one thanks, meant OpenMax AL and Open ES for providing audio playback.

It’s still like a package it’s still like Microsoft providing DirectX a package of various things that make the whole experience, only when you download end user runtime or install OS or update or so and it installs the other stuff it is under that one package all the various technologies, designed to manipulate hardware and data.

Wrong, just flat out wrong. There is no Khronos package. The only technology specified by Khronos that’s discussed in this forum is desktop OpenGL. Nothing else. Furthermore, not all of Khronos’ API are targeting graphics hardware. There also is no math library by Khronos. There is no handler library for input devices. There is absolutely no basis for comparing OpenGL and DirectX and there is no basis for comparing the Khronos group and Microsoft. None - what so frickin’ ever.

OpenGL handles those things in the background on the memory stacks yes there is matrix pushing and popping and math going on in the background, such as matrix math, and yes the code for the operations is online to perform the same tasks, glTranslate, glRotate, glScale, etc. So don’t say it doesn’t include it already it handles it in the function blocks and the function names makes it look pretty. And you can extract that information, but that reminds me yet again of the basic file loading, the translation, rotation, and scaling functions are just as useful, but we could always do it the old fashioned manual way defining our own vectors and do the matrix math, but man this is 2013. Yeah the OpenGL Software Development Kit certainly don’t sound like a package it certainly sounds like a kit.

Yes the Math contains the same identicle wording, terms, and usages, and is handled near identically the calculations are mostly the same, and the computers internal system clock still supplies the heartbeat and the internal lithium ion batteries still power the hardware configuration CMOS circuits or uh BIOS chip on the motherboard crystal quartz.

The resistance you show and the ignorance forced on us after having explained to you multiple times the inaccuracy of your statements - thatactually borders on trolling.

Ok I got it, the resistence is futile.

Yeah when I made the suggestion it was definately for a feature addition to OpenGL, atleast I didn’t think I was suggesting the update to other libraries.

3D Model Loading Basic Loader Tutorial, .obj mesh & textures C++ openGL:

Alright final post reply, I gotta get back to work.

OK, at this stage you’re clearly talking through your rear end.

Microsoft didn’t create Direct3D, RenderMorphics did. The formation of RenderMorphics dates to 1992 when - guess what? - the first release of OpenGL also happened. GDI+ didn’t even exist until almost a decade later. Any connection between these such as you describe is entirely fictitious.

Early versions of Direct3D didn’t even handle flipping or display - you used DirectDraw for that, which was otherwise a completely separate component.

There is no such thing as “Open ES” - maybe you mean OpenGL ES? But guess what again? That’s not an audio library, that’s a pure graphics-only library too!

GLSL is not a file format and has nothing to do with file formats. Where on earth did you pick up that misunderstanding from?

The N64 didn’t lead to OpenGL - OpenGL existed well before development of the N64 even began.

The feedback and picking you refer to is not part of OpenGL - it’s part of GLU.

If you want to make a case for this you would be better off making one that is (a) at least semi-coherent to begin with, and (b) actually based on facts rather than some kind of fevered imagination.