- Platform specifics: Linux changes
"Adding copy-written text to this wiki from other sites is not a good idea. All of the copied text must be rewritten."
The main idea was to reorganize the structure of the article and to provide focal points for the reader. Also one of the major goals was, to minimize the amount of text. In this case, - nothing could be better then the original quotes instead of reinventing the weel. Rewritten text of the main ideas of the original autors could change the meaning in unacceptable way, but i should try to do my best against that on the next revision of this article.
"This also makes me concerned about the source of that image you uploaded. Is that copy-written as well? If so, it will have to be removed and/or replaced by an image you can donate."
This image was exported personally by me from the kcachegrind while i profile the simple gl es application. So it's my ownership which i provide for gl wiki without any limits let it be under i.e. MIT licence.
"the styling of the text violates a lot of Wikipedia's manual of style"
Ok, i should pay more attention to the quality of style.
Hi Alfonse! Nothing about wayland currently, but check this out in context of our previous discussion where you said that: - "I'd be interested in seeing a discussion of how Wayland, EGL"
EGL, XCB, GL* & Forget About Xlib
Hi Alfonse. You removed my contributions from https://www.opengl.org/wiki/Getting_Started#Linux What is wrong with them and if so, - where i could read the rules of how to contribute convinient information according to this wiki conventions?
- Your content wasn't removed, but it was moved to Platform_specifics:_Linux to keep the main getting started page a little cleaner. Thanks for the contribution! Webmaster (talk) 09:07, 16 July 2015 (EDT)
- Yes, that was the idea. The content is quite good, but it's just too comprehensive for an introductory page like Getting Started. We don't want to overload new users with too much information all at once. Also, I'd be interested in seeing a discussion of how Wayland, EGL, and possibly Mir alter the dynamic of OpenGL usage on Linux. Alfonse (talk) 11:08, 16 July 2015 (EDT)
- Oh sorry for misunderstanding. Currently i have nothing to contribute about Wayland & EGL but topic is really hot for me and i'll do my best to research & contribute to it later.
- Have to say that i am ready to extend the article Platform_specifics:_Linux even more if it is convinient. Also i have to contribute about how to build & fix "OpenSceneGraph 3.3.8 (122) Incompatibile Errors Against OpenGL 4.3 Core Context/Profile (Linux)" In my opinion, - such kinds of frameworks are the good start point not only for beginers.
- I generally suggest following the standard Wikipedia guideline: Be Bold. You need not ask for permission to edit something. If you do something wrong, someone will notice and correct it or move it to a more appropriate place.
Hi Alfonse, I'm moving the Benchmark page (www.opengl.org/resources/benchmarks/) to the wiki. Where would you suggest we link to it from the main page of the wiki, or would we? Also, I would like to move the mailing list and newsgroups page from the main site to the wiki. Currently the best place I can see is under Getting Started->External Links->Other. Which seems rather buried. Any suggestions of how to structure that better? Thanks Webmaster (talk) 10:47, 11 March 2013 (PDT)
- These pages can be added to the "Other useful information" section at the bottom of the main page. The mailing list/etc page should probably be part of a general "getting help" resource page. I'm working on a more Wikipedia-like restructuring of the main page (see Test Main Page). I could see it going into the sidebar on that page once it's up-and-running. Alfonse (talk) 22:39, 11 March 2013 (PDT)
I only ask that you give constructive criticism or fix the problem instead of merely complaining. I'm not going to devote hours of my time trying to help people like myself looking for answers if that's the case.
- Hi, I've added a lot of information to the User:ElFarto/OpenGLBM page, and was looking for some thoughts on it. elFarto 04:52, 30 September 2011 (PDT)
- Here's the thing. Unless you intend to actually implement this API (perhaps on top of Linux and AMD's low-level stuff), I don't see what the point of discussing it is. Even if this API were the holy grail, it isn't going to be implemented by anyone unless you do the work yourself. So any discussion would be Sophistry; if nothing's going to come of it, what's the point of speculating?
- However, if you insist, I have added some commentary on the idea. Alfonse 11:30, 30 September 2011 (PDT)
I had a previous comment, but I found out it was correct. Thanks, great job.
I'm using last version of OpenGL in lwjgl and I found the solution of buffer Z problem with transparency using GL_DEPTH_TEST
" glEnable(GL_DEPTH_BUFFER_BIT); glAlphaFunc(GL_GREATER, 0.1f); "
Works fine, and other webs confirm that. If you read in the wiki...
"The Z buffer doesn't work as you might hope for transparent polygons. The problem is that the Z buffer prevents OpenGL from drawing pixels that are behind things that have already been drawn. Generally, that's pretty convenient, but when the thing in front is translucent, you need to see the things that are behind it. "
...you feel fuc***... but it's not true.
I can prove, GL_DEPTH_BUFFER_BIT and GL_GREATER works fine with the last version.
The first time I searched I read this, and I want to kill someone, I had planned everything with z buffer in my project. But I searched in net a little more and I found the solution.
If you do not want to show people the solution, it's your problem, but it works and many people appreciate. This page about trasnparency, not clarify absolutely anything if you have problems with buffer Z.
Moderation plugin added
There is a new moderation extension added to this wiki. You have been added to the automoderation list, so this should not affect you. The plugin has worked very well at curbing spam on the WebGL wiki over the last several months.
The much visited Getting Started https://www.khronos.org/opengl/wiki/Getting_Started page has a broken link that used to point to https://bitbucket.org/alfonse/gltut/wiki/Home. Have you closed up your repos on BitBucket, or moved them elsewhere?
- Technically BitBucket closed my repos, since they no longer support Mercurial. Mercurial support was the only reason I was still using BB, so when they stopped supporting it, I just left the platform. But I did move the tutorials elsewhere; I've updated the link. Alfonse (talk) 15:34, 5 October 2020 (UTC)
Textures do not have to have all images (mips) be the same format.
note: I'm too lazy to write the C version but can do if you need more proof.
This is what the spec OpenGL 4.6 spec says as well. Section 8.17 Texture Completeness
For one-, two-, and three-dimensional and one- and two-dimensional array textures, a texture is mipmap complete if all of the following conditions hold true:
- The set of mipmap images levelbase through q (where q is defined in section 8.14.3) were each specified with the same internal format.
- The dimensions of the images follow the sequence described in section 8.14.3.
- levelbase ≤ levelmax
Image levels k where k < levelbase or k > q are insignificant to the definition of completeness.
So, no, all images of a texture do not have to be the same format. Only images between TEXTURE_BASE_LEVEL and TEXUTRE_MAX_LEVEL
- That's all true. However, I don't think it is at all useful or meaningful to discuss such possibilities wihin the context of FBOs. The reason being that attaching an image from outside the base/max mipmap level range leads to an FBO that is attachment incomplete.
- And yes, I'm aware that you can still select the base level even if it differs in image format. But ultimately, I don't think it is a good idea to bring that up either. Especially considering that the glTexStorage series of APIs make this impossible to begin with. So even if it is possible to get away with it in limited cases, it's really better for everyone to just pretend that you need to use the same image format for all mipmaps. There's no downside to it, and the upside is less confusion and less having to remember esoteric rules of completeness.