This is the binary:
http://puu.sh/oks69/f9f950b505.jpg
This is the HTML5:
http://puu.sh/oksdK/7c9d3ea209.jpg
Text in other places is completely out of boundaries, particle effects aren’t showing at all, the skybox is weird, everything is edgy, and the fps seems to be really bad. Does this have anything to do with chunks?
Binary:
http://puu.sh/oksmn/e2c76d2843.jpg
HTML5:
http://puu.sh/oksEn/ef890221a5.jpg
Did I miss some settings? How can I fix this? I tried editing the .wrapper class in the index.html, but that didn’t really help much. Ideas?
Perhaps the good version is using deferred high end GL/D3D shading path? The HTML5 version is limited to GLES2/forward shading path. There is some way to simulate the GLES2 feature level preview in the editor. Does that account for the differences?
I have failed to find any such settings in the HTML5 section. I’d appreciate a screenshot.
See here:
Although I think it’s possible that the preview is not able to account for all the differences in deferred vs forward shading quality levels. For example In HTML5, why some materials are faulty and some are not - they use the same parameters - Platform & Builds - Epic Developer Community Forums seemed like a scenario where the preview did not know to account for a difference in GLES2 vs desktop GL.
Yes, it does account for the rendering problem, but the menu size problem still remains, something wrong with the text position, in some cases it leaves the button. Any idea on a solution?
Should I just bake all the lights then? I suspect GPU particles are also not supported so I’ll have to change them as well. I also have never had to do things for forward rendering, it’s pretty old school no? If I understand correctly FR resolves only on the gpu, so different pc configs will have different results. Normal maps and other fancy maps are ignored.
This is just a test project so I don’t think I’ll be banging my head about it, but I was kinda hoping to have my next game to be both playable on my website and have it’s own standalone, both with close enough quality.
I’m not very well versed with shaders, but from what I see there is no silver bullet for this problem here. Still, I’d be happy if you give me an idea on how to set it up right, so that I don’t run into such a problem in the future.
Not sure about the text positioning differences. Those sound like that they shouldn’t be affected by the shading quality level.
Forward shading is not necessarily old school, but in context of UE4, it’s definitely lower end graphics wise. Unfortunately it’s not possible to implement the higher quality levels by backing on to WebGL 1 alone. There is upcoming WebGL 2 specification (WebGL 2.0 Specification) that bumps up browser graphics capabilities to GLES3.0 level, but that has not yet reached stable browser versions. Firefox Nightly and Chrome Canary do have experimental implementations, and of course UE4 engine needs to be improved to utilize WebGL 2 after it ships to gain the benefit.
So basically there’s nothing I can do to improve the quality?
Probably depends on how much you are interested in getting your hands dirty. Since the sources are available, you could go and implement WebGL 2 rendering support to fix all the differences, but that can be a bit hardcore.
One thing you could do is attempt to break down the different graphical mismatches into individual test case projects with more detail. For example the differences in text rendering (spacing, font size, etc.) don’t looks like they’d be explained by forward vs deferred alone. It is possible that there are individual bugs that contribute to some of the differences, and that not all of it is due to the quality level. I can’t say for sure, but in any case, test builds & projects that zoom in on individual items at a time (rather than multiple discrepancies at a time) could be helpful for the UE4 developers directly to take a peek at. Sorry I don’t have a better help to offer here
Btw, regarding the performance issues you mentioned, I did found three items which altogether cause about a 20-30% slowdown in UE4 HTML5 builds:
-
HTML5 OpenGL backend doesn't need to flush GL commands - Platform & Builds - Epic Developer Community Forums
-
"Smooth Frame Rate" and "Use Fixed Frame Rate" should not be used in HTML 5 exports - Platform & Builds - Epic Developer Community Forums
-
Extend the glUniform*fv upload functions to reuse the preallocated ty… · emscripten-core/emscripten@2c6e2a7 · GitHub
With these fixes HTML 5 builds get a nice performance improvement.
The last one will come in UE4 in a future version, although one can apply it directly to one’s local installation manually by editing src/library_gl.js in the UE4 source directory.
Aight man thanks for all the info. Been of great help.