I see. Well, this is merely an exercise for me to get up to speed on OpenGL shaders as my next task is to convert our existing shaders from RTS 2 and RTS 3 to RTS 4, and convert from using .spdl to shader definitions. Our shaders do not use any GLSL, they use UI assisted hardware mapping via PPGs just like mental ray shaders. Sooooo, how can I get the same information without resorting to GLSL?
I think we avoided GLSL for performance reasons as our one main shader (NCDeferred) has roughly 400 parameters (if you remember the shader PPGLayout example from a previous bug report). Coding that in GLSL would be a very painful experience. Another wrinkle is I am being asked to add lighting calculations to the shaders which support our custom lights. Since Softimage does not support realtime shaders for lights, I must put the calculations into the realtime material shaders. This includes reading self installing custom property parameter values applied to the lights to define behaviors which are specific/unique to our game engine. How can I access that information from a realtime shader efficiently? Do I just use the C++ API or do I have to do that through the realtime shading APIs? Matt From: [email protected] [mailto:[email protected]] On Behalf Of John Voltaire Tensuan Sent: Wednesday, February 06, 2013 10:34 PM To: [email protected] Subject: RE: SDK: OGLLight Hi Matt, Working with vertex/fragment shaders is usually only goes one-way meaning you can upload the parameters to the shader but the shader itself usually cannot send its results back to the calling code (I believe there are extensions to do this but I'm not sure about the driver support for these and I also don't have much experience with them). If what you want is the world coordinates inside the fragment shader, what you can do is: 1. Create a new uniform variable in your vertex program so that your C++ code can feed the vertex program the current world matrix (e.g. uniform mat4 world_matrix) 2. Create a new varying variable for the world position in your vertex and fragment programs so that the vertex program can give the fragment program the world position it has calculated (e.g. varying vec4 world_pos) 3. Feed the world_matrix uniform the proper matrix in your C++ code via the glGetUniformLocation*/glUniform* functions (I think the code I sent you already does this inside SetTransforms()) 4. Set the world_pos varying variable inside your vertex program so that it can be properly read inside the fragment program So in your vertex program you'll have: varying vec4 world_pos; uniform mat4 world_matrix; ... void main() { ... world_pos = world_matrix * gl_Vertex; ... } And in the fragment program you can read what worldPos is just by declaring the same varying variable and using it like an ordinary variable inside the code: uniform vec4 light_pos; // Some other uniform that you might want to add varying vec4 world_pos; ... void main() { ... float fDist = distance(world_pos.xyz, light_pos.xyz); // Do something with world_pos ... } Regards, John From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Matt Lind Sent: Thursday, February 07, 2013 11:00 AM To: [email protected]<mailto:[email protected]> Subject: RE: SDK: OGLLight I'm used to writing mental ray shaders. Mental ray uses different coordinate spaces for every scene item which means shader code contains many conversion routines to do simple stuff like diffuse shading. I'm still getting my feet wet with OpenGL shaders using the Phong shader you sent me a while back. As a learning exercise I'm attempting to extend it to support point and spot lights. I initially experienced funky lighting when the point light was inserted into a hierarchy and moved around the scene, but then I caught my mistake and removed the computations that consider light orientation. One sticking point I have right now is how to get the world coordinate of the current shaded pixel. I see it defined in the vertex shader source (GLSL), but how do I read that into the C++ code so I can work with it further? All the calls I see in the C++ code push values from C++ into the vertex/fragment shaders. I need to go the other direction. Thanks, Matt From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of John Voltaire Tensuan Sent: Wednesday, February 06, 2013 6:46 PM To: [email protected]<mailto:[email protected]> Subject: RE: SDK: OGLLight Hi Matt, Coordinates returned by OGLLight should all be in global space. Are you seeing any weird behavior with it? Thanks, John From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Alok Sent: Thursday, February 07, 2013 7:37 AM To: [email protected]<mailto:[email protected]> Subject: Re: SDK: OGLLight Should be global, but again not sure [cid:[email protected]] On 06/02/2013 6:34 PM, Matt Lind wrote: Let me rephrase - what coordinate space is returned: local? Global? Screen? Normal? Camera? Thanks, Matt From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Alok Sent: Wednesday, February 06, 2013 3:23 PM To: [email protected]<mailto:[email protected]> Subject: Re: SDK: OGLLight Not sure, but as far as I can remember, it uses homogenous coordinates so point (x, y, z) is represented as (xw, yw, zw, w). If you are getting a return of four scalars and want to convert to 3d cartesian , simply divide the first three values by the fourth value. Maybe I am wrong, but not completely. [cid:[email protected]] On 06/02/2013 5:58 PM, Matt Lind wrote: Anybody know what coordinate space is used for the values returned by the OGLLight? (e.g. OGLLight.GetLightPosition(), OGLLight.GetLightDirection(), ...) The documentation doesn't specify. Matt No virus found in this message. Checked by AVG - www.avg.com<http://www.avg.com> Version: 2012.0.2238 / Virus Database: 2639/5585 - Release Date: 02/06/13 No virus found in this message. Checked by AVG - www.avg.com<http://www.avg.com> Version: 2012.0.2238 / Virus Database: 2639/5585 - Release Date: 02/06/13
<<inline: image001.gif>>
