packing/unpacking in shader

[Rick]

Because the data we can send to the shaders is limited, I'm thinking about packing/unpacking (encoding/decoding) data into the color Vec4 to pass in more data. Does anyone know if this would cause any major performance issues by doing this since the shader code would have to unpack to get the actual values?

[Rick]

Looks like it can be done. I'm not sure what he means about the highp talk though.

 

http://stackoverflow.com/questions/6893302/decode-rgb-value-to-single-float-without-bit-shift-in-glsl

[Admin]

What data?

[shadmar]

You could add uniforms and just send your own using shader->SetFloat/Vec2,3,4.

[Rick]

For the subtexture shader I made, I want to also send offset and scale of the subtexture itself. Currently I'm using the alpha now for the scale, but I only apply it to the x of the vec2 ex_color. I tested on wall segments for the narrow sides and it works well to scale up the texture so it matches the longer sides, but the top part of the walls need the y value adjusted. Doing it uniformly doesn't work visually.

 

@shadmar This has to be model instance specific, and if I remember correctly the only model instance specific data currently is position/rotation/scale/color.

 

@Josh basically what I'm trying to do is make what the face selection of the CSG can do with the texture scale/offset, but for models that use my subtexture shader to give me more flexibility.

 

Playing around with my next game ideas, and it means making buildings like you do in The Sims where you have wall segments and you paint different images on any side of them. I can pretty much do that now with the color alpha being the scalar value for the x portion and leave the top part of the walls a solid black, but would be nice to have more flexibility with the textures.

 

Ideally we'd have some custom vec3 variables that are for us to use for whatever, but not sure if GLSL allows this or if it slows things down to much.