Jump to content

  • Log In with Google      Sign In   
  • Create Account

D.V.D

Member Since 20 Aug 2012
Offline Last Active Yesterday, 11:52 PM

Posts I've Made

In Topic: Uniform Buffer Confusion

28 October 2014 - 11:54 PM

Hey, sorry for such a late reply. Midterms came along and ate way more time than I thought they would. 

 

So using the shader script, you assume that the given parameters, block names, and what not match up with the required uniform buffers for a shader program. It also seems like your shader program stores a list of buffers that it requests from the Renderable, and then binds them to the proper indices (which I’m probably going to do too, seems to work really well). Okay so I did some wrapping and implementation and got my GLShaderProgram class to support my GLUniformBuffer class. As shown before, my Uniform buffer class stores a class called UniformBufferAttributes which holds the name of the Uniform Buffer, the size of the uniform buffer, and the array of offsets. Originally, I also wanted GLShaderProgram to store a list of UniformBufferAttributes which it would then use to compare each uniform buffer thats being binded. That way, I could verify before binding whether or not I'm passing the properly encoded uniform buffer to the shader instead of passing and then waiting for an error. 

 

I still think this process has some benefits since the drivers might let the Uniform Buffer shader run even if it’s missing some of the parameters. As an example, if I give 3 vertex locations in my shader but only have 2 in the actual data + only 2 enabled using glEnableVertexAttribute, the program still renders the cube correctly on my hardware. I'm assuming other driver implementations might throw an error so I'm debating keeping Uniform Buffer attributes just for proper error checking.

 

On the opposite side of the argument, storing the offsets to do comparisons each frame for each UBO is probably a lot of extra overhead just for error checking, so instead of having uniform buffer attributes, I might be better off with only keeping the UBO name and letting OpenGL throw the error itself. I'm not sure if it will consistently come up on glGetError if not enough parameters are given to the UBO or if it will just give 0 values and run.

 

As for the shader scripting part to give parameters to UBO's, I think I might go with having some kind of special Uniform Buffers. My idea now is that via shader script (which I'm assuming is just some XML file stored with a model we are loading), I can give init values for all my required parameters, however certain UBO's will change every frame. An example is a UBO for orientation, it needs to have the orientation updated every frame so we need a way of distinguishing it from other UBO's.

 

Lastly, about the example of switching lighting from Phong to Physically Based to Toon, I think in my implementation, it would make sense if the shader script had a uniform buffer specified for each case. So then when the shader requests a uniform buffer, it just pulls the Toon shader one vs the others since the names could be different. Then as a backup, there could be a default uniform buffer created by the GLShaderProgram if no toon shader buffer is provided.

 

I think I'm starting to get how the whole thing should work :D


In Topic: Uniform Buffer Confusion

20 October 2014 - 01:38 PM

 


Okay so basically you avoid the whole problem of having to get a uniform buffer's index by making sure all shaders follow a naming convention for their uniform buffers. But what happens when I have a model which in the game, had something happen to it where before it was being rendered by a certain shader program but now were making it rendered by another shader program. This new shader program takes in 4 uniform buffers while the previous one took in 3. Do you just assume that while the renderable was being switched from one shader program to another, that whatever switched it knew it had to provide a new uniform buffer?

A shader script is part of a rendering pipeline. As such a specific script has to do what the pipeline needs at the stage where the script is used, and the script can use whatever the stage (directly and indirectly) provides but nothing more. Moreover, there is a correspondence of the scripts functionality and the parameters provided by the uniform buffers. For example, if a game entity should be rendered by using the Gooch NPR technique, the entity must provide the suitable parameters in its "material" block. Switching over to the Toon shader requires the material block to be switched, too.

 

In fact I don't try to avoid requesting indexes of uniform blocks (which can simply be requested once and stored for later use). Instead I define how scripts have to work in specific situations. So I know which names to use for the uniform blocks of scripts of a specific type. If a particular script can be replaced by another one where the latter uses an additional parameter block, then it means that the former script simply does without it because it doesn't need it although it could use it. In other words, I don't allow for arbitrary scripts because they would not fit into the bigger architecture.

 

