heavenwu / glsl-unit Goto Github PK

Adding ShaderProgram::getUncompiledVertexSource/getUncompiledFragmentSource 
would be useful for allowing code to switch between compiled/uncompiled mode 
either at runtime or compile-time.

What steps will reproduce the problem?
1. Write a shader with a small floating point difference from the expected 
value 
2. run it

What is the expected output? 

An error that shows the expected and actual values in enough precision to have 
an inkling what's wrong.


What do you see instead?
      Expectation 2 Failed: Expected texCoord.x == 0 with allowable error of 0.001, was 0.


The error printer just needs to print out more digits of precision on floating 
point numbers.

--glsl_include_prefix does what the name says, however, this behavior 
(concatenating paths) is undesirable in most cases.

Much more useful would be --glsl_include_path, which allows for a cwd-relative 
path.
This way it's possible to write tools/scripts that work correctly by using 
proper relative paths.

e.g. invoking the compiler from /foo to compile some files under /foo/bar/ with 
shared files in /foo/ would require sending --glsl_include_prefix=../ - if 
files were then under /foo/bar/wut/ it would require 
--glsl_include_prefix=../../
With --glsl_include_path one could make both calls with the same argument: 
--glsl_include_path=.

When writing tools with more complex directory structures doing the path 
manipulation before calling is nasty (and complex in bash scripts)

Would be useful to be able to specify arbitrary parameters on the command line 
to the template_compiler that get stuffed on ShaderProgram and can be used in 
templates.

For example:
template_compiler.js ... --template_property=key1=value1 
--template_property=key2=value2
...
... {{key1}} + {{key2}} ...

Simple and not super complex, but would prevent me from having to postprocess 
compiler output in simple cases where I would like to do something like embed a 
path inside the result that cannot (or should not) be placed in the input glsl.

Linking programs is expensive, so in cases where one vertex shader is shared 
with many fragment shaders (or vs.) it would be nice to enable sharing.

I'm not sure of the best design for this from the compiler - maybe take 
multiple GLSL files on the command line and ensure consistent naming on 
attributes/uniforms/etc used by the vertex shader (then the vs for each 
resulting output would be identical, allowing it to be reused once compiled).

the replace used only replaces the first newline, not all of them, meaning the 
value cannot be embedded in a string in js -- probably need a regex replace, 
like .replace(/\n/g, '\\n') (I think)

Running template_glsl_compiler:

Settinginput to file.glsl
Settingtemplate to file.mustache
       ^ no spaces!

It would be nice to be able to list all of the glsllib files included for a 
given input. Build systems can use this to then do dependency 
tracking/caching/etc. The compiler can hopefully get this information rather 
easily, where as doing it externally would require parsing all of the files. As 
the compiler inputs get more complex (with preprocessor logic/etc) it gets more 
difficult to do this from the outside.

e.g.,
glsl-compiler --input=foo.glsl --list-dependencies
foo.glsl
somelib.glsllib
some/path/lib.glslib
...

If dumped on stdout it'd be possible to grab this and pipe it to another file 
or programmatically act on it.

In complex projects (especially ones including other libraries) one can end up 
with multiple paths containing glsllib files. It'd be useful to be able to pass 
comma/semicolon/whatever separated lists to glsl_include_prefix, or multiple 
glsl_include_prefix values to specify them.

e.g.
--glsl_include_prefix=lib1/includes/ --glsl_include_prefix=lib2/includes/ 
--input=file.glsl

Fragment shaders have no default float precision, and as such a precision 
statement must occur before any statements using floats (such as 
varying/uniform declarations).

If you have a glsl file like:
//! COMMON
uniform float x;
//! VERTEX
...
//! FRAGMENT
precision mediump float;
...

This will result in an output fragment shader of:
uniform float x; precision mediump float; ....
At runtime this will result in a 'no precision specified for (float)'.

The only workaround I've found is to put the precision statement at the top of 
my //! COMMON, however I'd like to be able to vary the precision across shaders 
and even across VS/FS.

It's tricky to just hoist precision statements, as there can be multiple and 
they are scoped. Perhaps a //! DEFAULT_PRECISION highp or something? You could 
then have this in glsllib to share (and it will always get placed as the first 
statement), or override it in .glsl files selectively.

Would be nice to have a script or some documentation on how to build 
template_glsl_compiler and co - right now when bugs are found they are 
difficult to update.

Guidance on how best to run uncompiled, if possible, would be cool too - that 
way testing changes would be easier.

What steps will reproduce the problem?
1. Minimise a shader.
2. Observe that the minimised shader declares multiple variables on a single 
line:
  attribute vec2 a, b;
3. IE11 can't compile such statements.

More information here: 
https://groups.google.com/d/msg/webgl-dev-list/LopzjRB7w5Y/xGdbJeu75jgJ

What is the expected output? What do you see instead?
There needs to be a way to rewrite such statements with one declaration per 
line (or, Microsoft need to fix their GLSL parser).

What version of the product are you using? On what operating system?
The latest master of glsl-unit (f80be0a52e07429b0a0fe8b8368895f5e0159294).


Please provide any additional information below.

In many situations when outputting the lists of attributes/uniforms it's handy 
to know when at the end of the list. Unfortunately mustache does not provide 
this functionality.
This means that outputting the map of attributes/uniforms into JSON (which 
cannot have trailing commas) is not possible without dummy values, nor is good 
string construction.

See: 
http://stackoverflow.com/questions/6114435/in-mustache-templating-is-there-an-el
egant-way-of-expressing-a-comma-seperated-l

Adding a 'last' property (or something like it) to the last entry in each list 
is probably cleanest. It looks like ShaderProgram#getAttribute/getUniform would 
be the best place, as object enumeration order is undefined and the last entry 
is not known until that function returns.

What steps will reproduce the problem?
1. Install glsl-unit with npm on Windows
2. Try to run glsl-compiler

What is the expected output? What do you see instead?
Expected “node.js” to be executed, but “template_glsl_compiler.js” is 
opened with Windows JScript.

What version of the product are you using? On what operating system?
Windows 7, npm 1.1.45, glsl-unit 0.0.7

http://stackoverflow.com/questions/10905438/npm-generated-command-not-calling-no
de

What steps will reproduce the problem?
1. Clone repository
2. Try to run example as described in the wiki Getting started
(https://code.google.com/p/glsl-unit/wiki/GettingStarted)


What is the expected output? What do you see instead?
Expected : test are running
but I get :
unable to read configuration file

What version of the product are you using? On what operating system?
latest version from project

glsl-unit can currently use the same name for uniforms and attributes in the 
minified output. Recent changes in Chrome mean that such programs will no 
longer link:
  https://groups.google.com/d/msg/webgl-dev-list/LopzjRB7w5Y/1X2f7DdYCwwJ

What steps will reproduce the problem?
1. Compile the attached shader with glsl-unit.
2. Observe the output of glsl-unit: the name "c" is used for both an 
attribution and a uniform.

What is the expected output? What do you see instead?
Names should not be re-used.

What version of the product are you using? On what operating system?
Observed with glsl-unit at f80be0a52e07429b0a0fe8b8368895f5e0159294 (master as 
of May 2012, currently the latest version).

Would you be able to bump the version number and publish a new package to the 
npm registry?

I'm also curious if you'd be willing to move this repository to GitHub in hopes 
of giving it some more visibility and perhaps attracting other contributors.

Thanks

Would be very useful!