Examples don't pass cmake for Emscripten #29
Comments
|
OK, as I had already expected, I had messed up the path settings for cmake. This successfully generates js make infrastructure for triangle and viewer.
which I assume has to do with the Which feature must be enabled to get RGB support into the emscripten Magnum build? |
|
Hey, thanks for the nice words! It made my day much brighter :) Really. Some examples not building correctly on Emscripten -- to make the code simple and fun to read without overwhelming platform specifics and ugly boilerplate for various mobile platforms, the I'm planning to revive it after I drop the backwards compatibility and then I try to port as many examples as possible to Emscripten and elsewhere, making use of web audio, WebGL 2 etc., but currently can't say any date as I'm quite overwhelmed with my job. Regarding the viewer example: fortunately, just to get it to compile on WebGL 1, just change Sorry if this feels too much like |
|
For the generates without ado, but the (make-) build fails with due to make's double colon plague¹, the culprit is the Commenting out line #60 and replacing the string But if I publish the installed site page with e.g.
It doensn't. ¹ Switching to cmake's |
|
Yes, sorry, this is exactly what I meant by saying that the Curious, if you run the example from the link above, does it show Suzanne or also fails with similar JavaScript error? I might have some time during the weekend, so I'll try to clean it up and fix the issues -- the build system should be similarly easy to use as with the desktop builds, definitely not this hard and broken. |
Could it be that one would better use the
Your showcase's Suzanne is all nice and well with current Iceweasel, Chrome and Epiphany on my Debian 8 box. And cool - literally: Indeed, exactly the fact that that showcase is working that fine initially put me on the emscripten trek. |
ah! :) Yes, you might get some more progress by using the Your encouragement is making me want to give up everything else now and just focus on having the |
|
Okay, I went all on it and:
If you check out the |
|
@mosra:
Well - Suzi painted black? Call it a feature - that's an homage to the Rolling Stones. Period. :) That's because the "lightcolor" Uniform is not set in Magnum's "phong.frag" if GL_ES is defined - try e.g.: ♬ and no black anymore That's of course just a debug hack, don't know whether you want to fix that for WebGL in the C++ source or in the GLSL. |
Hah :D The default value is not set in ...
/* Set defaults in OpenGL ES (for desktop they are set in shader code itself) */
#ifdef MAGNUM_TARGET_GLES
/* Default to fully opaque white so we can see the textures */
if(flags & Flag::AmbientTexture) setAmbientColor(Color4{1.0f});
else setAmbientColor(Color4{0.0f, 1.0f});
...So I still have to investigate. But couldn't reliably reproduce today, so it was maybe just some random error (library mismatch?). Or does it look all black with just white speculars for you too? |
NW : screenshot of your showcase's Suzi As one can see, btw, specular highlights are always visible. And that's totally conclusive; here https://github.com/mosra/magnum-examples/blob/master/src/viewer/ViewerExample.cpp#L394 void ColoredObject::draw(const Matrix4& transformationMatrix, SceneGraph::Camera3D& camera) {
_shader->setAmbientColor(_ambientColor)
.setDiffuseColor(_diffuseColor)
.setSpecularColor(_specularColor)
.setShininess(_shininess)
.setLightPosition(camera.cameraMatrix().transformPoint({-3.0f, 10.0f, 10.0f}))
.setTransformationMatrix(transformationMatrix)
.setNormalMatrix(transformationMatrix.rotation())
.setProjectionMatrix(camera.projectionMatrix());
_mesh->draw(*_shader);
}
there are all colors set except lightColor, which is used and used only for the Lambert part of the Phong fragment shader. |
|
Thanks a lot for the debugging, you pointed me to the right location! Just a few lines below the setup for default ambient color I posted above there was also default light color and that worked flawlessly for years so I assumed the problem just couldn't be there. But in fact it was! The problem originates in mosra/magnum@da2ac00, more precisely here (can you spot it?): diff --git a/src/Magnum/Shaders/Phong.cpp b/src/Magnum/Shaders/Phong.cpp
index 4f76a9e..61aa8a3 100644
--- a/src/Magnum/Shaders/Phong.cpp
+++ b/src/Magnum/Shaders/Phong.cpp
@@ -113,13 +113,13 @@ Phong::Phong(const Flags flags): transformationMatrixUniform(0), projectionMatri
/* Set defaults in OpenGL ES (for desktop they are set in shader code itself) */
#ifdef MAGNUM_TARGET_GLES
/* Default to fully opaque white so we can see the textures */
- if(flags & Flag::AmbientTexture) setAmbientColor(Vector3{1.0f});
- else setAmbientColor({});
+ if(flags & Flag::AmbientTexture) setAmbientColor(Color4{1.0f});
+ else setAmbientColor(Color4{0.0f, 1.0f});
- if(flags & Flag::DiffuseTexture) setDiffuseColor(Vector3{1.0f});
+ if(flags & Flag::DiffuseTexture) setDiffuseColor(Color4{1.0f});
- setSpecularColor(Vector3(1.0f));
- setLightColor(Vector3(1.0f));
+ setSpecularColor(Color4{1.0f});
+ setLightColor(Color4{.0f});
setShininess(80.0f);
#endif
}It's fixed now in mosra/magnum@71f57b5. Thanks again. |
@mosra ? |
How does that relate to the bugfix above? I'm not sure I understand.
Funnily enough I already tried this optimization in my previous project in order to reduce the number of GL calls per frame -- every shader class had a cache of the uniform values and every setter was first comparing the value to the cached one and only if it differed it was calling The engine is doing state tracking of almost everything except uniforms, because I don't see any visible gain in doing so and the amount of code and testing needed for that would be huge. If this proves to be a bottleneck in your application, you can always do one of these things:
This is way beyond scope and KISS philosophy of the engine, sorry ;) Since OpenGL is inherently single-threaded, I don't see point in having thread-safe access to uniforms. If you need this, you can always wrap the shader class on application side, if you just need to see what uniforms are being set, you might be better off with some GL debugger/tracer such as Apitrace or Renderdoc. |
Such comparisons are inherently expensive, better pimpl the setter to a no-op functor if the value is clean and to a glUniform() calling functor if it got dirtied.
The point is that there's no limitation of what the rest of an app does to the data set by the glUniform calls and when. |
|
Sorry, that still seems like a lot of coding and runtime overhead for questionable benefits. As I said above, if profiling shows that this functionality is needed, it can be always implemented on top of current simple shader API. |
|
It doesn't have to be all incorporated by Magnum right away, but to incorporate it efficiently in an application it at least needs an access point deep enough in the Magnum API stack. |
|
I have a feeling that we are talking about vastly different things here. Maybe I misunderstood your original question or maybe you think Magnum works differently. Let me clarify:
In case this still doesn't answer your question, could you maybe explain your point with a small code snippet? |
github-project-automation
bot
moved this to Done
in Magnum Examples / Project management
On Debian 8 x86_64 I've successfully built and installed corrade, magnum and magnum-plugins¹ for both the system's ELF clang-3.5 chain and for the emscripten (emcc 1.36.0) chain.
I sudo-installed corrade, magnum and magnum-plugins¹ underneath default /usr/local; "emsdk_portable" resides in my home directory.
Given that environment, the magnum viewer example builds flawlessly with the clang for ELF. and emcc and em++ compile HelloWorld programs to valid js.
On the example tree, however, after git'ing the
toolchainsmodule and patchingtoolchains/generic/Emscripten.cmaketo point to my emsdk location, cmake (3.0.2), invoked from a build dir underneath themagnum-examples- root dir likecmake -DCMAKE_TOOLCHAIN_FILE="../toolchains/generic/Emscripten.cmake" ..first detects valid emcc and em++ but then fails with
For my purposes, not all of the examples would need to be compiled to js, if it'd be just the viewer example itself - like it apparently was for mosra's showcases - I'd be happy enough.
Due to the complexity of the build infrastructure involved I cannot be totally sure that this is an issue - it is a perfectly plausible alternative hypothesis that I just messed sth up.
But I've tried several approaches to alter cmake-module paths, setting missing variables on the command line or in the cmake-gui etc, but to no avail yet.
Could you look into that, please?
Yours sincerely,
decltype-auto
P.S. @mosra: Your Magnum is a BRILLIANT piece of software!
Likely the cleanest real-life C++11/14 I've yet seen; I'm really enthusiastic about it.
¹ For emscripten just with
-DWITH_ANYAUDIOIMPORTER=ON
-DWITH_ANYIMAGECONVERTER=ON
-DWITH_ANYIMAGEIMPORTER=ON
-DWITH_ANYSCENEIMPORTER=ON
-DWITH_OPENGEXIMPORTER=ON
due to lack of libpng, libfont_whatever_ in my emsdk environment.
The text was updated successfully, but these errors were encountered: