Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (106)
games submitted by our members
Games in WIP (533)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  GLSL: Force attribute to be used  (Read 2568 times)
0 Members and 1 Guest are viewing this topic.
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Posted 2012-04-19 14:15:37 »

So I've got a Sprite class, which uses a simple vertex format of position (x,y), colour (r, g, b, a) and texCoords (u, v).

There's a corresponding 'textured' shader which has position, colour and texCoord attributes in it's vertex shader. So far so normal, everything works fine.

The problem is when I want to swap in an alternate texture. That one only uses position and texCoord, and ignores colour. For compatibility, the vertex shader still has a colour attribute, it's just unused. However some drivers (hello nVidia!) will decide the 'colour' attribute is unused, and optimise it out. That means my code now crashes because the shader doesn't actually expose the interface the source code looks like it does.

Does anyone know how to force a shader attribute to be included (ie. not optimised out)? Or any other alternate solutions to this?

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline Danny02
« Reply #1 - Posted 2012-04-19 14:18:26 »

you can always use
1  
#pragma optimize(off)


in your shader, but I strongly advise you to just support this kind of different shaders in your code.

Offline Spasi
« Reply #2 - Posted 2012-04-19 14:54:58 »

I'd use the same vertex/fragment shader combination in both cases. In the second case I'd set the colour vertex attribute to a constant no-op value (all 0.0 or all 1.0 depending on how you use it in the fragment shader). This is easily achieved with a single call to glColor4f or glVertexAttrib4f before making the draw call, assuming the bound VBO has no colour data.

Btw, the optimization behavior you're seeing is expected and in accordance to the GLSL spec.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #3 - Posted 2012-04-19 15:50:42 »

I'd use the same vertex/fragment shader combination in both cases. In the second case I'd set the colour vertex attribute to a constant no-op value (all 0.0 or all 1.0 depending on how you use it in the fragment shader). This is easily achieved with a single call to glColor4f or glVertexAttrib4f before making the draw call, assuming the bound VBO has no colour data.

I think you've got it backwards - my sprite is always sending position+colour+uvs, but a shader with an unused colour attrib has the colour attrib optimised out, so the sprite errors as it can't lookup the 'colour' attrib from the shader.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline theagentd
« Reply #4 - Posted 2012-04-19 17:27:44 »

Just don't enable the vertex attribute if it doesn't exist?

Myomyomyo.
Offline Spasi
« Reply #5 - Posted 2012-04-19 18:14:05 »

Indeed, this should be handled by the engine, there shouldn't be a colour attrib in the shader at all. But if you don't want to change the engine or the model data (or whatever you use to describe the model data to the engine), there's one stupid trick I use when I want to quickly test something and bump into unused attribute/uniform optimizations:

1  
2  
3  
4  
5  
6  
7  
8  
in vec4 dummyColor; // unused input
out vec4 fragOut;

void main(void) {
    ...
    fragOut = ... // normal fragment shader output
   fragOut += dummyColor * 0.00001; // dummyColor is used now and won't be optimized away
}
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #6 - Posted 2012-04-19 18:24:25 »

Hmm. The problem with skipping it if not found is that now the engine can no longer catch cases where you write a shader *expecting* to handle all attributes, but don't (say, you mis-spell colour) and your shader silently produces incorrect results.

The analogy would be to an interface function - the specs say you have shade(position, colour, uvs), you accept those arguments even if you ignore one of them.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline Danny02
« Reply #7 - Posted 2012-04-19 18:41:50 »

first off all, you can do everything. Of course you can somehow manage all the different cases(I do it somehow but don#t have time to look into my stuff to figure it out how^^)

have you tried my pragma? you can use it until you figured out how to handle this case with your engine
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #8 - Posted 2012-04-19 18:47:28 »

first off all, you can do everything.

Right now, I'm not sure that is the case - I simply don't get enough info back from the shader to distinguish between the two cases. Either missing attributes are ok, in which case misspelt variables won't be caught. Or missing attributes are not ok, which catches misspelt variables but doesn't allow shaders which only use a subset of their inputs.

I don't think disabling optimisations is a reasonable solution I'm afraid.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline Spasi
« Reply #9 - Posted 2012-04-19 18:53:58 »

You're correct, the shader source and geometry data alone are not enough to describe both situations. In Marathon I used to have configuration files (custom format + scripting support) that described what every shader expected from the engine: vertex attributes, texture maps, preprocessor #defines, dependencies on other shader fragments, etc. All that served as the "specs" you mentioned and any incompatibilities could easily be detected.
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

pw (25 views)
2014-07-24 01:59:36

Riven (25 views)
2014-07-23 21:16:32

Riven (19 views)
2014-07-23 21:07:15

Riven (22 views)
2014-07-23 20:56:16

ctomni231 (51 views)
2014-07-18 06:55:21

Zero Volt (46 views)
2014-07-17 23:47:54

danieldean (37 views)
2014-07-17 23:41:23

MustardPeter (40 views)
2014-07-16 23:30:00

Cero (56 views)
2014-07-16 00:42:17

Riven (55 views)
2014-07-14 18:02:53
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!