Hello Carsten,
>> Johannes Brunen wrote:
> Carsten Neumann wrote:
>
> you can register higher priority loaders at any time, but there is not a
> good way to go back and forth between them. Is that needed?
>
Yes, I think that this is useful. Imagine that you have to support two
different file types for the very same suffix.
Maybe we should allow the customization of the priority at runtime at least.
>> Probably the 'A' comes from 'Autodesk'. I did not want to change the
>> 'naming
>> policy'. Therefore I stuck to it. Should I change it?
>
> as I said, not terribly important.
>
Ok, then I will not change the name :)
> for the time being you'll have to use gl_MultiTexCoordN to access vertex
> attributes.
> Here is a vertex shader I use to perform vertex skinning animation on
> the GPU. A vertex has a position, a normal, four joint indices (stored
> in gl_MultiTexCoord2), and four joint weights (stored in
> gl_MultiTexCoord3).
>
> // forward decl
> void calcSkin(inout vec4 pos, inout vec3 norm,\n"
> in vec4 matIdx, in vec4 weight);\n"
>
> varying vec4 position;
> varying vec3 normal;
>
> void main(void)
> {\n"
> vec4 pos = gl_Vertex;
> vec3 norm = gl_Normal;
> vec4 matIdx = gl_MultiTexCoord2;
> vec4 weight = gl_MultiTexCoord3;
>
> calcSkin(pos, norm, matIdx, weight);
>
> gl_Position = gl_ModelViewProjectionMatrix * pos;
> position = gl_Position;
> normal = gl_NormalMatrix * norm;
> }
>
> On the OpenSG side there are four GeoProperties on the Geometry:
>
> geo->setProperty(pos, Geometry::PositionsIndex);
> geo->setProperty(normals, Geometry::NormalsIndex);
> geo->setProperty(jointIdx, Geometry::TexCoords2Index);
> geo->setProperty(jointWeight, Geometry::TexCoords3Index);
>
> I'm not sure if this is enough to explain it, please ask if you need
> more details.
>
Thank you for your explanation. I think I have understood. I will play a
little with this in order to get some familiarity. Time to read some shader
programming book...
>> I thought that I would have full GL state infromation inside of a shader
>> program.
>
> no, you can access all the lights properties (position, color, etc.)
> through the gl_LightSource[i] built in uniform, but the piece of
> information that is crucially missing is if the light is actually
> enabled (i.e. if glEnable(GL_LIGHTi) was called).
>
Unbelievable. Then this information must be provided by addional uniforms.
Correct?
>
> determining the type of light source requires examining the light's
> properties (e.g. if gl_LightSource[i].position[3] == 0 it is a
> directional light), it can be done, but slows the thing down, especially
> since it needs to be done in the fragment shader.
>
Understood.
>>> How do you fight the combinatorial explosion of all the combinations of
>>> different textures that can be present/absent?
>>
>> I do not understand that correctly. If you look at the code you will see
>> the
>> general scheme I had in mind. Might be not the right way to solve the
>> problem, so.
>
> hm, your bump map shader does not evaluate TEXTURE1_MAP or TEXTURE2_MAP
> to determine basecolor, it just uses a fixed value. Just for the three
> textures (TEXTURE1_MAP, TEXTURE2_MAP, BUMP_MAP) you need shaders for:
>
> no texture (maybe not needed)
> only tex1
> only tex2 (maybe not needed)
> tex1, tex2
> tex1, bump
> tex2, bump (maybe not needed)
> tex1, tex2, bump
>
> so even optimistically there are 4 combinations to deal with and that is
> only for three input textures, that's what I meant with combinatorial
> explosion.
Understood.
I will rethink the matter of the shaders and textures. As already stated,
this is new ground for me...
Best,
Johannes
------------------------------------------------------------------------------
_______________________________________________
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users
