Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Preventing redeclaration of variables when using ShaderChunks #9035

Closed
WestLangley opened this issue May 30, 2016 · 6 comments
Closed

Preventing redeclaration of variables when using ShaderChunks #9035

WestLangley opened this issue May 30, 2016 · 6 comments

Comments

@WestLangley
Copy link
Collaborator

clipping_planes_pars_vertex.glsl uses this coding pattern

#if NUM_CLIPPING_PLANES > 0 && ! defined( PHYSICAL ) && ! defined( PHONG )

    varying vec3 vViewPosition;

#endif

In other words, declare viewViewPosition -- but not if it has been predeclared.

These material-dependent chunks become problematic when creating new materials, because it can lead to variable redeclaration conflicts if it is not known if the variable has been previously declared. For example:

#if SOME_CONDITION

    varying vec3 vViewPosition;

#endif

...

//from clipping_planes_pars_vertex
#if NUM_CLIPPING_PLANES > 0 && ! defined( PHYSICAL ) && ! defined( PHONG )

    varying vec3 vViewPosition;

#endif

As the number of materials increases, figuring out how to modify the chunks to avoid a potential redeclaration is too tedious.

Would the following coding pattern be acceptable? To be used only when needed.

varying vec3 vViewPosition;
#define VVIEWPOSITION

...

//rewrite of clipping_planes_pars_vertex
#if NUM_CLIPPING_PLANES > 0 && ! defined( VVIEWPOSITION ) 

    varying vec3 vViewPosition;

#endif

Or, is there a better solution to decouple the material types from the Chunks?

@bhouston
Copy link
Contributor

bhouston commented Jun 2, 2016

The way we have been doing it until now is to list all of the conditions that require that variable at the point of its declaration. If we were to follow that pattern here, it would result in simpler code.

@mrdoob
Copy link
Owner

mrdoob commented Jun 2, 2016

Sounds good to me, yeah.

@bhouston
Copy link
Contributor

@WestLangley, could you just add something like a

#require varying vec3 vViewPosition

And once would parse the shader looking for the above structure replace these with your defines automatically. I guess I want to keep the glsl simple, even if it means adding some additional preprocessor commands.

@WestLangley
Copy link
Collaborator Author

@bhouston I am open to that. But if you want to go that route, someone other than myself should implement it -- at least at first.

@mrdoob
Copy link
Owner

mrdoob commented Dec 15, 2016

I think we can do this on two steps. @WestLangley suggestion sounds like a (much needed) clean up.

@bhouston
Copy link
Contributor

bhouston commented Dec 15, 2016

No worries, I was just brainstorming. To be more specific, I was just thinking of doing a search and replace of patterns like this:

#require varying vec3 vViewPosition

// or here is another form:
#defineonce( varying vec3 vViewPosition )

With something like this:

#ifndef defineonce_varying_vec3_vViewPosition
   varying vec3 vViewPosition
   #define defineonce_varying_vec3_vViewPosition
#endif

Then the code example you gave about would look like:

#defineonce( varying vec3 vViewPosition; )

...
//rewrite of clipping_planes_pars_vertex
#if NUM_CLIPPING_PLANES > 0

    #defineonce( varying vec3 vViewPosition; )

#endif

Which would be transformed into this:

#ifndef defineonce_varying_vec3_vViewPosition
   varying vec3 vViewPosition;
   #define defineonce_varying_vec3_vViewPosition
#endif
...
//rewrite of clipping_planes_pars_vertex
#if NUM_CLIPPING_PLANES > 0

   #ifndef defineonce_varying_vec3_vViewPosition
      varying vec3 vViewPosition;
      #define defineonce_varying_vec3_vViewPosition
   #endif

#endif

EDIT: It may make more sense to use a hash (MD5 or shorter) of the "defineonce" contents rather than trying to turn it into a valid preprocessor variable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants