Jump to content

  • Log In with Google      Sign In   
  • Create Account


beans222

Member Since 21 Jul 2012
Online Last Active Today, 05:23 PM

#5017503 I need help understanding ARB_instanced_arrays.

Posted by beans222 on 04 January 2013 - 03:12 PM

The VBO is just a normal VBO. It just contains matrices. The glVertexAttribPointers setup the attribute for the shader. More than one are needed because GLSL implements matrix attributes as 4 vec4s with consecutive positions/IDs; the stride is a full 4x4 matrix. The glVertexAttribDivisor =1 tells GL that that attribute is per each instance draw (rather than per vertex =0).

 

After setting all that up, assuming your shader is set up to use the attribute for the world transform instead of a uniform, then you just call glDrawElementsInstanced which takes the number of instances as the last parameter that matches the number of matrices in your VBO.




#5017304 Passing attributes to shaders

Posted by beans222 on 03 January 2013 - 05:40 PM

Check that your program object is linking properly.




#5015538 Miscellaneous OpenGL questions (mostly dealing with shaders)

Posted by beans222 on 29 December 2012 - 03:20 PM

I couldn't disagree more. However, everything depends on what "results you're looking for". That custom shader that outputs the values does just that and often only that. Then the shaders that do lighting are completely separate. Now you have much fewer shaders as well as many more lights. Clever implementations even get more dynamic shadowing (I haven't looked at those much though).

 

