Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 25 Jan 2010
Offline Last Active Nov 19 2014 12:44 PM

Posts I've Made

In Topic: Sharing transformed vertices in subsequent render stages?

22 October 2014 - 01:34 PM

Thanks a lot, for this reply....I knew about the old/deprecated fixed function feedback system, but didn't realize there was an official replacement for the shader world.  I'll do some more reading before diving in, but it looks to be a great solution.


I know the transformation is relatively cheap, but in my current implementation it is happening for 6 stages of render, per model, with potentially thousands of models.  I'm also going to be doing something similar for label rendering, but will need to be able to generate the NDC coord buffer and potentially read it back for de-clutter processing on the CPU.  Having a shader stage that will just populate an NDC coord buffer for readback/post-processing would be awesome.


There's also a lot you can do to avoid needing so many stages of redundant vertex transformation. For instance, you can render the geometry once and then write material IDs and properties to another set of buffers and do passes over those (whether or not this is faster will depend on a lot of factors, so as always, measure and see).


Sorry, but I don't quite follow you here...can you describe a bit more, or link some reading material?


Thanks again!

In Topic: GL 3.3 glDrawElements VAO issue...AMD bug or my mistake?

20 August 2014 - 01:48 PM

Update #2:  Problem solved!


For anyone encountering similar issues, it turns out some older ATI cards (maybe newer) do NOT like vertex array attributes that are not aligned to 4-byte boundaries.   I changed my color array to pass 4 unsigned bytes instead of 3, and updated my shader to accept vec4 instead of vec3 for that attribute and everything now works as intended.


Kind of a silly issue....but that is what i get for trying to cut corners on memory bandwidth, etc.  =P

In Topic: GL 3.3 glDrawElements VAO issue...AMD bug or my mistake?

20 August 2014 - 10:53 AM

I still haven't figured out the root of the issue, but as a test I have switched to using floats for my color attribute instead of gl_unsigned_byte.  My unsigned byte colors were being passed in the range 0..255 with normalized set to GL_TRUE, and floats are passed 0..1.0 with normalized param of GL_FALSE.  Without really changing anything else , the problem goes away completely, so I am really suspicious of the ATI driver...
Anyone else seeing issues using multiple glDrawElement calls from a single bound VAO containing unsigned-byte color vertex attributes?


In Topic: GLSL 330 sampler2D array access via vertex attribute?

14 August 2014 - 07:12 AM

Your link might be a workable option, but having read a bit more I think I might be confusing people with my description.


I think the real compatibility issue is more generalized to accessing a uniform array from within the fragment shader using a non-constant index.   The index variable I am using is originally received in the vertex shader as an attribute (in), and passed to the fragment shader (out),  The fragment shader then  uses that to index into the uniform array of texture samplers.   


What I've found in hindsight is that glsl 330 doesn't like using any form of variable as an index into said uniform array, even though NVidia seems to allow it.  =/

In Topic: Orthographic-like billboards in perspective projection?

31 July 2014 - 07:17 AM


Thanks for the response!  I see what you are saying and I think it makes complete sense....Being still somewhat new to shaders, I forget that the view frustum clipping doesn't happen prior to my vertex shader stage....for some reason I was assuming that GL would throw away my 3D vertices once I had set up for an ortho viewport/pixel-based coord system.  


Sometimes it is easy to fall back into a fixed-function mentality.. =P