Horde3D

Next-Generation Graphics Engine
It is currently 24.11.2024, 15:40

All times are UTC + 1 hour




Post new topic Reply to topic  [ 74 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next
Author Message
 Post subject: Success!!!
PostPosted: 30.12.2007, 16:04 
Offline

Joined: 22.11.2007, 17:05
Posts: 707
Location: Boston, MA
I finally got it! I replaced the calcPhongSpotLight() function in "Content/shaders/utilityLib/fragLighting.glsl" with a function that returns a constant term, and the whole system executes nicely! Except of course that the lighting is not correct ;)

I assume therefore that the phong lighting equation there is overrunning my cards capabilities/finding an obscure bug. I am not a shader wizard, so I wonder if someone else could have a bash at working up a simplified version of the shader that I could test...

For reference, here is the function it dies with:
Code:
vec3 calcPhongSpotLight( const vec3 pos, const vec3 normal, const vec3 albedo, const float specMask, const float viewDist )
{
   vec3 light = lightPos.xyz - pos;
   
   // Distance attenuation
   float lightDist = length( light ) / lightPos.w;
   float att = max( 1.0 - lightDist * lightDist, 0.0 );
   light = normalize( light );
   
   // Spotlight falloff
   float angle = dot( lightDir, -light );
   att *= clamp( (angle - lightCosCutoff) / 0.2, 0.0, 1.0 );
      
   // Half lambert lighting
   float NdotL = dot( normal, light );
   float diffuse = NdotL * 0.5 + 0.5;
   diffuse = diffuse * diffuse;
   
   // Final color
   vec3 col = albedo * lightColor * (diffuse + 0.3) * att;    // Diffuse & ambient color
   
   // Shadow
   if( NdotL > 0.0 && att > 0.0 )
   {   
      mat4 lightMat;
      if( viewDist < shadowSplitDists.x ) lightMat = shadowMats[0];
      else if( viewDist < shadowSplitDists.y ) lightMat = shadowMats[1];
      else if( viewDist < shadowSplitDists.z ) lightMat = shadowMats[2];
      else lightMat = shadowMats[3];
      
      vec4 projShadow = lightMat * vec4( pos, 1.0 );
      projShadow.z = lightDist;
      projShadow.xy /= projShadow.w;
      
      float shadowFac = PCF( projShadow );
      col *= max( 0.5, shadowFac );
      
      // Specular
      vec3 eye = normalize( viewer - pos );
      vec3 refl = reflect( -light, normal );
      float spec = pow( clamp( dot( refl, eye ), 0.0, 1.0 ), 8.0 ) * specMask;
      col += vec3( 0.3, 0.3, 0.4 ) * spec * att * shadowFac;
   }
   
   return col;
}

And here is my replacement which ends the crashing...
Code:
vec3 calcPhongSpotLight( const vec3 pos, const vec3 normal, const vec3 albedo, const float specMask, const float viewDist )
{
   return vec3(0.5);
}


However, this does confirm it is a problem with my specific card/driver and the shader, rather than the engine code itself, so I am going to go ahead an package up a binary SDK for Mac. Would you like me to place it elsewhere, or could it be hosted here? For the record, I am willing to be the maintainer for the Mac port, especially since I am gearing up a project using Horde for the renderer.

Edit: Here is the binary distribution: deprecated - see newer version below.

I would be obliged if any other Mac users could give it a spin and see if it works...


Last edited by swiftcoder on 17.01.2008, 14:57, edited 4 times in total.

Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: 31.12.2007, 16:09 
Offline

Joined: 22.11.2007, 17:05
Posts: 707
Location: Boston, MA
Hmm, looks like we are exceeding the dynamic branching limit for my driver/card. In the above function (calcPhongSpotLight), replacing these lines:
Code:
      if( viewDist < shadowSplitDists.x ) lightMat = shadowMats[0];
      else if( viewDist < shadowSplitDists.y ) lightMat = shadowMats[1];
      else if( viewDist < shadowSplitDists.z ) lightMat = shadowMats[2];
      else lightMat = shadowMats[3];

with this line:
Code:
      lightMat = shadowMats[0];

Fixes the problem entirely, although of course it disables the PSSM, and renders only nearby shadows.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: 01.01.2008, 18:50 
Offline
Engine Developer

Joined: 10.09.2006, 15:52
Posts: 1217
Thanks for tracking down the problem! Actually the current solution for selecting the PSSM matrices is rather a hack and not optimal since it requires branches and copying of the matrix in the pixel shader. My first idea was to use an index and to make a lookup in the shadowMats array but that doesn't work in GLSL. I will have to look if there is a better solution but I'm not quite sure.