Okay I'm slightly understand this. I haven't seen a shader script before but from what I understand, you get the parameters for each uniform buffer from the shader script which also describes how the uniform buffers must be set when you switch from one shader script to another. But then you need to specify how a shader script must populate its uniform buffers from all possible switches between shader scripts. So switching between toon/phong/physically based shading requires each shader script for toon/phong/... to have info on how to set its uniform buffers when switching between any of the other types of shaders. Doesn't that kind of reliance on other shader scripts cause a lot of potential for errors or am I completely misunderstanding this?

 

 

 

I see, it still doesn't make sense how you would know if the uniform buffers provided fulfill the shader program requirments.

 

 

Personally, if the shader does not contain the specific uniform buffer name (using glGetUniformBlockIndex), I ignore it/send a warning to the console.

 

Moreover, my renderer is a deferred renderer so I more or less know exactly what kind of shaders I have at any given time.

 

Sorry I should have rephrased it, what happens if you don't give a required uniform buffer for a shader because the object being rendered doesn't have it? In that case, you can't figure out if one of the uniform buffers needed for the shader hasn't been given since you can't query the names of all uniform buffers in a shader. Its weird that I can't query that since I can do that for uniforms, is there maybe a variant of glGetProgramiv that lets me get all the uniform buffer names in a shader program?


In Topic: Uniform Buffer Confusion

17 October 2014 - 12:46 PM

I'm dealing with this issue by suiting the graphics rendering pipeline and the shader scripts together. A specific kind of render pipeline has its specific stages: Forward lighting, material rendering, screen-space lighting, tone mapping, image post-processing, ... whatever. There are several kinds of properties needed: Material properties for physical based shading (or the suitable NPR properties for NPR rendering; let's call this material, too), camera set-up, screen rect, lights, and so on. Different stages have (partially) distinct requirements, but inside a stage the requirements are fixed.

 

So here is the deal: A camera provides a uniform block with its parameters, the screen provides one with its own parameters, the model provides one with its material, a post-process provides one with its parameters, a pipeline stage provides one, and perhaps other do so. Each block coming from such a source has an equivalent in the respective shader scripts, and there is a standard name used for it: E.g. CameraSetup, ScreenRect, Material, ... So it is convention that every script implementing forward rendering or material rendering has a slot for e.g. a Material block. Hence one can expect to have blocks with a specific name in a script suitable for a specific kind of rendering stage.

 

The higher level of rendering is implemented inside the stages of the render pipeline. It fetches the suitable blocks from the various sources and generates suitable binding instructions in the state part of the rendering jobs. The lower level of rendering (i.e. the one that calls OpenGL) then has to process those without the need to know the specific meaning of the parameters in a block.

 

Perhaps it is worth to mention that I use std140 layout. This makes things easier at least if the block is shared over many calls, like e.g. CameraSetup.

Okay so basically you avoid the whole problem of having to get a uniform buffer's index by making sure all shaders follow a naming convention for their uniform buffers. But what happens when I have a model which in the game, had something happen to it where before it was being rendered by a certain shader program but now were making it rendered by another shader program. This new shader program takes in 4 uniform buffers while the previous one took in 3. Do you just assume that while the renderable was being switched from one shader program to another, that whatever switched it knew it had to provide a new uniform buffer? It still seems weird to me that I can't get the uniform buffer requirments for each shader program by name.

 

I do it in the following way:

 

My UniformBuffer has a usage flag, which is "Default" or "Shared". Now we have 2 scenarios on using the UBO:

 

1) If the UniformBuffer usage is "Shared", then the UBO send an event to the ShaderManager to register this UBO to all the loaded shaders. In my engine it's guaranteed that all the shaders are pre-loaded, so when you create a shared UBO, it's also guaranteed that all the shaders will know about it. When the renderer is binding a shader, it also binds its registered UBOs.

 

2) If the UniformBuffer usage is "Default", then I manually register the UBO to whichever shader I want.

 

I use the std140 layout as well.

