note that you can calculate the binormal by cross(normal, tangent)

personally, i make a vertex struct for every usage type, since many things have different needs

for example a fullscreen shader needs only vertices that are [0, 1], and the tex coords can be derived from the vertices!

example:

// tex coords directly

texCoord = in_vertex.xy;

// transformation to screenspace in ortographics projection (0, 1, 0, 1, zmin, zmax)

gl_Position = vec4(in_vertex.xy * 2.0 - 1.0, 0.0, 1.0);

unless you are confident this is your bottleneck, you should be in gDEBugger to find out where your performance bottlenecks really are!

one neat feature in gDEBugger is rendering in slow motion, so you can see the exact order of operations, including order of rendering your models

that way you can for example get a real estimate on how effective your z-culling and samples passed (query objects) will be

### Show differencesHistory of post edits

### #2Kaptein

Posted 18 November 2012 - 10:27 AM

note that you can calculate the binormal by cross(normal, tangent)

personally, i make a vertex struct for every usage type, since many things have different needs

for example a fullscreen shader needs only vertices that are [0, 1], and the tex coords can be derived from the vertices!

example:

// tex coords directly

texCoord = in_vertex.xy;

// transformation to screenspace

gl_Position = vec4(in_vertex.xy * 2.0 - 1.0, 0.0, 1.0);

unless you are confident this is your bottleneck, you should be in gDEBugger to find out where your performance bottlenecks really are!

one neat feature in gDEBugger is rendering in slow motion, so you can see the exact order of operations, including order of rendering your models

that way you can for example get a real estimate on how effective your z-culling and samples passed (query objects) will be

personally, i make a vertex struct for every usage type, since many things have different needs

for example a fullscreen shader needs only vertices that are [0, 1], and the tex coords can be derived from the vertices!

example:

// tex coords directly

texCoord = in_vertex.xy;

// transformation to screenspace

gl_Position = vec4(in_vertex.xy * 2.0 - 1.0, 0.0, 1.0);

unless you are confident this is your bottleneck, you should be in gDEBugger to find out where your performance bottlenecks really are!

one neat feature in gDEBugger is rendering in slow motion, so you can see the exact order of operations, including order of rendering your models

that way you can for example get a real estimate on how effective your z-culling and samples passed (query objects) will be

### #1Kaptein

Posted 18 November 2012 - 10:24 AM

note that you can calculate the binormal by cross(normal, tangent)

personally, i make a vertex struct for every usage type, since many things have different needs

for example a fullscreen shader needs only vertices that are [0, 1], and the tex coords can be derived from the vertices!

you can also the opposite:

texCoord = in_vertex.xy;

gl_Position = vec4(in_vertex.xy * 2.0 - 1.0, 0.0, 1.0);

unless you are confident this is your bottleneck, you should be in gDEBugger to find out where your performance bottlenecks really are!

one neat feature in gDEBugger is rendering in slow motion, so you can see the exact order of operations, including order of rendering your models

that way you can for example get a real estimate on how effective your z-culling and samples passed (query objects) will be

personally, i make a vertex struct for every usage type, since many things have different needs

for example a fullscreen shader needs only vertices that are [0, 1], and the tex coords can be derived from the vertices!

you can also the opposite:

texCoord = in_vertex.xy;

gl_Position = vec4(in_vertex.xy * 2.0 - 1.0, 0.0, 1.0);

unless you are confident this is your bottleneck, you should be in gDEBugger to find out where your performance bottlenecks really are!

one neat feature in gDEBugger is rendering in slow motion, so you can see the exact order of operations, including order of rendering your models

that way you can for example get a real estimate on how effective your z-culling and samples passed (query objects) will be