Great to hear that you want to maintain the Mac port. Since more and more people are making contributions :) I'm currently thinking of ways how we can make Horde development more community centric and collaborative. Moving the project to sourceforge would probably be an option. Until we have a good system I think it would be the best if you could host the port yourself.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: 01.01.2008, 20:54 
Offline

Joined: 22.11.2007, 17:05
Posts: 707
Location: Boston, MA
marciano wrote:
Thanks for tracking down the problem! Actually the current solution for selecting the PSSM matrices is rather a hack and not optimal since it requires branches and copying of the matrix in the pixel shader. My first idea was to use an index and to make a lookup in the shadowMats array but that doesn't work in GLSL. I will have to look if there is a better solution but I'm not quite sure.

I don't think I have ever seen a different way to do it, but I am sure some improvements can be made.

Quote:
Great to hear that you want to maintain the Mac port. Since more and more people are making contributions :) I'm currently thinking of ways how we can make Horde development more community centric and collaborative. Moving the project to sourceforge would probably be an option. Until we have a good system I think it would be the best if you could host the port yourself.

OK, I am going to put together a ReadMe for the Mac SDK, and package it up with the source code and license, etc. I will continue hosting on MediaFire, and I will send you a link to post here when I have it working.

I think to find enough testers, and get a little coverage for the port it might be good to announce it on GameDev as well once I have it packaged - perhaps as a second "image of the day" ;)


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: 02.01.2008, 02:18 
Offline
Engine Developer

Joined: 10.09.2006, 15:52
Posts: 1217
swiftcoder wrote:
I think to find enough testers, and get a little coverage for the port it might be good to announce it on GameDev as well once I have it packaged - perhaps as a second "image of the day" ;)

That's a good idea! :)


Top
 Profile  
Reply with quote  
PostPosted: 02.01.2008, 21:03 
Offline

Joined: 22.11.2007, 17:05
Posts: 707
Location: Boston, MA
Here is the 'official' release of the 0.13.0 SDK for Mac. It is compatible with both Intel and PowerPC Macs, running 10.4 or newer. This is a binary SDK, but also contains source code for the samples.

Deprecated in favour of later release below

A Mac-specific ReadMe is included, with installation instructions and basic troubleshooting information. Desperately in need of testing and bug reports, so please give it a spin and let me know what works and what doesn't.

I will be submitting an 'Image of the Day' to GameDev.net shortly, and i will place a link here after it shows up.


Last edited by swiftcoder on 31.01.2008, 06:11, edited 1 time in total.

Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: 16.01.2008, 18:18 
Offline

Joined: 23.11.2007, 10:37
Posts: 2
You are still using a lot of absolute paths in your xcode projects, for instance /Users/tristam/Library/Frameworks/...

Can I recommend you create another user account on your MAC and test your release against that, slowly working through to get it working with relative paths, except where truly necessary. :wink:

P.S. I had a go at using the original xcode projects with a MacBook; but came across issues which I suspect are to do with SDLs use of OpenGL. I think SDL must be specifying a specific OpenGL device, as the examples fail with "no support for ARB_texture_float" which _is_ supported by the fallback software based openGL driver provided by apple (but not the intel GMA OpenGL driver). Haven't had time to get to the bottom of that one. Perhaps a Cocoa derived SDK instead of using SDL may make things better?


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: 16.01.2008, 18:56 
Offline

Joined: 22.11.2007, 17:05
Posts: 707
Location: Boston, MA
RichBecks wrote:
You are still using a lot of absolute paths in your xcode projects, for instance /Users/tristam/Library/Frameworks/...

Can I recommend you create another user account on your MAC and test your release against that, slowly working through to get it working with relative paths, except where truly necessary. :wink:


Huh? There aren't any frameworks in the Binary SDK — the whole point is to make it newbie friendly and dummy proof (which shipping XCode projects isn't :wink: ).

RichBecks wrote:
P.S. I had a go at using the original xcode projects with a MacBook; but came across issues which I suspect are to do with SDLs use of OpenGL. I think SDL must be specifying a specific OpenGL device, as the examples fail with "no support for ARB_texture_float" which _is_ supported by the fallback software based openGL driver provided by apple (but not the intel GMA OpenGL driver). Haven't had time to get to the bottom of that one. Perhaps a Cocoa derived SDK instead of using SDL may make things better?


I plan to add a Cocoa integration sample at some point, so that will support the software renderer at any rate. However, I don't want to replace SDL in the default samples, to maintain portability. It might be worth a bug report/feature request to the SDL guys, to ask for a SDL_GL_SOFTWARE_DRIVER flag on context creation...


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: 17.01.2008, 09:41 
Offline

Joined: 23.11.2007, 10:37
Posts: 2
Quote:
Huh? There aren't any frameworks in the Binary SDK — the whole point is to make it newbie friendly and dummy proof (which shipping XCode projects isn't ).


