Implement Basic File Loading Into OpenGL's Standard.

[Aleksandar]

Why are my posts being trolled?

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.

[thokra]

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.

[Knight Chat X]

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.

Italics is not my style sorry.

[Knight Chat X]

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
And: http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx

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.

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.

[thokra]

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.

[Knight Chat X]

[QUOTE]

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?:
http://www.youtube.com/watch?v=EWMtfYAkGek

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.:
http://www.youtube.com/watch?v=-Vx6DxJCyRk

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:
http://www.youtube.com/watch?v=rF9Tu...eature=related

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

[mhagain]

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.

[thokra]

Maybe deprecated but the system contains lighting and via shading.

No, it's removed from core OpenGL 3.1+. The only reason fixed-function stuff is still around is because first and foremost AMD and NVIDIA implement GL_ARB_compatibility. And there is no lighting whatsoever in shaders - you can implement shading models using shaders but with the fixed-function pipeline gone, all the built-in GLSL state for fixed light sources is gone.

Input for picking aka selection, etc...

Fixed-function support for selection is gone as well. You can either implement it using shaders or do picking directly on the scene contents using ray-casting.

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

You realize that these may not even be implemented on any system, right? Also, there is no guarantee that what's important to most applications, i.e. the application layer, is actually implemented on the system you're targeting. Also OpenSL ES is what is is: a standard for embedded systems which is probably not available on any desktop system. You seem to neglect that these are specifications, not software, like many people do.

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.

Memory stacks? You mean matrix stacks. BTW, matrix stacks are gone, just like glTranslate, glRotate, glScale and all the stuff related to and layered on it. So yes, I will say it - again: OpenGL doesn't include any functions for doing linear algebra anymore. Welcome to OpenGL 3.1+ and Direct3D 10.

Ok I got it, the resistence is futile.

Assimilation in terms of wising up and actually doing research is a good thing. The Borg aren't always wrong.

Edit: Holy moly, I didn't even read this one before.

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.

The N64 was released 4 years after OpenGL 1.0 ...

[V-man]

Ok, let's bottom line this. You want some library for reading model files such as OBJ, 3ds, milkshape, X. There are already such libraries available as homebrew projects. Khronos/ARB are not going to write one for you. These guys write specifications.
It will certainly not go into OpenGL because this library is just for communicating with the GPU.
nVidia, AMD, INTEL, APPLE are not going to write a model loader into their graphics driver.

[kRogue]

Just an aside, a long time ago, one used GLU to do some utility things [stretch image data to be power of 2, some perspective matrices for you, etc]. GLU, analogous to D3DX is built on top of GL.. but pre GL3, so much of what it did does not make any sense for GL3 core and newer.

On the other hand, what would be nice is a coordinated something for such a utility library. There are already LOTS of libs out there for such utility functionality for GL (gl, assimp, etc). What would be nice is something that collects it... wait we already have that on www.opengl.org: http://www.opengl.org/sdk/libs/. It might be a good idea to add to that page, say with a link to Assimp (I am not a huge fan of assimp because the last time I played with it, I could only capture the first frame of a key frame mode, getting joint animations out of some things did not happen, etc)....

What you want is a utility library on top of GL, nothing more. The key difference between GL and D3D is that GL is like the wild west, there are many ways and many libs to help you.. but all scattered all over the place where as in D3D it is integrated with the rest of the Win32/64 API which in turn gives it it's utility libraries all ready.