Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (803)
Games in Android Showcase (237)
games submitted by our members
Games in WIP (867)
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  
  Problems with colors and samples mixing in GLSL shaders  (Read 6537 times)
0 Members and 1 Guest are viewing this topic.
Offline wessles
« Posted 2014-02-05 22:29:42 »

Hello all!

I have a slight issue here. I have a shader in which I pass the color and sample into the fragment. The texture renders fine, but when I want to draw a plain colored cube, it will be tainted black. This is because I am using mix(), mixing the color and texture.

I can fix this by passing in a uniform u_sampled, which will act as a switch between mixing the texture and color, or just the color. This is pretty messy, however... So my question is: how can I figure out if a texture (sample) is bound from the shader?

-wes  Smiley
Offline Gef
« Reply #1 - Posted 2014-02-05 22:41:17 »

Few articles on internet said that starting GLSL 1.3, but I've never used it :
if( textureSize( SamplerDiffuse, 0).x > 0)
   // sample texture
   // use color

Say us if that works !

Offline theagentd
« Reply #2 - Posted 2014-02-05 22:48:23 »

Create a 4x4 texture filled with white pixels and bind that when you want to use "no" texture.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Gef
« Reply #3 - Posted 2014-02-05 22:50:35 »

I though of that solution too, but that will not break the mix between the color and the white pixel, no ?

Perhaps you can play and force the mix_factor to 0 or 1...

Offline theagentd
« Reply #4 - Posted 2014-02-05 23:09:03 »

This is what I'm seeing at the moment:

 - You're shader expects that you have a texture and mixes between an input color and a texture sample.
 - You currently don't have a texture bound.
 - You expect your shader to magically adapt and ignore the texture, but instead GLSL does the only logical thing and feeds you black.

Offline quew8

JGO Knight

Medals: 53

« Reply #5 - Posted 2014-02-05 23:09:21 »

Conditional statements in shaders are worse than messy. They are slow. Very slow. Either do as @theagentd says, as @Gef says or just use a different shader. There is no other way I'm afraid.
Offline Gef
« Reply #6 - Posted 2014-02-05 23:14:56 »

You can also use the same shader with preprocessor like "#ifdef", to enable/disable parts in your shader at compilation.
At the end, you have one shader to maintain but two or more different versions declared in your Java code.
    // mix color with texture
    // use color

Offline theagentd
« Reply #7 - Posted 2014-02-06 00:13:32 »

Conditional statements in shaders are worse than messy. They are slow. Very slow.
This is a common misconception. If-statements aren't expensive per se, but they have some quirks which can make them useless for performance gains.

First of all, conditional assignments are extremely cheap. Example:
x = myBoolean ? 10 : 5;

Secondly, on OpenGL cards with dynamic branching, if-statements can actually increase performance. Many people want to use if-statements to skip work in shaders, realize that they give no performance gain (but also don't performance cost!) and proclaim that if-statements are slow. GPUs runs shaders in groups, usually of 16x16 pixels, but the processors on your GPU aren't very flexible. If you have an if-else-statement in your shader and 255 pixels pass the if-statement and just a single pixel does (= enters the else-block), all 256 shader executions will run both the if and else blocks. For example, I had code that skipped work for pixels with depth=1.0 (meaning the sky was visible so I can skip some computations) and it worked very well, since the sky pixels were generally a continuous area on the screen, so a significant number of 16x16 blocks could skip the computation. If you on the other hand were to look at the sky through the branches of a tree, this would break down since most 16x16 blocks would have at least a few pixels that the branches or leaves covered, so the whole block would have to run the computations.

Pages: [1]
  ignore  |  Print  

Riven (397 views)
2019-09-04 15:33:17

hadezbladez (5280 views)
2018-11-16 13:46:03

hadezbladez (2204 views)
2018-11-16 13:41:33

hadezbladez (5544 views)
2018-11-16 13:35:35

hadezbladez (1150 views)
2018-11-16 13:32:03

EgonOlsen (4584 views)
2018-06-10 19:43:48

EgonOlsen (5462 views)
2018-06-10 19:43:44

EgonOlsen (3119 views)
2018-06-10 19:43:20

DesertCoockie (4015 views)
2018-05-13 18:23:11

nelsongames (4708 views)
2018-04-24 18:15:36
A NON-ideal modular configuration for Eclipse with JavaFX
by philfrei
2019-12-19 19:35:12

Java Gaming Resources
by philfrei
2019-05-14 16:15:13

Deployment and Packaging
by philfrei
2019-05-08 15:15:36

Deployment and Packaging
by philfrei
2019-05-08 15:13:34

Deployment and Packaging
by philfrei
2019-02-17 20:25:53

Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08 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‑
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!