OpenSceneGraph Forum Forum Index OpenSceneGraph Forum
Official forum which mirrors the existent OSG mailing lists. Messages posted here are forwarded to the mailing list and vice versa.
 
   FAQFAQ    SearchSearch    MemberlistMemberlist    RulesRules    UsergroupsUsergroups    RegisterRegister 
 Mail2Forum SettingsMail2Forum Settings  ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
   AlbumAlbum  OpenSceneGraph IRC ChatOpenSceneGraph IRC Chat   SmartFeedSmartFeed 

obj plugin does not support diffuse and specular texture maps


 
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> Submission
View previous topic :: View next topic  
Author Message
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 11910

PostPosted: Mon Mar 12, 2018 5:17 pm    Post subject:
obj plugin does not support diffuse and specular texture maps
Reply with quote

Hi Ralf,

Sorry for the slow review. Slowly clearing the backlog now that I
have some free time.

I've done a review of the osgUtil::ShaderGen changes and broadly they
are in keeping with the existing ShaderGen but it really jumps out
that ShaderGen really would be much easier to develop and improve it
was re-implemented with #pragma(tic) shader composition. What the
code should have is a single vertex and fragment program that uses
#ifdef's to toggle on/off the various features in the shader, then
have the ShaderGen class just set the #define's via
StateSet::setDefine() etc. This approach would be much cleaner and
easier to maintain, and would also work more seamlessly with the final
shader_pipeline work that I've been experimenting with.

At this point I don't think it makes sense to add more complexity to
ShaderGen as it'll just make it harder to rewrite to use #pragma(tic)
shader composition. The right approach is to convert it to #psc and
then add additional features. I don't know how much work this might
be but I'll do a code review of ShaderGen in OSG master now and see
how easy it would be to adapt it.

If I don't get to this refactor of ShaderGen right away then it would
be helpful if others could pitch in. Once it's refactored then we can
look at again at extending support for more than just very basic fixed
function pipeline like in your proposal.

Cheers,
Robert.



Robert.

On 23 October 2017 at 14:03, Ralf Habacker <> wrote:
Quote:
Am 17.10.2017 um 18:06 schrieb Robert Osfield:
Quote:
With ShaderGen it's there as stop gap to generate some shaders for a
subset of the fixed function pipeline that is common in a subset of the
OSG loaders. It is just a means of getting "something" on the screen on
platforms like GL core profile and GLESL 2+, it's not an all purpose
fully functioning solution.

The appended patch adds build in support of diffuse and specular
textures for obj by extending ShaderGen and the obj plugin. Adding
shaders is disabled by default and needs to be enabled with a plugin
option:

osgviewer -O useBuildInShader plane-with-uv-map.obj

I added the changed files and the related git patches which contains
explanations about how this has been implemented. A test obj file has
also be added. The used images are not added but downloadable from
http://www.rastertek.com/dx10tut21.html because I did not find any
related copyright info.

Quote:
With the shader_pipeline work one would need to have a top level shader
that is able to handle the diffuse and specular texture maps in an
appropriate way. The current top level shader I've worked on so far is
OpenSceneGraph-Data/shaders/shaderpipeline.vert and
shaderpipeline.frag, this is just early days though, but might give you
an idea where this functionality is going and how one might add support
for different texturing and lighting approaches.

Looking at the patch I'm currently not sure if all ShaderGen state mask
combinations are working correctly and the question here is if it would
make more sense to refactor ShaderGen to use define based shaders
instead of adding all the remaining combinations to the recent
implementation.

