Ogre 1.9, Radeon, Linux

Discussion area about developing or extending OGRE, adding plugins for it or building applications on it. No newbie questions please, use the Help forum for that.
Post Reply
cord
Halfling
Posts: 59
Joined: Tue Oct 22, 2013 10:22 am

Ogre 1.9, Radeon, Linux

Post by cord » Thu Nov 21, 2013 2:31 am

I'm stumped on a fragment shader issue. Fortunately, I can reproduce the issue on both NVidia and Radeon cards. I'm porting a glsl150 fragment shader to glsl. If you're thinking "just wait until the glsl150 shader is working," sorry, I'm not waiting. I will learn more by doing it.

Background:

I'm attempting to fix bugs in Ogre 1.9, and Sample_VolumeTerrain falls back to no texturing on my Radeon card, at least on Linux. That's because it's a glsl150 shader [1]. No problem, I'm not complaining or anything, but to get it to work on my card, I'm attempting to back-port it to glsl. I'm fairly sure it's because I'm using the GL RenderSystem instead of GL3+. I honestly haven't tried out GL3+ because it appears GL3+ is still in alpha.

Problem:

After fixing the obvious issues, I get this output: (on both an NVidia and a Radeon card)
triplanar_glsl.jpg
Shader Output
triplanar_glsl.jpg (209.59 KiB) Viewed 3450 times
It looks like it's sort-of working, but since triplanar texturing isn't that complicated of a concept, the problem is most likely some finicky bit of fragment shader code that a newbie like me won't know anything about. Is there someone with some more experience who could point out what's going on here?


Here are the changes I made to the triplanarReference.program:

Code: Select all

diff -r 05f0ce02f60d Samples/Media/volumeTerrain/triplanarReference.program
--- a/Samples/Media/volumeTerrain/triplanarReference.program	Sun Nov 17 23:17:48 2013 -0600
+++ b/Samples/Media/volumeTerrain/triplanarReference.program	Wed Nov 20 18:31:40 2013 -0700
@@ -128,7 +128,7 @@
 vertex_program TriplanarReferenceHigh_VSGLSL glsl
 {
 	source triplanarReferenceVS.glsl
-	syntax glsl150
+	syntax glsl
 	default_params
 	{
 		// Uncomment for Fog
@@ -142,7 +142,7 @@
 fragment_program TriplanarReferenceHigh_PSGLSL glsl
 {
 	source triplanarReferencePS.glsl
-	syntax glsl150
+	syntax glsl
 	default_params 
 	{
 		
@@ -190,7 +190,7 @@
 vertex_program TriplanarReferenceLow_VSGLSL glsl
 {
 	source triplanarReferenceVS.glsl
-	syntax glsl150
+	syntax glsl
 	default_params
 	{
 		// Uncomment for Fog
@@ -204,7 +204,7 @@
 fragment_program TriplanarReferenceLow_PSGLSL glsl
 {
 	source triplanarReferencePS.glsl
-	syntax glsl150
+	syntax glsl
 	default_params 
 	{
 		param_named_auto lightSpecular0 light_specular_colour 0
diff -r 05f0ce02f60d Samples/Media/volumeTerrain/triplanarReferencePS.glsl
--- a/Samples/Media/volumeTerrain/triplanarReferencePS.glsl	Sun Nov 17 23:17:48 2013 -0600
+++ b/Samples/Media/volumeTerrain/triplanarReferencePS.glsl	Wed Nov 20 18:31:40 2013 -0700
@@ -1,8 +1,6 @@
-#version 150
-
-in vec3 oPos;
-in vec4 oNormAndFogVal;
-in vec3 oEyePos;
+varying vec3 oPos;
+varying vec4 oNormAndFogVal;
+varying vec3 oEyePos;
 
 #if LIGHT0
 uniform vec4 lightPosition0;
@@ -47,11 +45,9 @@
 uniform sampler2D texFromZ;
 uniform sampler2D texFromZNormal;
 
-out vec4 fragColour;
-
 vec3 expand(vec3 v)
 {
-	return (v - 0.5) * 2;
+	return (v - 0.5) * 2.0;
 }
 
 vec4 lit(float NdotL, float NdotH, float m)
@@ -83,7 +79,7 @@
 	float nDotH = dot(halfAngle, normal);
 	vec4 lighting = lit(nDotL, nDotH, exponent);
 	
-	float attenuation = 1;
+	float attenuation = 1.0;
 	#if ATTENUATION
 	if (lightPosition.w != 0) {
 		float distance = length(lightPosition.xyz - oPos);
@@ -91,8 +87,8 @@
 	}
 	#endif
 	
-	float spot = 1;
-	if (!(lightSpotlight.x == 1 && lightSpotlight.y == 0 && lightSpotlight.z == 0 && lightSpotlight.w == 1)) {
+	float spot = 1.0;
+	if (!(lightSpotlight.x == 1.0 && lightSpotlight.y == 0.0 && lightSpotlight.z == 0.0 && lightSpotlight.w == 1.0)) {
 		spot = clamp(
 			(dot(lightDir, normalize(-lightSpotDir)) - lightSpotlight.y) /
 			(lightSpotlight.x - lightSpotlight.y), 0.0, 1.0);
@@ -103,14 +99,13 @@
 
 void main()
 {
-	
 	vec3 unitNormal = normalize(oNormAndFogVal.xyz);
 	vec3 eyeDir = normalize(oEyePos - oPos);
 		
 	// Ported from http://http.developer.nvidia.com/GPUGems3/gpugems3_ch01.html
 	vec3 blendWeights = abs(unitNormal);
 	blendWeights = blendWeights - plateauSize;
-	blendWeights = pow(max(blendWeights, 0), vec3(transitionSpeed));
+	blendWeights = pow(max(blendWeights, 0.0), vec3(transitionSpeed));
 	blendWeights /= vec3(blendWeights.x + blendWeights.y + blendWeights.z );
 	// Move the planar mapping a bit according to the normal length to avoid bad looking skirts.
 	float nLength = length(oNormAndFogVal.xyz - 1.0);
@@ -118,9 +113,9 @@
 	vec2 coord2 = (oPos.zx + nLength) * texScale;
 	vec2 coord3 = (oPos.xy + nLength) * texScale;
 	
-	vec4 col1 = texture(texFromX, coord1);
-	vec4 col2 = texture(texFromY, coord2);
-	vec4 col3 = texture(texFromZ, coord3);
+	vec4 col1 = texture2D(texFromX, coord1);
+	vec4 col2 = texture2D(texFromY, coord2);
+	vec4 col3 = texture2D(texFromZ, coord3);
 	vec4 textColour = vec4(col1.xyz * blendWeights.x +
 		col2.xyz * blendWeights.y +
 		col3.xyz * blendWeights.z, 1);
@@ -132,9 +127,9 @@
 	tangent = normalize(cross(unitNormal, binormal));
 	mat3 TBN = mat3(tangent, binormal, unitNormal);
 	vec3 eyeDir2 = normalize(TBN * eyeDir);
-	vec3 bumpFetch1 = expand(texture(texFromXNormal, coord1).rgb);
-    vec3 bumpFetch2 = expand(texture(texFromYNormal, coord2).rgb);
-    vec3 bumpFetch3 = expand(texture(texFromZNormal, coord3).rgb);
+	vec3 bumpFetch1 = expand(texture2D(texFromXNormal, coord1).rgb);
+    vec3 bumpFetch2 = expand(texture2D(texFromYNormal, coord2).rgb);
+    vec3 bumpFetch3 = expand(texture2D(texFromZNormal, coord3).rgb);
 	vec3 normal2 = bumpFetch1.xyz * blendWeights.x +  
 		bumpFetch2.xyz * blendWeights.y +  
 		bumpFetch3.xyz * blendWeights.z;
@@ -190,9 +185,9 @@
 	lightContribution += doLighting(oPos, normal2, eyeDir2, exponent, specularFactor, lightDir22, lightPosition2, lightDiffuse2, lightSpecular2, lightAttenuation2, lightSpotlight2, lightSpotDir22);
 	#endif
 	
-	fragColour = clamp(textColour * (lightContribution + ambient), 0.0, 1.0);
+	gl_FragColor = clamp(textColour * (lightContribution + ambient), 0.0, 1.0);
 	#if FOGLINEAR || FOGEXPONENTIAL || FOGEXPONENTIAL2
-	fragColour = mix(oColor, fogColour, oNormAndFogVal.w);
+	gl_FragColor = mix(oColor, fogColour, oNormAndFogVal.w);
 	#endif
 	
 }
diff -r 05f0ce02f60d Samples/Media/volumeTerrain/triplanarReferenceVS.glsl
--- a/Samples/Media/volumeTerrain/triplanarReferenceVS.glsl	Sun Nov 17 23:17:48 2013 -0600
+++ b/Samples/Media/volumeTerrain/triplanarReferenceVS.glsl	Wed Nov 20 18:31:40 2013 -0700
@@ -1,7 +1,5 @@
-#version 150
-
-in vec4 position;
-in vec3 normal;
+attribute vec4 position;
+attribute vec3 normal;
 
 uniform vec3 eyePosition;
 uniform mat4 worldviewproj;
@@ -10,9 +8,9 @@
 uniform vec4 fogParams;
 #endif
 
-out vec3 oPos;
-out vec4 oNormAndFogVal;
-out vec3 oEyePos;
+varying vec3 oPos;
+varying vec4 oNormAndFogVal;
+varying vec3 oEyePos;
 
 void main()
 {

[1] see Samples/Media/volumeTerrain/triplanarReference.program, search for "syntax glsl150"

"Supported Shader Profiles" only lists glsl in my log:

Code: Select all

RenderSystem capabilities
-------------------------
RenderSystem Name: OpenGL Rendering Subsystem
GPU Vendor: amd
Device Name: AMD Radeon HD 7900 Series
Driver Version: 4.2.12422.0   
 * Fixed function pipeline: yes
 * Hardware generation of mipmaps: no
 * Texture blending: yes
 * Anisotropic texture filtering: yes
 * Dot product texture operation: yes
 * Cube mapping: yes
 * Hardware stencil buffer: yes
   - Stencil depth: 8
   - Two sided stencil support: yes
   - Wrap stencil values: yes 
---8<---8<--- snip ---8<---8<---
 * Compute programs: no
 * Number of floating-point constants for compute programs: 0
 * Number of integer constants for compute programs: 0
 * Number of boolean constants for compute programs: 0
 * Supported Shader Profiles: arbfp1 arbvp1 glsl gp4gp gpu_gp nvgp4 ps_1_1 ps_1_2 ps_1_3 ps_1_4
0 x

User avatar
holocronweaver
Google Summer of Code Student
Google Summer of Code Student
Posts: 273
Joined: Mon Oct 29, 2012 8:52 pm
Location: Princeton, NJ

Re: Ogre 1.9, Radeon, Linux

Post by holocronweaver » Thu Nov 21, 2013 2:44 am

cord wrote:If you're thinking "just wait until the glsl150 shader is working," sorry, I'm not waiting. I will learn more by doing it.
I like your moxy. :)
I'm fairly sure it's because I'm using the GL RenderSystem instead of GL3+. I honestly haven't tried out GL3+ because it appears GL3+ is still in alpha.
I have this on my TODO in GL3+, but am experiencing the same problems on a Radeon. Will try to get it fixed tonight and then get back to you.
0 x

User avatar
holocronweaver
Google Summer of Code Student
Google Summer of Code Student
Posts: 273
Joined: Mon Oct 29, 2012 8:52 pm
Location: Princeton, NJ

Re: Ogre 1.9, Radeon, Linux

Post by holocronweaver » Thu Nov 21, 2013 3:30 am

Could someone please confirm that the Cg shaders are working? They were last I checked.
0 x

cord
Halfling
Posts: 59
Joined: Tue Oct 22, 2013 10:22 am

Re: Ogre 1.9, Radeon, Linux

Post by cord » Thu Nov 21, 2013 3:57 am

Sure, the Cg shader works.

Edit: comment out all the lines "delegate TriplanarReference*_*GLSL" in triplanarReference.program

This is the output:
triplanar_cg.jpg
Output
triplanar_cg.jpg (192.91 KiB) Viewed 3439 times
0 x

User avatar
holocronweaver
Google Summer of Code Student
Google Summer of Code Student
Posts: 273
Joined: Mon Oct 29, 2012 8:52 pm
Location: Princeton, NJ

Re: Ogre 1.9, Radeon, Linux

Post by holocronweaver » Thu Nov 21, 2013 4:08 am

Found one error in the lit function of triplanarReferencePS.glsl:

Code: Select all

float specular = step(0.0, NdotL) * max(NdotH * m, 0.0);
should be

Code: Select all

float specular = step(0.0, NdotL) * pow(max(NdotH, 0.0), m);
as per docs on Cg built-in lit. I am somewhat confused by the docs because I am not sure what the '?' operator means. The '?:' is ternary in Cg, but what is a lone question mark and why is it a binary operator?

How does that help things on your end?
0 x

cord
Halfling
Posts: 59
Joined: Tue Oct 22, 2013 10:22 am

Re: Ogre 1.9, Radeon, Linux

Post by cord » Thu Nov 21, 2013 4:14 am

It's a minor change for the worse on NVidia but no change at all on Radeon.

NVidia output:
nvidia_bug.jpg
NVidia Output
nvidia_bug.jpg (200.59 KiB) Viewed 3436 times
0 x

cord
Halfling
Posts: 59
Joined: Tue Oct 22, 2013 10:22 am

Re: Ogre 1.9, Radeon, Linux

Post by cord » Thu Nov 21, 2013 4:24 am

I did some testing to confirm, the black areas are all triplanarReferenceLOW. Moving closer to them switches them to HIGH and the black disappears.
0 x

cord
Halfling
Posts: 59
Joined: Tue Oct 22, 2013 10:22 am

Re: Ogre 1.9, Radeon, Linux

Post by cord » Thu Nov 21, 2013 4:30 am

It appears there are multiple bugs here.

Replace vec4 textColour = vec4(col1.xyz * blendWeights.x + col2.xyz * blendWeights.y + col3.xyz * blendWeights.z, 1);
with vec4 textColour = vec4(0.5,0.5,0.5,1.0);

Still it has the patches of black and white -- those must be the lighting calculations.

I then tried adding lightContribution = vec4(0,0,0,0); right before the final gl_FragColor = ... I noticed that the triplanar texturing is only using a single texture.

So there are at least two separate problems: lighting and the triplanar texturing.

If it would help, I'm on irc.freenode.net #ogre3d as dmamfmgm
0 x

User avatar
holocronweaver
Google Summer of Code Student
Google Summer of Code Student
Posts: 273
Joined: Mon Oct 29, 2012 8:52 pm
Location: Princeton, NJ

Re: Ogre 1.9, Radeon, Linux

Post by holocronweaver » Thu Nov 21, 2013 4:58 am

Using the fix I gave above, I currently have the GLSL 1.50 code looking like:
first_fix.jpg
first_fix.jpg (113.4 KiB) Viewed 3430 times
It is possible some GLSL 1.50 feature is not available in whatever target version you are setting.
0 x

cord
Halfling
Posts: 59
Joined: Tue Oct 22, 2013 10:22 am

Re: Ogre 1.9, Radeon, Linux

Post by cord » Thu Nov 21, 2013 5:11 am

Here is the output of VolumeCSG, as you suggested on IRC. It's working the same on NVidia and ATI.
volume_csg_original.jpg
Volume CSG
volume_csg_original.jpg (103.96 KiB) Viewed 3426 times
0 x

User avatar
holocronweaver
Google Summer of Code Student
Google Summer of Code Student
Posts: 273
Joined: Mon Oct 29, 2012 8:52 pm
Location: Princeton, NJ

Re: Ogre 1.9, Radeon, Linux

Post by holocronweaver » Thu Nov 21, 2013 5:14 am

And here is my Volume CSG without any further modification beyond above:
volume_csg_first_attempt.jpg
volume_csg_first_attempt.jpg (143.36 KiB) Viewed 3426 times
0 x

User avatar
holocronweaver
Google Summer of Code Student
Google Summer of Code Student
Posts: 273
Joined: Mon Oct 29, 2012 8:52 pm
Location: Princeton, NJ

Re: Ogre 1.9, Radeon, Linux

Post by holocronweaver » Thu Nov 21, 2013 8:47 am

I copied the RTSS GLSL triplanar shader code and...nothing changed. After some experimenting, I realized that even if I only load from the y-axis texture and no other, it still loads from the x-axis texture! So apparently something is wrong with texture loading. So far none of my work has involved this many textures in a pass, hence the reason this problem has evaded me. Will start working on it tomorrow.
0 x

cord
Halfling
Posts: 59
Joined: Tue Oct 22, 2013 10:22 am

Re: Ogre 1.9, Radeon, Linux

Post by cord » Thu Nov 21, 2013 9:48 am

Very educational IRC session, thanks. I pushed a commit to my personal bitbucket to use the RTSS TriplanarTexturing in Sample_VolumeTerrain.

Please take a look: https://bitbucket.org/dmamfmgm/ogre2/co ... f8149df020

I understand you found the normals were not being passed correctly. I guess I still don't understand why, with the RTSS TriplanarTexturing, Ogre needs two shaders that do the same thing? My best guess is that the RTSS version doesn't include specular normal maps--however, the Sample_VolumeTerrain only uses one directional light, so specular maps wouldn't do anything anyway... /confused

I'd like to submit a pull request on Sample_VolumeTerrain:
  1. NVidia cards (may use GLSL or CG, RenderSystem_GL seems to choose GLSL over Cg for some reason)
  2. Radeon cards with RenderSystem_GL - fixed
  3. Radeon cards with RenderSystem_GL3+ - seems fixed here, you should probably verify
From what I understand, you're working on getting Radeon cards to work with RenderSystem_GL3+ but that still leaves the broken material for GL cards?
0 x

User avatar
holocronweaver
Google Summer of Code Student
Google Summer of Code Student
Posts: 273
Joined: Mon Oct 29, 2012 8:52 pm
Location: Princeton, NJ

Re: Ogre 1.9, Radeon, Linux

Post by holocronweaver » Thu Nov 21, 2013 11:01 pm

cord wrote:I pushed a commit to my personal bitbucket to use the RTSS TriplanarTexturing in Sample_VolumeTerrain.
I actually think your original idea of porting the GLSL 1.50 shader to a lower GLSL version is still the way to go. Besides trying to avoid using RTSS in the VolumeTerrain sample for the sake of keeping it simple, we also need to test every pathway, especially the most common one. Most OGRE users do not use RTSS, and since the samples serve as eye candy, tests, and examples, we really need to make sure the standard shaders approach works. You know, to show 'em how it's done. :)
I understand you found the normals were not being passed correctly.
I was mistaken. The problem was that the first texture unit was used for ALL the sampled textures, including the normal maps! I am in the process of investigating why this is. It is a very serious problem to not correctly load textures and I am glad it showed up before GL3+ hits prime time.
I guess I still don't understand why, with the RTSS TriplanarTexturing, Ogre needs two shaders that do the same thing? My best guess is that the RTSS version doesn't include specular normal maps--however, the Sample_VolumeTerrain only uses one directional light, so specular maps wouldn't do anything anyway... /confused
Indeed, the RTSS triplanar texturing does not do normal mapping or specular mapped, though it probably would not be hard to add this to the RTSS system. BTW, specular lighting is really just how 'shiny' parts of an object appear from various viewing angles and can exist even with a single point light or directed light. The VolumeTerrain shaders were designed to handle multiple lights and I would like to preserve this ability.
I'd like to submit a pull request on Sample_VolumeTerrain
Hopefully I have convinced you to proceed with your GL RS port instead of using RTSS. However, since you have already done the work, could you post what your VolumeTerrain looks like using just the RTSS shader? Make sure it is not using the Cg RTSS triplanar texturing - either by compiling OGRE without the Cg plugin checked in CMake or removing it from within the RTSS definition.
From what I understand, you're working on getting Radeon cards to work with RenderSystem_GL3+ but that still leaves the broken material for GL cards?
My first priority is GL3+ RS, but I try to help out with the GL RS whenever I have time. I only test on Radeon because it happens to be what I have. I am in the process of acquiring a Mac and a an NVIDIA card. Only thing missing is Intel.
0 x

binarycrusader
Gnoblar
Posts: 17
Joined: Wed May 19, 2010 5:31 am

Re: Ogre 1.9, Radeon, Linux

Post by binarycrusader » Fri Nov 22, 2013 8:11 am

cord wrote:I'm stumped on a fragment shader issue. Fortunately, I can reproduce the issue on both NVidia and Radeon cards. I'm porting a glsl150 fragment shader to glsl. If you're thinking "just wait until the glsl150 shader is working," sorry, I'm not waiting. I will learn more by doing it.

Background:

I'm attempting to fix bugs in Ogre 1.9, and Sample_VolumeTerrain falls back to no texturing on my Radeon card, at least on Linux. That's because it's a glsl150 shader [1]. No problem, I'm not complaining or anything, but to get it to work on my card, I'm attempting to back-port it to glsl. I'm fairly sure it's because I'm using the GL RenderSystem instead of GL3+. I honestly haven't tried out GL3+ because it appears GL3+ is still in alpha.

Problem:

After fixing the obvious issues, I get this output: (on both an NVidia and a Radeon card)
triplanar_glsl.jpg
It looks like it's sort-of working, but since triplanar texturing isn't that complicated of a concept, the problem is most likely some finicky bit of fragment shader code that a newbie like me won't know anything about. Is there someone with some more experience who could point out what's going on here?


Here are the changes I made to the triplanarReference.program:

Code: Select all

diff -r 05f0ce02f60d Samples/Media/volumeTerrain/triplanarReference.program
--- a/Samples/Media/volumeTerrain/triplanarReference.program	Sun Nov 17 23:17:48 2013 -0600
+++ b/Samples/Media/volumeTerrain/triplanarReference.program	Wed Nov 20 18:31:40 2013 -0700
@@ -128,7 +128,7 @@
 vertex_program TriplanarReferenceHigh_VSGLSL glsl
 {
 	source triplanarReferenceVS.glsl
-	syntax glsl150
+	syntax glsl
 	default_params
 	{
 		// Uncomment for Fog
@@ -142,7 +142,7 @@
 fragment_program TriplanarReferenceHigh_PSGLSL glsl
 {
 	source triplanarReferencePS.glsl
-	syntax glsl150
+	syntax glsl
 	default_params 
 	{
 		
@@ -190,7 +190,7 @@
 vertex_program TriplanarReferenceLow_VSGLSL glsl
 {
 	source triplanarReferenceVS.glsl
-	syntax glsl150
+	syntax glsl
 	default_params
 	{
 		// Uncomment for Fog
@@ -204,7 +204,7 @@
 fragment_program TriplanarReferenceLow_PSGLSL glsl
 {
 	source triplanarReferencePS.glsl
-	syntax glsl150
+	syntax glsl
 	default_params 
 	{
 		param_named_auto lightSpecular0 light_specular_colour 0
diff -r 05f0ce02f60d Samples/Media/volumeTerrain/triplanarReferencePS.glsl
--- a/Samples/Media/volumeTerrain/triplanarReferencePS.glsl	Sun Nov 17 23:17:48 2013 -0600
+++ b/Samples/Media/volumeTerrain/triplanarReferencePS.glsl	Wed Nov 20 18:31:40 2013 -0700
@@ -1,8 +1,6 @@
-#version 150
-
-in vec3 oPos;
-in vec4 oNormAndFogVal;
-in vec3 oEyePos;
+varying vec3 oPos;
+varying vec4 oNormAndFogVal;
+varying vec3 oEyePos;
 
 #if LIGHT0
 uniform vec4 lightPosition0;
@@ -47,11 +45,9 @@
 uniform sampler2D texFromZ;
 uniform sampler2D texFromZNormal;
 
-out vec4 fragColour;
-
 vec3 expand(vec3 v)
 {
-	return (v - 0.5) * 2;
+	return (v - 0.5) * 2.0;
 }
 
 vec4 lit(float NdotL, float NdotH, float m)
@@ -83,7 +79,7 @@
 	float nDotH = dot(halfAngle, normal);
 	vec4 lighting = lit(nDotL, nDotH, exponent);
 	
-	float attenuation = 1;
+	float attenuation = 1.0;
 	#if ATTENUATION
 	if (lightPosition.w != 0) {
 		float distance = length(lightPosition.xyz - oPos);
@@ -91,8 +87,8 @@
 	}
 	#endif
 	
-	float spot = 1;
-	if (!(lightSpotlight.x == 1 && lightSpotlight.y == 0 && lightSpotlight.z == 0 && lightSpotlight.w == 1)) {
+	float spot = 1.0;
+	if (!(lightSpotlight.x == 1.0 && lightSpotlight.y == 0.0 && lightSpotlight.z == 0.0 && lightSpotlight.w == 1.0)) {
 		spot = clamp(
 			(dot(lightDir, normalize(-lightSpotDir)) - lightSpotlight.y) /
 			(lightSpotlight.x - lightSpotlight.y), 0.0, 1.0);
@@ -103,14 +99,13 @@
 
 void main()
 {
-	
 	vec3 unitNormal = normalize(oNormAndFogVal.xyz);
 	vec3 eyeDir = normalize(oEyePos - oPos);
 		
 	// Ported from http://http.developer.nvidia.com/GPUGems3/gpugems3_ch01.html
 	vec3 blendWeights = abs(unitNormal);
 	blendWeights = blendWeights - plateauSize;
-	blendWeights = pow(max(blendWeights, 0), vec3(transitionSpeed));
+	blendWeights = pow(max(blendWeights, 0.0), vec3(transitionSpeed));
 	blendWeights /= vec3(blendWeights.x + blendWeights.y + blendWeights.z );
 	// Move the planar mapping a bit according to the normal length to avoid bad looking skirts.
 	float nLength = length(oNormAndFogVal.xyz - 1.0);
@@ -118,9 +113,9 @@
 	vec2 coord2 = (oPos.zx + nLength) * texScale;
 	vec2 coord3 = (oPos.xy + nLength) * texScale;
 	
-	vec4 col1 = texture(texFromX, coord1);
-	vec4 col2 = texture(texFromY, coord2);
-	vec4 col3 = texture(texFromZ, coord3);
+	vec4 col1 = texture2D(texFromX, coord1);
+	vec4 col2 = texture2D(texFromY, coord2);
+	vec4 col3 = texture2D(texFromZ, coord3);
 	vec4 textColour = vec4(col1.xyz * blendWeights.x +
 		col2.xyz * blendWeights.y +
 		col3.xyz * blendWeights.z, 1);
@@ -132,9 +127,9 @@
 	tangent = normalize(cross(unitNormal, binormal));
 	mat3 TBN = mat3(tangent, binormal, unitNormal);
 	vec3 eyeDir2 = normalize(TBN * eyeDir);
-	vec3 bumpFetch1 = expand(texture(texFromXNormal, coord1).rgb);
-    vec3 bumpFetch2 = expand(texture(texFromYNormal, coord2).rgb);
-    vec3 bumpFetch3 = expand(texture(texFromZNormal, coord3).rgb);
+	vec3 bumpFetch1 = expand(texture2D(texFromXNormal, coord1).rgb);
+    vec3 bumpFetch2 = expand(texture2D(texFromYNormal, coord2).rgb);
+    vec3 bumpFetch3 = expand(texture2D(texFromZNormal, coord3).rgb);
 	vec3 normal2 = bumpFetch1.xyz * blendWeights.x +  
 		bumpFetch2.xyz * blendWeights.y +  
 		bumpFetch3.xyz * blendWeights.z;
@@ -190,9 +185,9 @@
 	lightContribution += doLighting(oPos, normal2, eyeDir2, exponent, specularFactor, lightDir22, lightPosition2, lightDiffuse2, lightSpecular2, lightAttenuation2, lightSpotlight2, lightSpotDir22);
 	#endif
 	
-	fragColour = clamp(textColour * (lightContribution + ambient), 0.0, 1.0);
+	gl_FragColor = clamp(textColour * (lightContribution + ambient), 0.0, 1.0);
 	#if FOGLINEAR || FOGEXPONENTIAL || FOGEXPONENTIAL2
-	fragColour = mix(oColor, fogColour, oNormAndFogVal.w);
+	gl_FragColor = mix(oColor, fogColour, oNormAndFogVal.w);
 	#endif
 	
 }
diff -r 05f0ce02f60d Samples/Media/volumeTerrain/triplanarReferenceVS.glsl
--- a/Samples/Media/volumeTerrain/triplanarReferenceVS.glsl	Sun Nov 17 23:17:48 2013 -0600
+++ b/Samples/Media/volumeTerrain/triplanarReferenceVS.glsl	Wed Nov 20 18:31:40 2013 -0700
@@ -1,7 +1,5 @@
-#version 150
-
-in vec4 position;
-in vec3 normal;
+attribute vec4 position;
+attribute vec3 normal;
 
 uniform vec3 eyePosition;
 uniform mat4 worldviewproj;
@@ -10,9 +8,9 @@
 uniform vec4 fogParams;
 #endif
 
-out vec3 oPos;
-out vec4 oNormAndFogVal;
-out vec3 oEyePos;
+varying vec3 oPos;
+varying vec4 oNormAndFogVal;
+varying vec3 oEyePos;
 
 void main()
 {

[1] see Samples/Media/volumeTerrain/triplanarReference.program, search for "syntax glsl150"

"Supported Shader Profiles" only lists glsl in my log:

Code: Select all

RenderSystem capabilities
-------------------------
RenderSystem Name: OpenGL Rendering Subsystem
GPU Vendor: amd
Device Name: AMD Radeon HD 7900 Series
Driver Version: 4.2.12422.0   
 * Fixed function pipeline: yes
 * Hardware generation of mipmaps: no
 * Texture blending: yes
 * Anisotropic texture filtering: yes
 * Dot product texture operation: yes
 * Cube mapping: yes
 * Hardware stencil buffer: yes
   - Stencil depth: 8
   - Two sided stencil support: yes
   - Wrap stencil values: yes 
---8<---8<--- snip ---8<---8<---
 * Compute programs: no
 * Number of floating-point constants for compute programs: 0
 * Number of integer constants for compute programs: 0
 * Number of boolean constants for compute programs: 0
 * Supported Shader Profiles: arbfp1 arbvp1 glsl gp4gp gpu_gp nvgp4 ps_1_1 ps_1_2 ps_1_3 ps_1_4
For the record, that's almost exactly what the GL3Plus render system looks like for the terrain sample on my NVidia GTX 580 on Windows 8.1 :-)
0 x

cord
Halfling
Posts: 59
Joined: Tue Oct 22, 2013 10:22 am

Re: Ogre 1.9, Radeon, Linux

Post by cord » Fri Nov 22, 2013 2:32 pm

holocronweaver wrote:
cord wrote:I pushed a commit to my personal bitbucket to use the RTSS TriplanarTexturing in Sample_VolumeTerrain.
I actually think your original idea of porting the GLSL 1.50 shader to a lower GLSL version is still the way to go. Besides trying to avoid using RTSS in the VolumeTerrain sample for the sake of keeping it simple, we also need to test every pathway, especially the most common one. Most OGRE users do not use RTSS, and since the samples serve as eye candy, tests, and examples, we really need to make sure the standard shaders approach works. You know, to show 'em how it's done. :)
Oh, now I understand.
holocronweaver wrote:
I understand you found the normals were not being passed correctly.
I was mistaken. The problem was that the first texture unit was used for ALL the sampled textures, including the normal maps! I am in the process of investigating why this is. It is a very serious problem to not correctly load textures and I am glad it showed up before GL3+ hits prime time.
Ok. The same problem exists on the GL RS too.
holocronweaver wrote:
I guess I still don't understand why, with the RTSS TriplanarTexturing, Ogre needs two shaders that do the same thing? My best guess is that the RTSS version doesn't include specular normal maps--however, the Sample_VolumeTerrain only uses one directional light, so specular maps wouldn't do anything anyway... /confused
Indeed, the RTSS triplanar texturing does not do normal mapping or specular mapped, though it probably would not be hard to add this to the RTSS system. BTW, specular lighting is really just how 'shiny' parts of an object appear from various viewing angles and can exist even with a single point light or directed light. The VolumeTerrain shaders were designed to handle multiple lights and I would like to preserve this ability.
That makes sense.
holocronweaver wrote:
I'd like to submit a pull request on Sample_VolumeTerrain
Hopefully I have convinced you to proceed with your GL RS port instead of using RTSS. However, since you have already done the work, could you post what your VolumeTerrain looks like using just the RTSS shader? Make sure it is not using the Cg RTSS triplanar texturing - either by compiling OGRE without the Cg plugin checked in CMake or removing it from within the RTSS definition.
Will do, there appears to be at least one more issue for the GL RS port, but it affects both NVidia and Radeon cards. After the problem with the triplanar part is fixed (all textures coming from just one texture) -- the other problem is the saturation of the lighting which produces the white and black patches.

Here is what I get by switching it to the RTSS shader:
rtss_sample.jpg
RTSS shader results
rtss_sample.jpg (170.75 KiB) Viewed 3362 times
holocronweaver wrote:
From what I understand, you're working on getting Radeon cards to work with RenderSystem_GL3+ but that still leaves the broken material for GL cards?
My first priority is GL3+ RS, but I try to help out with the GL RS whenever I have time. I only test on Radeon because it happens to be what I have. I am in the process of acquiring a Mac and a an NVIDIA card. Only thing missing is Intel.
I typically only test on NVidia when I have to.

It's too bad Macs are so expensive... :) Obviously it's nice to have so you can support the platform. Have you considered building a Hackintosh? I bought one for a neighbor - parts only cost $400 for that one but it didn't include a discrete GPU.
0 x

User avatar
holocronweaver
Google Summer of Code Student
Google Summer of Code Student
Posts: 273
Joined: Mon Oct 29, 2012 8:52 pm
Location: Princeton, NJ

Re: Ogre 1.9, Radeon, Linux

Post by holocronweaver » Sat Nov 23, 2013 6:44 am

cord wrote:Ok. The same problem exists on the GL RS too.
Shocked no one has noticed this before in GL RS. Makes this even more important to fix ASAP.
the other problem is the saturation of the lighting which produces the white and black patches.
Probably will be solved once we make sure all the textures are right.
Here is what I get by switching it to the RTSS shader
Still only one texture from the looks of it.
Have you considered building a Hackintosh?
Yep, that is what I am working to find time to construct. I built a couple over the past few years, but had to disassemble them for parts. I own a legal copy of OS X Lion, but nothing else Mac. :) Even made a Hackintosh laptop once, but the motherboard died and the replacement cost of that alone was more than what I paid for the laptop.
0 x

cord
Halfling
Posts: 59
Joined: Tue Oct 22, 2013 10:22 am

Re: Ogre 1.9, Radeon, Linux

Post by cord » Wed Nov 27, 2013 7:06 pm

I think my backport of triplanarTexturing to GLSL is ready. However, getting the textures bound to the right texture units on Radeon is still a problem. Anyone have any ideas?
0 x

User avatar
holocronweaver
Google Summer of Code Student
Google Summer of Code Student
Posts: 273
Joined: Mon Oct 29, 2012 8:52 pm
Location: Princeton, NJ

Re: Ogre 1.9, Radeon, Linux

Post by holocronweaver » Sun Dec 15, 2013 5:33 am

Just a quick update that I will be looking at this intensively next weekend with the goal of clearing everything up.
0 x

cord
Halfling
Posts: 59
Joined: Tue Oct 22, 2013 10:22 am

Re: Ogre 1.9, Radeon, Linux

Post by cord » Mon Dec 16, 2013 6:03 am

Ok, great! As far as I can tell, here's what's going on:

1. 2 or more textures on Radeon+Linux silently get reduced to just 1 texture. No progress.

2. Port triplanar texturing to GLSL: done, code is in the first post. But #1 is a blocker.

I'm vacationing right now, so my radeon card is temporarily unavailable for testing...
0 x

Post Reply