Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Page 1 of 3 123 LastLast
Results 1 to 10 of 22

Thread: Implement Basic File Loading Into OpenGL's Standard.

  1. #1
    Junior Member Newbie
    Join Date
    Feb 2006
    Location
    Tulsa, Oklahoma
    Posts
    20

    Post 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.

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

    Example of the Wavefront OBJ File Format:
    http://en.wikipedia.org/wiki/Wavefront_.obj_file

    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.
    Last edited by Knight Chat X; 09-29-2012 at 07:29 PM. Reason: Basic Mesh Description Added

  2. #2
    Senior Member OpenGL Pro Aleksandar's Avatar
    Join Date
    Jul 2009
    Posts
    1,072
    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.

  3. #3
    Senior Member OpenGL Pro
    Join Date
    Jan 2007
    Posts
    1,136
    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.

  4. #4
    Junior Member Newbie
    Join Date
    Feb 2006
    Location
    Tulsa, Oklahoma
    Posts
    20
    Quote Originally Posted by mhagain View Post
    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.

    Take this game for example, they used Google Sketchup to create things:
    http://www.sketchupartists.org/spotl...n-game-design/

    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.
    Last edited by Knight Chat X; 09-30-2012 at 09:28 PM. Reason: Removed Empty Spaces

  5. #5
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    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.

  6. #6
    Junior Member Newbie
    Join Date
    Feb 2006
    Location
    Tulsa, Oklahoma
    Posts
    20
    Quote Originally Posted by Aleksandar View Post
    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.
    Quote Originally Posted by Aleksandar View Post
    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.

    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.

  7. #7
    Junior Member Newbie
    Join Date
    Feb 2006
    Location
    Tulsa, Oklahoma
    Posts
    20

    Lightbulb

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

    Code :
    '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:

    Code :
    '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:
    Code :
    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:
    Code :
    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.

    Some File Format References:

    OBJ (Wavefront Object Mesh File):

    http://en.wikipedia.org/wiki/Wavefront_.obj_file

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

    DAE (COLLADA Multi-Purpose Digital Asset File):
    http://www.khronos.org/files/collada_spec_1_4.pdf

    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.
    Last edited by Knight Chat X; 10-01-2012 at 02:16 AM. Reason: Added Extra Code.

  8. #8
    Senior Member OpenGL Pro
    Join Date
    Apr 2010
    Location
    Germany
    Posts
    1,099
    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.

  9. #9
    Junior Member Newbie
    Join Date
    Feb 2006
    Location
    Tulsa, Oklahoma
    Posts
    20
    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.
    Last edited by Knight Chat X; 10-01-2012 at 05:29 AM. Reason: I give up.

  10. #10
    Senior Member OpenGL Pro
    Join Date
    Jan 2007
    Posts
    1,136
    Quote Originally Posted by Knight Chat X View Post
    <snip>
    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: http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx
    D3DX is a library of tools designed to provide additional graphics functionality on top of Direct3D.
    And: http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •