User posts Ryan Uttech
12 January 2015 22:15
Yes, that's the page I get. For some reason the attachment(Screen Shot) did not attach.
12 January 2015 20:59
This the page i get.
Attached is a screen shot as well.
12 January 2015 20:56
Here's a list of all the browsers and their versions that support WebGL.

12 January 2015 20:55
We'll be setting up an error message prior to initializing Blend4Web. We'll check the browser version first.
12 January 2015 20:27
I noticed that when a browser does not have WebGL turned on the error message that is placed on screen has a link to "". This page does not exist, I would either update the page to forward to the correct spot or change the text in the code to have a link to the correct location.
12 January 2015 20:24
I am getting the JS error on the follow spec:

Safari: 5.1.10

OS: 10.6.8

WebGL enabled

Js Error: TypeError: 'undefined' is not a function (evaluating 'a.getShaderPrecisionFormat(a.FRAGMENT_SHADER, a.HIGH_FLOAT)')

It just stopped on the preload screen (Blend4Web's API Simple Preloader).
09 January 2015 00:44
So the best way to get around some of the issue is I turned on smoothing on an entire object. Then, the polys that had normal issues I selected and set smoothing to flat. It fixed the issue enough. I would recommend to anyone exporting models from another 3D program to export as Objs. These will maintain the smoothing groups the best.

The best way to solve my issue would be to rebuild the model. Since the model was built outside 3DSMAX and Blender the imported files have computer generated polys and some of the vertices and edges aren't even welded properly. We only have 2 weeks to complete a mode; including all textures, animation and modeling (pieces that were not included from the client and wiring). Typology is not worried about as much since these high res models are only used for still renders and image sequences using 3DSMAX and VRAY. As a game artist these models make me sick, but typology is the least of our worries since they look fine when rendered.
06 January 2015 01:24
Seems that I if I go back to the edit mode all the normals reset. (Which to me seems like a flaw) How is a user to select different verts on different sides without being able to go back into edit mode?
06 January 2015 01:19
I've continued working with the model. Since the original files we receive are .ASMs and .PRTs (PRO-E Files) the typology is terrible. Some of the edges and verts aren't even connected correctly. I have worked with the Blend4Web Normals editor, but no matter how many times I click on 'Save', the next set of verts I change resets my last fix.

This also happens when I enter back into edit mode from object mode. I selected the normals I wanted to edit, clicked reload normals, then hit save. The model looks good at this point. As soon as I go back into the edit mode to select new verts my normals reset themselves. Is there something i'm doing wrong? I read and went through all the steps as per the documentation:

In the general case the algorithm for normals editing is as follows:
Entering to the edit mode
Selecting the needed vertices (Found the verts I wanted to edit)
Entering to the object mode (Shows the verts selected when I have the 'Show' normals turned on under Blend4Web)
Reload Normals (Clicked this button and it reset the normals to what I wanted them to look like)
Editing the selected normals (Didn't need to do this since the normals reset correctly after the reload)
Save (if Autosave is inactive) (Clicked Save, numerous times)

-Yuri- Baking the Normals would not work in this case since the typology is bad and we do no have time to recreate the model.
05 January 2015 17:38
Thanks for the response everyone. I've looked into using the normal editor, but for the time constraints we have on the projects we are working on this will not be efficient. I'm going to look into prepping the model differently before bringing it into Blender. If anyone has any input on what would work the best please let me know. If I find out anything I'll be glad to post my findings.