I am not sure if this approach is 100% correct though. Reading haegarr's approach makes me re-think of my design a bit.

I see, it still doesn't make sense how you would know if the uniform buffers provided fulfill the shader program requirments.


In Topic: Rendered Object disappears under Perspective Projection

27 September 2014 - 03:07 PM

Okay so I tried it and I found the issue with my code. When I had a value in the translation matrix for the object, it would disappear however when I tried your suggestion to put -10 to all z values, multiplying the vertices in the shader by just the projection matrix worked. So the issue had to be in the translation matrix since giving this any value in the z direction caused it to disappear. Turns out I didn't update the code in this matrix to use glm but instead I was setting the values manually and I probably made a mistake somewhere along the way. Changing that function made everything work properly in terms of the objects orientation :D. Thanks a lot!


In Topic: Game Actor and System Architecture

02 July 2014 - 08:02 PM

Hmm okay I'm starting to see a path through this. The perception idea is super cool but I probably don't need to implement something as complicated as that for my game in terms of touch, sound, smell etc with the stimuli. It is something I will want to look at in the future just because it sounds so cool and plays well with some other ideas I have bouncing around in my head. Okay so I think I figured out a nice way of organizing everything:

 

To start off, actors are as always just a id and a collection of components except now they are a collection of component id's instead of pointers. 

 

Components of each type are instead stored in each of their own component managers which might be just a list, a vector or a map. This would allow for future endeavors to compress the components since we know each component manager only holds variables of one component type. As an example, if my component manager holds orientation components for all actors, it could apply some sort of spacial optimization to all the components or reuse similar coordinates if such compression where ever needed. It also has the capability of being more data oriented although since my project isn't going to be huge, I'll just leave them as maps. Each component manager has to only implement simple methods like add/destroy component and get component manager type.

 

Components are same as always except now initialization will be a little different. So before, I just had a Init method for the actor to call Init on all components but now I added a post init which could be used to resolve all component dependencies. A orientation component won't have a dependency so its PostInit method will be empty. But something like a physics collision component could add in post init a dependency to the orientation by going through the owner actor pointer and searching for a component of type orientation. I could also have it add a collision response component/s which could be used to resolve collisions in the physics system when they happen. The benefit of post init is that we know all components are created, we are now just linking them together sort of like your program compiles everything, and then links. 

 

In PostInit, we could also attach our components to all the systems they have to be attached to. So a physics collision model could check to see if a orientation and collision response component exist on its current actor. If they do, it can link them up and attach itself to the physics system. Otherwise, it could signal an error or maybe run a default although I would rather signal an error.

 

As for BeerNutts method of solving the collisions, I think with the system I described above you could implement it since I sort of wrapped my head around settling dependencies between components. I do have two options however. I could make multiple collision responses for collision with different types of actors (although this creates a issue since a actor doesn't really have a type, its just a bundle of components). Or could make one large collision response component that handles multiple collision types. Both are a bit weird since a actor doesn't have a type. Would you somehow grab it from the collision model component which could potentially hold a type or add a type to each actor by default? 

 

There is another thing that bothers me that might be a bit more physics related but still something I think needs to be understood by me. Lets say two teleporters collide (yes this shouldn't ever happen but there could be other similar situations). Both objects have equal priority in terms of resolving the collision so which one would take priority and teleport the other to the teleporting location? Since its very likely two colliding actors will try to somehow resolve a collision, if both collision responses want to modify the other actor, it has to be somehow decided which one gets priority over the other and applies the modification first. 

 

I was also of thinking of just having a collision response actor that implements rigid body responses to collision, instead of having it in the physics system. That way, the physics system only ever worries about finding collisions and calling the appropriate collision response calls based on whatever priority. By doing so, the actor components technically implement all the systems while the system manages them to have everything work as a group.

 

Thanks for all the help so far!!

 

EDIT: Hmm, looking at it now, I think its better to skip having the component managers in the first place since for now, they don't really make a difference other than take extra implementation time. Maybe in the future I should add them in but everything else should apply as long as id's are changed to pointers.


PARTNERS