All the more because there are already 'define' based shaders available
for osg (see https://github.com/OpenMW/openmw/tree/master/files/shaders)

Regards
Ralf













------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 11910

PostPosted: Wed Mar 14, 2018 10:00 am    Post subject:
obj plugin does not support diffuse and specular texture maps
Reply with quote

Hi Ralf,

On 12 March 2018 at 17:13, Robert Osfield <> wrote:
Quote:
At this point I don't think it makes sense to add more complexity to
ShaderGen as it'll just make it harder to rewrite to use #pragma(tic)
shader composition. The right approach is to convert it to #psc and
then add additional features. I don't know how much work this might
be but I'll do a code review of ShaderGen in OSG master now and see
how easy it would be to adapt it.

I have now checked in a rewrite of ShaderGen to use #pragma(tic)
shader composition:

https://github.com/openscenegraph/OpenSceneGraph/commit/4447190dd6cb926341547c001bcaecedffb3bf81

There was functionality in the original implementation that was only
partially implemented so I couldn't see how it could function so I've
removed it. The old code didn't have any proper lighting code so I
need to write this, and the handling of fog isn't implemented
correctly either, I've left this in place but might remove this.

I have checked in shadergen.vert and shadergen.frag to
OpenSceneGraph-Data/shaders:

https://github.com/openscenegraph/OpenSceneGraph-Data/blob/master/shaders/shadergen.vert
https://github.com/openscenegraph/OpenSceneGraph-Data/blob/master/shaders/shadergen.frag

Unfortunately as osgUtil isn't able to use osgDB::readShaderFile()
itself, due the hierarchy of OSG libs, so these shaders are converted
to .cpp's and can be found in src/osgUtil/shaders. These .cpp's are
updated by using osg2cpp --shader
OpenSceneGraph-Data/shaders/shadergen.vert.

It probably would be useful to have a set uber shader setting in
osgUtil::ShaderGen to help workaround the above constraint.

For integration of new features such as support additional
functionality from plugins like obj that aren't natively supported by
fixed function GL I would suggest levering the StateSet::setDefine()
to enable/disable controls, then have the uber shader have this in
them. This way you needn't deeply couple ShaderGen to the various
plugins, instead just the uber shaders and plugins need to be
coordinated.

For the proposed change to ShaderGen/OBJ plugin, I'm now officially
declaring them a dead-end, so if you want this functionality you'll
need to refactor to use the suggested approach above.

Cheers,
Robert.


------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
Ralf Habacker
Guest





PostPosted: Tue Apr 03, 2018 8:33 am    Post subject:
obj plugin does not support diffuse and specular texture maps
Reply with quote

Am 14.03.2018 um 10:55 schrieb Robert Osfield:
Hi Robert,

Quote:
For integration of new features such as support additional
functionality from plugins like obj that aren't natively supported by
fixed function GL I would suggest levering the StateSet::setDefine()
to enable/disable controls, then have the uber shader have this in
them. This way you needn't deeply couple ShaderGen to the various
plugins, instead just the uber shaders and plugins need to be
coordinated.
This looks nice - thanks for your work.

I tried to adapt the shaders from
https://github.com/OpenMW/openmw/tree/master/files/shaders and detected
an issue, which seems to not be supported with the current implementation.

At
https://github.com/OpenMW/openmw/blob/master/files/shaders/objects_vertex.glsl#L67
there is

diffuseMapUV = (gl_TextureMatrix[@diffuseMapUV] *
gl_MultiTexCoord@diffuseMapUV).xy;

which uses a macro @diffuseMapUV for generating index values and is
expanded for example to

diffuseMapUV = (gl_TextureMatrix[0] * gl_MultiTexCoord0).xy;

To be able to use the mentioned shader directly in osg I renamed the
defines named @<name> to _<name>. but got a problem with the following term:

gl_MultiTexCoord@diffuseMapUV

which generates a variable name created from a variable name suffix and
the value from the macro @diffuseMapUV by the preprocessor:

gl_MultiTexCoord <concat> _diffuseMapUV

According to https://gcc.gnu.org/onlinedocs/cpp/Concatenation.html in
regular C I would use

gl_MultiTexCoord ## _diffuseMapUV

or

gl_MultiTexCoord/**/_diffuseMapUV

but at least the nvidia glsl compiler does not understand this and
returns a compile error. An internet search for a solution inside the
glsl compiler gave no results.

Than I took a look at osg shader loading implementation to see if there
would be another way to solve this, because the shader source code is
already parsed by osg (in Shader::PerContextShader::compileShader) and
performs some replacements (In openmw, where the mentioned shaders came
from, the @<name> replacements are also performed in the framework by a
class named ShaderManager).

It looks possible to add some macro replacement from the given state set
to solve this issue, but before I'm going to start writing a related
patch I would like to know if there would be better (or easier) solution ?

Ralf


------------------
Post generated by Mail2Forum
Back to top
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 11910

PostPosted: Tue Apr 03, 2018 8:44 am    Post subject:
obj plugin does not support diffuse and specular texture maps
Reply with quote

Hi Hartwig,

I can't see how you can reuse shaders that are from applications that
do their own shader preprocessing. The @ usage in question isn't
supported by GLSL or the OSG, and given both the OSG and GLSL support
#define's and there usage this is how those OpenMW probably should
have been written, especially given how the OSG's #pragma(tic) shader
composition system provide inserting of variables automatically for
you without an application special preprocessing.

Robert



On 3 April 2018 at 09:28, Ralf Habacker <> wrote:
Quote:
Am 14.03.2018 um 10:55 schrieb Robert Osfield:
Hi Robert,

Quote:
For integration of new features such as support additional
functionality from plugins like obj that aren't natively supported by
fixed function GL I would suggest levering the StateSet::setDefine()
to enable/disable controls, then have the uber shader have this in
them. This way you needn't deeply couple ShaderGen to the various
plugins, instead just the uber shaders and plugins need to be
coordinated.
This looks nice - thanks for your work.

I tried to adapt the shaders from
https://github.com/OpenMW/openmw/tree/master/files/shaders and detected
an issue, which seems to not be supported with the current implementation.

At
https://github.com/OpenMW/openmw/blob/master/files/shaders/objects_vertex.glsl#L67
there is

diffuseMapUV = (gl_TextureMatrix[@diffuseMapUV] *
gl_MultiTexCoord@diffuseMapUV).xy;

which uses a macro @diffuseMapUV for generating index values and is
expanded for example to

diffuseMapUV = (gl_TextureMatrix[0] * gl_MultiTexCoord0).xy;

To be able to use the mentioned shader directly in osg I renamed the
defines named @<name> to _<name>. but got a problem with the following term:

gl_MultiTexCoord@diffuseMapUV

which generates a variable name created from a variable name suffix and
the value from the macro @diffuseMapUV by the preprocessor:

gl_MultiTexCoord <concat> _diffuseMapUV

According to https://gcc.gnu.org/onlinedocs/cpp/Concatenation.html in
regular C I would use

gl_MultiTexCoord ## _diffuseMapUV

or

gl_MultiTexCoord/**/_diffuseMapUV

but at least the nvidia glsl compiler does not understand this and
returns a compile error. An internet search for a solution inside the
glsl compiler gave no results.

Than I took a look at osg shader loading implementation to see if there
would be another way to solve this, because the shader source code is
already parsed by osg (in Shader::PerContextShader::compileShader) and
performs some replacements (In openmw, where the mentioned shaders came
from, the @<name> replacements are also performed in the framework by a
class named ShaderManager).

It looks possible to add some macro replacement from the given state set
to solve this issue, but before I'm going to start writing a related
patch I would like to know if there would be better (or easier) solution ?

Ralf



------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
Ralf Habacker
Guest





PostPosted: Tue Apr 03, 2018 9:02 am    Post subject:
obj plugin does not support diffuse and specular texture maps
Reply with quote

Am 03.04.2018 um 10:39 schrieb Robert Osfield:
Hi Robert,
Quote:

I can't see how you can reuse shaders that are from applications that
do their own shader preprocessing. The @ usage in question isn't
supported by GLSL or the OSG, and given both the OSG and GLSL support
#define's and there usage this is how those OpenMW probably should
have been written, especially given how the OSG's #pragma(tic) shader
composition system provide inserting of variables automatically for
you without an application special preprocessing.

Then let me ask in a different way:
The obj plugin specifies texture in a predefined or custom order, which
need to be propagated to shader code

In recent implementation of shadergen_vert.cpp there is

#if defined(GL_TEXTURE_2D)
gl_TexCoord[0] = gl_MultiTexCoord0;
#endif

which is used later in the related fragment shader as

#if defined(GL_TEXTURE_2D)
color = color * texture2D(diffuseMap, gl_TexCoord[0].st);
#endif

If I specify a different texture unit the vertex shader need to use a
different gl_MultiTexCoord... variable e.g. the macro diffuseMap points
to the related unit this would be

#if defined(GL_TEXTURE_2D)
gl_TexCoord[diffuseMap] = gl_MultiTexCoord <concat> diffuseMap;
#endif

and in the related fragment shader

#if defined(GL_TEXTURE_2D)
color = color * texture2D(diffuseMap, gl_TexCoord[diffuseMap].st);
#endif

How to solve this ?

Ralf


------------------
Post generated by Mail2Forum
Back to top
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 11910

PostPosted: Tue Apr 03, 2018 9:33 am    Post subject:
obj plugin does not support diffuse and specular texture maps
Reply with quote

Hi Hartwig,

I'm afraid I need to concentrate on release work right now so can't
get involved in general discussions.

Robert.

On 3 April 2018 at 09:57, Ralf Habacker <> wrote:
Quote:
Am 03.04.2018 um 10:39 schrieb Robert Osfield:
Hi Robert,
Quote:

I can't see how you can reuse shaders that are from applications that
do their own shader preprocessing. The @ usage in question isn't
supported by GLSL or the OSG, and given both the OSG and GLSL support
#define's and there usage this is how those OpenMW probably should
have been written, especially given how the OSG's #pragma(tic) shader
composition system provide inserting of variables automatically for
you without an application special preprocessing.

Then let me ask in a different way:
The obj plugin specifies texture in a predefined or custom order, which
need to be propagated to shader code

In recent implementation of shadergen_vert.cpp there is

#if defined(GL_TEXTURE_2D)
gl_TexCoord[0] = gl_MultiTexCoord0;
#endif

which is used later in the related fragment shader as

#if defined(GL_TEXTURE_2D)
color = color * texture2D(diffuseMap, gl_TexCoord[0].st);
#endif

If I specify a different texture unit the vertex shader need to use a
different gl_MultiTexCoord... variable e.g. the macro diffuseMap points
to the related unit this would be

#if defined(GL_TEXTURE_2D)
gl_TexCoord[diffuseMap] = gl_MultiTexCoord <concat> diffuseMap;
#endif

and in the related fragment shader

#if defined(GL_TEXTURE_2D)
color = color * texture2D(diffuseMap, gl_TexCoord[diffuseMap].st);
#endif

How to solve this ?

Ralf



------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
Albert Eloyan
Guest





PostPosted: Thu Apr 05, 2018 1:06 pm    Post subject:
obj plugin does not support diffuse and specular texture maps
Reply with quote

Thank you.

On Tue, Apr 3, 2018 at 2:28 AM, Robert Osfield < (
Only registered users can see emails on this board!
Get registred or enter the forums!
)> wrote:
Quote:
Hi Hartwig,

I'm afraid I need to concentrate on release work right now so can't
get involved in general discussions.

Robert.

On 3 April 2018 at 09:57, Ralf Habacker < (
Only registered users can see emails on this board!
Get registred or enter the forums!
)> wrote:
Quote:
Am 03.04.2018 um 10:39 schrieb Robert Osfield:
Hi Robert,
Quote:

I can't see how you can reuse shaders that are from applications that
do their own shader preprocessing.  The @ usage in question isn't
supported by GLSL or the OSG, and given both the OSG and GLSL support
#define's and there usage this is how those OpenMW probably should
have been written, especially given how the OSG's #pragma(tic) shader
composition system provide inserting of variables automatically for
you without an application special preprocessing.

Then let me ask in a different way:
The obj plugin specifies texture in a predefined or custom order, which
need to be propagated to shader code

In recent implementation of shadergen_vert.cpp there is

#if defined(GL_TEXTURE_2D)
    gl_TexCoord[0] = gl_MultiTexCoord0;
#endif

which is used later in the related fragment shader as

#if defined(GL_TEXTURE_2D)
    color = color * texture2D(diffuseMap, gl_TexCoord[0].st);
#endif

If I specify a different texture unit the vertex shader need to use a
different gl_MultiTexCoord... variable e.g. the macro diffuseMap points
to the related unit this would be

#if defined(GL_TEXTURE_2D)
    gl_TexCoord[diffuseMap] = gl_MultiTexCoord <concat> diffuseMap;
#endif

and in the related fragment shader

#if defined(GL_TEXTURE_2D)
    color = color * texture2D(diffuseMap, gl_TexCoord[diffuseMap].st);
#endif

How to solve this ?

Ralf
_______________________________________________
osg-submissions mailing list
(
Only registered users can see emails on this board!
Get registred or enter the forums!
)
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
_______________________________________________
osg-submissions mailing list
(
Only registered users can see emails on this board!
Get registred or enter the forums!
)
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org


------------------
Post generated by Mail2Forum
Back to top
Display posts from previous:   
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> Submission All times are GMT
Page 1 of 1

 
Jump to:  
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 vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum

Similar Topics
Topic Author Forum Replies Posted
No new posts Support for paletted images in dds pl... psi29a Plugins [osgPlugins] 1 Fri Jun 22, 2018 10:14 am View latest post
No new posts ANGLE/UWP support checked into OSG gi... robertosfield General 5 Fri Jun 01, 2018 2:08 pm View latest post
No new posts No specular maps, exporting from blen... Klemen Červ Plugins [osgPlugins] 1 Wed May 16, 2018 1:08 pm View latest post
No new posts Support for loading cubemap images in... Farshid Lashkari Submission 7 Wed May 09, 2018 5:56 pm View latest post
No new posts DXT texture compression urbanchaos General [forum] 14 Tue May 08, 2018 12:13 pm View latest post


Board Security Anti Bot Question MOD - phpBB MOD against Spam Bots
Powered by phpBB © 2001, 2005 phpBB Group
Protected by Anti-Spam ACP