Common Problems
This page lists some common problems and solutions that may be encountered when using XML3D.
When troubleshooting a problem with XML3D it's helpful to open the developer console in your browser and check the console output for errors from XML3D. It's also helpful to reload the page with the logging level set to all by appending ?xml3d-loglevel=all to the end of the page URL.
xml3d.js doesn't include a camera controller by default. Never fear! We've released a standard camera as a plugin that should be included separately in your scene and then initialized:
<script type="text/javascript" src="http://xml3d.org/xml3d/scripts/tools/camera.js"/>
<script type="text/javascript">
function onload() {
var viewElement = document.getElementById("myViewElement");
var cam = new XML3D.StandardCamera(viewElement, options);
}
</script>This is a simple camera that's meant to provide basic interaction with your scene for both mouse and touch devices. You're free to use it as a basis for developing more complicated camera controllers.
If left alone the camera controller will try to initialize itself with the first <view> element that it finds.
There are a lot of different causes for this, the first thing we should do is check the Javascript console for any errors. HTML errors such as 404 or 500 can point to broken links or server problems. These will often be followed by Mesh Error: Mesh does not have 'position' attribute. which is XML3D indicating that it didn't find valid data for the model.
An Invalid external XML document error usually means the model was found but could not be parsed for some reason. Check the model file for syntax errors and make sure the server is sending the model correctly. Some browsers may also truncate xml files that are too large, in that case try splitting your model up into smaller ones.
If you don't see any error messages in the log then first check to make sure the material for the model isn't fully transparent. Some exporters and converters may forget to invert the alpha value when switching between 'opacity' and 'transparency'.
Next, try scaling your model by a factor of 10 or 100. This can help identify scaling or positioning problems.
Finally you could try removing the material from the model. This will cause it to be rendered with a default material instead which can help identify problems with the material that you're using.
First, make sure the model is using a shaded material such as urn:xml3d:material:phong and that the model includes surface normals. Make sure the ambientIntensity field of the material is less than 1, otherwise it will wash out the diffuse and specular shading entirely.
If the shaded surface of your model looks patchy where it should be smooth this usually points to incorrect normal values in your model data. Try exporting it again or using a different exporter/converter.
XML3D expects a valid Content-Type header for every external document that it needs to load. In some cases you may need to change your server configuration to supply the right content type for a particular file type, especially if you're using BLAST with its unique .blst extension. Some servers (eg. Apache 2.4) will send files without a content-type header if the extension is not familiar.
Content types don't need to match the file contents exactly, for instance it's enough to use a content type of application/xml for any xml file, regardless if it's an asset or a collection of mesh data. Binary file types (including BLAST) can be sent with the generic application/octet-stream MIME type. For binary files it's important to use either a .bin, .bson or .blst extension.
If you encounter this error and you're not sure what content type (if any) is being sent by your server then check the Network tab in the Chrome Developer Tools (Ctrl+Shift+J). Here you can check the Response Headers for a valid content-type.