Hybrid View

Implement Basic Geometry 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Originally Posted by Aleksandar

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.

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.