I'd have to disagree that deferred shading is any harder than forward, especially if you've done something like shadow mapping before (ie, you've done more with OpenGL than send a single tri through a VAO). I thought you summarized deferred (in the manner that most would implement) rather succinctly, and of course more research would be needed to implement it.

 

The lighting shader(s) for deferred are a lot less complicated than the uber-shader or 293485 shaders for various combinations of diffuse texturing (splatting, bump, etc), shadow or not, number of lights on object, etc. Perhaps not just one, but not a "super-shader" when it has a single, easily maintainable task to perform per shader. Separable shader objects help, but I really prefer the clean split.

 

You'd have to be more controlled in the way you render your scene, with the different render targets and the way you pack/unpack information, etc. In one word, you'd have to be an obsessive with your rendering pipeline.

 

Curious, filling a few buffers with carefully chosen layouts is hardly obsessive (I apologize for the censorship, but it wasn't relevent to what I was quoting, so I just left it out). In what way to you need to be more controlled? I get needing a forward pass for transparency, but chances are there's not that much of that and you didn't need that many lighting effects from it anyway (or at least I don't which is why I don't mind needing the pass for it).




#5015345 Miscellaneous OpenGL questions (mostly dealing with shaders)

Posted by beans222 on 29 December 2012 - 12:23 AM

I know you can apply shaders to models, and basic lighting can be done that way. Is there a way to use a shader to add lighting to every model in a scene at once? I'm having a very hard time specifying this question dry.png

 

If you use deferred shading (as described by LordJulian above), you are no longer on the level of individual meshes, as (often) all you have is the relevent shading data for that pixel. A common technique is to draw bounding geometry for calculating dynamic lighting so that lighting is only calculated if the light is visible and touching (or close to touching) those pixels. Deferred shading can also be useful to reduce the number and complexity of shaders due to its separation of calculating diffuse color from pretty much all of the lighting options.




#5014606 What kind of optimization makes C++ faster than C#?

Posted by beans222 on 26 December 2012 - 11:21 PM

C++ operates at a lower level of abstraction than C#. In C++, you could (if you wanted to) trivially fill an array with machine code, cast it to a function and run that code (it would no longer have any amount of portability at that point).

C# compiles to a bytecode that wasn't the machine code of any processor (I say 'wasn't' because I haven't followed C# in a while; they may have built one since). C# programs are run by what is often called an interpreter even though C# runtime has always compiled to machine code on the fly. In a C++ program, the progammer has manual access to freeing memory (as well as the pointers to/within it). A C# program uses the garbage collector to take care of freeing memory (as in, C# doesn't have a 'delete' operator, just 'new').

 

Some people might even argue that C# could be faster because C# gets compiled on the fly, the runtime knows exactly what the best actual machine instructions are for the users exact hardware (as opposed to a C++ compiler having to target some lower denominator of CPU like no-SSE, unless you actually provide multiple binaries for users to choose from or users compile themselves).

 

The fact that a C++ process will never slow down, use an extra thread (or *gasp* pause) for a garbage collection is probably one of the best reasons for people who like control. I thought was going to come up with better arguments, but other than memory access and allocation, it's late and I'm drawing a blank. The runtime compiling C# bytecode on the fly takes time too, and I imagine there's a threshold of how many interprets of the function before it decides to compile.




#5012866 [GL3] VAO and VBO question about dynamic/stream buffers

Posted by beans222 on 20 December 2012 - 12:21 PM

This page should have all the information: http://www.opengl.org/wiki/Buffer_Object_Streaming
There's no way around a glBindBuffer though.


#5010089 opengl 3/GLM matrix help

Posted by beans222 on 13 December 2012 - 12:56 AM

Check your ordering of multiplying the matrices together. The destination space of the combined matrix needs to be on the left of the multiply.
(both the multiplies in the first two lines of updateMatrices are backwards)

If you haven't already, do yourself a huge favor and read arcsynthesis.org/gltut all the way through. He explains all the math from the beginning and uses GLM for all the examples.


#4994812 Problems importing mesh (assimp)

Posted by beans222 on 28 October 2012 - 01:16 PM

Are you actually rendering quads? If not, you should have assimp make triangles (aiProcess_Triangulate). Also use aiProcess_JoinIdenticalVertices otherwise assimp will assume you don't want to be using an index buffer.


#4991276 [Solved] Simple GLSL Texture Troubleshoot

Posted by beans222 on 17 October 2012 - 05:25 PM

You can set _colorOut directly to the results of the texture call. An rgb texture made of unsigned bytes is a normalized format and will return 0.0-1.0 in the shader.


#4990119 [GLSL] Draw a textured (RGBA) polygon with opacity

Posted by beans222 on 14 October 2012 - 01:24 PM

You could also use the keyword 'flat' before 'varying' to turn off interpolation for that variable.


#4988230 Questions about GLEW and its versions

Posted by beans222 on 09 October 2012 - 12:03 AM

Newer versions of OpenGL include all of the functions introduced in previous versions, except for deprecated functions that should no longer be used anyway. Just get the most recent versioned context you can (hopefully 3.2/3+) and roll with it.

As far as I know, there's no reason to not always use the most recent GLEW version.


#4964580 Assimp and Direct3D 9

Posted by beans222 on 30 July 2012 - 01:06 PM

The final argument to memcpy should be the same as the length passed to create the buffer (as it's the total bytes to copy), and the sizeof in the index buffer one should be short, not int. ("numFaces * 3 * sizeof(short)" "numVertices * sizeof(SDX_CUSTOMVERTEX)"). Is type VERTEX (the type of array 'vertices') the same thing as SDX_CUSTOMVERTEX?

I think there's also a problem with the counters in the code that gets the data from Assimp. The index counter is based on the number of vertices which will almost never match the number of vertices. It would be better to use completely separate counters for vertex and index data and just add the mesh's mNumVertices and mNumFaces*3 to the respective counters at the end of the outer loop.


#4964271 Configure Visual Studio 2010 from ogl 1.1 to ogl 3.x or 4.x

Posted by beans222 on 29 July 2012 - 10:55 AM

Anything beyond 1.1 you need to query the function pointer through wglGetProcAddress. Using the library called GLEW is a fairly popular choice for gaining access to newer GL functions with minimal work on your part. If you search for GLEW, you'll likely find other libraries that would work just as well.


#4963849 Assimp and Direct3D 9

Posted by beans222 on 27 July 2012 - 09:31 PM

About that memcpy call for the indices, it looks like you are passing the size of the pointer (which will be 4 or 8) rather than the size of the array.


#4962698 Help with Shadow Mapping and Multi-Texturing

Posted by beans222 on 24 July 2012 - 01:09 PM

Ambient is supposed to be added in without being involved in the lambert calculations as part of its purpose is keeping things from being completely black, but that's obviously not important if the shadows are being stubborn.

As for the two textures, there's really no way to know what another coder was thinking if they didn't leave any notes. All shadow code I've seen disables color buffer drawing leaving it out of the FBO while only using the depth component texture in the shadow checking code.

Other than to try to using gluLookAt to build the light camera/view matrix, I'm out of ideas.




PARTNERS