Unable to view dungeon or lights and shadows demo

[JulieMay]

The demos:
http://sinisterchipmunk.github.io/dungeon.html
http://sinisterchipmunk.github.io/lights_and_shadows.html

The previously mentioned demos come up with a black screen. Using Google Chrome, Version 29.0.1547.62 m

All of the other domos view properly in Chrome.

On another note, in Firefox when I tried to move the teapot in lights and shadows the teapot would not move with mouse control re: http://sinisterchipmunk.github.io/lights_and_shadows.html Firefox Version: 23.0.1

[sinisterchipmunk]

What hardware are you using? All the demos render as expected on my older model (2010 I think?) Macbook Pro / nVidia, and on my Windows 7 / ATI desktop last I checked.

The demos were written in Jax 2.x, which had some problems when running on mobile hardware. From my testing, the master branch seems more reliable on mobile devices.

Interestingly, the mouse dragging seems broken for me in Chrome 29.0.1547.65 as well. My local (Jax 3.x dev) version of the same demo works fine, so I assume something in the standard has changed since the demo was last worked on.

[equityboost]

None of the demos work for me. I'm running a GL3.1 capable Intel video card and latest version of Chrome on Windows 8.1. Never had a problem running other webgl apps so I'm thinking there must be a jax issue.

[Goutte]

Hello !

I found out that some video cards failed to read the shaders (of both cyx and jax demos) :

• Geforce 660M
• GeForce GT 650M

Some people were on Windows, some on Mac.
The error is always the same :

WebGL: INVALID_OPERATION: getUniformLocation: program not linked
Uncaught Error: Could not initialize shader!
Uniforms with the same name but different type/precision jax.js:33

There are uniforms in the shaders that some video cards just can't eat, it seems.
Of course, javascript breaks at this Error, which makes it annoying.

---

Any hint ?

[sinisterchipmunk]

This may relate to an issue I hit recently in development on jax-core, where Chrome complained about int precision. On master, I ensured that the default precision is set for int just as it is for float, resolving the problem. I do not recall updating the demos, however.

I have a new local dev branch where I am making drastic changes to shaders. It contains breaking API changes but much better performance and control over issues like this. Because it will break all existing shaders, I have been loathe to merge it into master, but I am increasingly convinced that it is the Right Way (TM) so expect that to be merged prior to the final 3.0 release. Ill push the branch up next time I'm on my dev box, probably after Xmas, and link to it from this issue so you all can tell me if it's a bad idea or not before it is final.

[Goutte]

I tested with the current master, and it looks like the shader issue melted away ! 💛

---

Just a quick note : Camera.unprojectLineSegment references Camera.unproject instead of Camera.unprojectPoint.

Also, I'm having a hard time building back my trackball controls, as setFixedYawAxis disappeared ; I'll come back here and whine a bit if I can't figure it out by myself !

[Goutte]

It was trivial, using the second parameter of Camera.setDirection. I'm eager to see what improvements you hacked into the shaders.

See you all next year !

[sinisterchipmunk]

I tested with the current master, and it looks like the shader issue melted away !

Great news!

It was trivial, using the second parameter of Camera.setDirection

Yeah, since it was only really used by that API, it seemed smarter and more convenient to make it a parameter.

I've just pushed my latest development effort to improve-shaders-and-materials. Save for a few minor bugs, it's ready to be merged into master. As promised, I'll hold off long enough for anyone with feedback to give me some. I think it makes custom Materials conceptually easier to manage, and I also think it puts much more control over the shader source in the hands of the developer than the old "Layer" approach did. There's far less magic going on under the covers, and that's a good thing. Materials are now more tightly coupled to their shaders -- I hemmed and hawed about this for a long time, but in hindsight I think it was the right choice, as shaders are essentially the presentation layer for a material and rely heavily on what exactly composes the material itself.

I intended the changes to the built-in Materials to be compatible with scenes that don't rely on custom shaders, but the new API will break every custom material and shader in use today.

The new system is somewhat less plug-and-play than the old. This is a little disappointing and may seem like a regression at a high level. However, the old system wasn't really all that great at plug-and-play either. It worked acceptably well (notwithstanding an expensive compilation step) when each Layer operated in isolation, but tended to fall apart when they needed to cooperate with one another (for example, combining normal maps with procedural surface normals). The new system essentially replicates Layer in the form of functions, and each Material shader writes its own main() which can then call those functions directly. This approach is a little more in line with the way GLSL was designed. The idea of imports, exports and shared variables has been removed entirely, as relevant values are now managed directly by a material's shader sources.

Also, the branch contains two major victories: event-driven variable assignments, meaning that variables such as light position are only calculated and assigned if the relevant data actually changes; and single-pass, multi-light rendering. I was able to exploit the new system to allow up to 6 lights to be rendered in a single pass. We still support an arbitrary number of light sources; they'll be rendered in 6-light batches (6, 12, 18, etc) which should make even the most light-intensive scenes pretty performant. Caveat: I might have to tweak this number (I originally tried 8) based on hardware limitations to ensure the shaders can actually compile on less capable hardware. I haven't tested what might happen on a mobile device, for example. Ultimately, the system will tweak lights-per-frame based on the capabilities of the device -- but it doesn't do that yet.

[Goutte]

I promise I'll play with shaders when I grok them ! :)

Meanwhile, I figured this might interest you, if you don't already know about it : http://ioccc.org/2013/hou/