OpenGL defines a few glGen* functions, for example:
glGenTextures
glGenFrameBuffers
glGenBuffers
Does id generated by glGen function is unique globally or only within a glGen context - for example glGenTextures ?
Object names are only unique within a given space of object names. Usually, that means for the object type itself: texture names, buffer names, etc.
The only exception to this are shader and program objects who share the same name space, and thus their names cannot overlap.
Related
Take this GLSL sample code:
layout(set = 0, binding = 0) uniform BlockName {
mat4 someMtx;
} instanceName;
What is the purpose of "BlockName" in this context?
I know you can use the block name to match inputs/outputs of pipeline stages. But what is the purpose for uniform blocks in Vulkan?
The purpose is that GLSL requires it.
GLSL was made for OpenGL. It can be used with Vulkan, but the actual features of GLSL were made to serve the needs of OpenGL. Since Vulkan is a very different API, that means you're going to sometimes have vestigial functionality.
Like these.
In OpenGL, resources are identified, and can be queried, by name. Two resources are the same resource if they use the same name (they also have to match with other properties or an error results, but a name match is a requirement). As such, block names were made part of the grammar of GLSL interface blocks. You can't not have them on any interface blocks (UBOs being a subset of interface blocks).
Vulkan (and SPIR-V) doesn't care about names. For interface variables, the name remains useful because the GLSL code itself uses that name when it wants to access that variable. But block names were only used by the external API; they were never used by GLSL code itself.
So when you use a GLSL construct that uses an interface-only name to feed an API that doesn't care about interface names, you get block names: a name that needs to exist because GLSL requires it but doesn't actually do the thing GLSL expects it to.
I look at this link https://learnopengl.com/Advanced-OpenGL/Advanced-GLSL
It says different program can share same binding point's uniform value, but it doesn't mention whether the vertex shader and fragment shader could share them same uniform buffer ?
If they could share, did I need to define the same uniform twice with the same name and the same binding
glBindBufferRange doesn't take a shader stage when you bind a buffer. As such, UBO binding points are not stage specific. Binding point 0, for example, is the same binding point whether you use it in a VS, FS, or both. Both names represent the same bound buffer object.
did I need to define the same uniform twice with the same name and the same binding
Yes, in exactly the same way that if you want to share some class in two different cpp files, both files have to have the same class definition. In C++, this is typically done via a header. In GLSL, it happens however you want it to happen.
I'm writing a program in OpenGL. There is a Gfx class which holds an OpenGL context and wraps the OpenGL library.
There is also a Texture class which wraps OpenGL texture names (including generation and deletion). The Texture class naturally has an implicit dependency on the Gfx class. But I want RAII, no pointers, and therefore think that the Texture class must be publicly accessible.
What is the cleanest way to express the dependency on a constructed Gfx instance?
Assuming the texture cannot exist without the context, looks like the constructor argument is proper in this case, possibly a std::shared_ptr<Gfx> (hope this is excused from your no-pointer policy - I consider it a C++ construct). This way Gfx will linger as long as at least one Texture is not disposed.
First of all, i don't know if the "key" pattern is accepted as general patter, but some sorts of it have been appearing all over SO recently, so...
What I want to do?
Create shader manipulation class in C++. My issue here particularly focuses on setting uniform values (values sent from C++ to GLSL "directly").
What's the problem?
(Quick explanation, so that people not accustomed to OpenGL can contribute too) -
Uniform variables are set by using global glUniform* functions, taking as first parameter the location of the uniform in currently bound shader (int);
So the common usage is:
glBindProgram(myProgramNum);
int Location = glGetUniformLocation(myProgramNum, "myUniformParameterName");
float myValue = 42.f; // arbitrary data
glUniform1f (Location, myValue);
I've created some of the methods I need to encapsulate the above, such as
void SetUniform1f (std::string const& name, float a);
void SetUniformVector3 (std::string const& name, CVector3 const& vec);
void SetUniformMatrix4 (std::string const& name, CMatrix4 const& mat);
I've noticed, however, that all these use the glGetUniformLocation(int, const char*). As some of them will be used in realtime, this would cause unnecessary performance overhead.
The first idea
I've thought that I could create two versions of each function - one taking std::string and value, and second int and value, thus allowing faster access.
However, it would make them no better than the pure OpenGL access, since user would still be able to send malicious parameter to them.
The second idea
So, the proper way do to it would be to generate some sort of "Key" object from shader class, containing location of given uniform. It would however need to be linked to specific CShader class instance, because one could generate key in one object and pass it to another, causing unwanted behavior.
And my question is - is something like this possible in C++? Do I have to keep pointer to "parent" object in the key object and test if it's valid parameter every time, or are there any language/Boost features that will allow some sort of syntaxic sugar around it?
What I was able to deduce myself, the key class should be nested in CShader, and had CShader as friend. Also it should declare trivial constructor private, and overload copy-constructor so that copied objects will still be valid keys.
You need only an integer to set an uniform variable. Indeed, instead of calling a bunch of glGetUniformLocation, why don't you cache those values in a std::map<std::string, int>? Querying the map would be faster, isn't it?
Not everything is clear in you question (parent pointer?, malicious values?), but at the end an hypothetical user of a CShader class wants a shortcut for setting up uniform values. Indeed you can query uniforms after shader linkage (using glGetActiveUniform) or you can query uniform and cache uniform location when necessary.
I have some attributes in my EClasses I would like to initialize to a computed value when an instance is created. I'm wondering what the recommended way to do this using the framework is.
In one case I'd like to initialize the id attribute to a UUID. In this case I'd like the UUID value to be assigned when the object is first created and then remain the same for the life of the object.
In another case I'd like to generate a short id that only needs to be unique within the model instance.
I'm new to EMF and would greatly appreciate any guidance.
In both cases, I usually make the attributes suppress Setter and initialize the them in the default constructor.
the UUID is generated via EcoreUtils.generateUUID()
the class unique id is generated from a class static nextID
The attributes are not made unchangeable as we must (normally) be able to load a XML file and these must take precedence over the ones set in the constructors.
The class unique id, is slightly more difficult to handle as we must also initialize nextID to a good value when the application starts.
Consider the sequence where we create a number of objects first and then load an old file: how do we ensure there are no duplicates between the objects? One possible method is to divide the id into two parts: a timestamp and a sequence number. Assuming we cannot restart the application within the resolution of the timestamp (usually one second) this works quites all right.
This solution still assumes we never need to load two or more old files as these may conflict if created at the same time in different application instances....
All-in-all, I normally stick with UUIDs as this method avoids all of the above problems :-)