This is why I suggested installing your "SDK" as a separate user and trying it out. The binaries fail with

Library not loaded: /Users/tristam/Library/Frameworks/Horde3D.framework/A/Horde3D

Referenced from : /Users/rjones/Downloads/Horde3D 0.13.0 Mac UB SDK/Binaries/Knight.app/Contents/MacOS/Knight

Reason: image not found

Looks like an absolute path issue to me (or at least missing files originally referenced with an absolute path).


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: 17.01.2008, 13:26 
Offline

Joined: 22.11.2007, 17:05
Posts: 707
Location: Boston, MA
RichBecks wrote:
Quote:
Huh? There aren't any frameworks in the Binary SDK — the whole point is to make it newbie friendly and dummy proof (which shipping XCode projects isn't ).


This is why I suggested installing your "SDK" as a separate user and trying it out. The binaries fail with

Library not loaded: /Users/tristam/Library/Frameworks/Horde3D.framework/A/Horde3D

Referenced from : /Users/rjones/Downloads/Horde3D 0.13.0 Mac UB SDK/Binaries/Knight.app/Contents/MacOS/Knight

Reason: image not found

Looks like an absolute path issue to me (or at least missing files originally referenced with an absolute path).


I just tried that, and they work perfectly - but make sure you copied the framework into "/Library/Frameworks/" or "~/Library/Frameworks/" as per the read me. The error message if you don't copy does have the wrong path, but that doesn't affect it running.

If the darn framework wasn't so big, I would embed a copy of the framework in the samples, to make them truly dummy proof - but that would increase the size of the download by 4MB.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: 31.01.2008, 06:10 
Offline

Joined: 22.11.2007, 17:05
Posts: 707
Location: Boston, MA
I am pleased to announce that the Mac OS X Binary SDK for Horde3D 0.14.0 is now available. Apologies for the delay, but some patches to glfw were necessary.

Horde3D 0.14.0 Mac UB SDK.zip (3.4 MB)

The package includes the Horde framework, binaries of the Chicago and Knight samples, a binary of the ColladaConv tool, source for the 2 samples, and a patched binary distro of glfw.

Please follow the installation instructions in the 'Read Me First - Mac OS X.rtf' file carefully, as the framework must be manually installed before the samples will run.

As always, I would welcome any bug reports, as well as frames-per-second values and hardware specs, as I am trying to track down a performance issue.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: 31.01.2008, 11:03 
Offline
Engine Developer

Joined: 10.09.2006, 15:52
Posts: 1217
Great! I would realy like to try it out but without a Mac that's difficult ;)

If you want I can post a link on the download site. By the way the sourceforge project is already registered so Horde could relocate soon.

Will you contribute the fixes you made to GLFW back to them?


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: 31.01.2008, 13:05 
Offline

Joined: 22.11.2007, 17:05
Posts: 707
Location: Boston, MA
marciano wrote:
If you want I can post a link on the download site. By the way the sourceforge project is already registered so Horde could relocate soon.

Excellent on both counts!

marciano wrote:
Will you contribute the fixes you made to GLFW back to them?
Ja, if I can raise any activity on the glfw mailing lists. It isn't the most active of projects, but on the other hand it is fairly stable. I also want to avoid becoming the maintainer for that as well ;)


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: 05.02.2008, 15:30 
Offline
Engine Developer

Joined: 10.09.2006, 15:52
Posts: 1217
I just installed the latest Catalyst 8.1 drivers for the X1600 in our lab. Now I have the same problems that swiftcoder describes, a crash in the Chicago sample when PSSM are used. Luckily I found a simple workaround in the shader which doesn't disable PSSM.

But the other huge problem is that the performance of the new drivers (ATI has completely rewritten them recently) is really poor, less than half of what I had using the 7.10 drivers.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: 05.02.2008, 15:34 
Offline

Joined: 22.11.2007, 17:05
Posts: 707
Location: Boston, MA
marciano wrote:
I just installed the latest Catalyst 8.1 drivers for the X1600 in our lab. Now I have the same problems that swiftcoder describes, a crash in the Chicago sample when PSSM are used. Luckily I found a simple workaround in the shader which doesn't disable PSSM.

What was the workaround? I am interested in trying that over here.

marciano wrote:
But the other huge problem is that the performance of the new drivers (ATI has completely rewritten them recently) is really poor, less than half of what I had using the 7.10 drivers.

Ja, I heard this on gamedev a couple of days ago. It looks like ATI shipped the new drivers on the Mac side first, and now the PC side is getting them as well. I guess we wait and hope they fix them...


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 74 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next

All times are UTC + 1 hour


Who is online

Users browsing this forum: No registered users and 7 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group