DeveloperError: normalized result is not a number #4863
Comments
|
@grmc144 I wasn't able to reproduce this. Could you please provide more information? Thanks! |
|
I also came across this recently but haven't been able to reproduce it on Sandcastle. I was able to get around it by setting |
|
This seems to happen when your cartesian coordinate is 0,0,0. The resulting magnitude then is also 0 which results in a division by 0 in the normalize function. (see https://github.com/AnalyticalGraphicsInc/cesium/blob/master/Source/Core/Cartesian3.js#L408) It happens a lot with us when transforming our data to a custom cartesian tiling grid where the lower left vertex usually falls on 0,0,0. |
|
@ketulm @tomvantilburg do either of you have sample code or sample data to reproduce this? Cesium shouldn't be trying to normalize the zero vector. This case should be caught further up the pipeline before this error is thrown. |
|
This should do the trick: |
|
Thanks @tomvantilburg, but I know that's what is causing the developer error to be thrown. The error is in place so we can catch bad data coming in from other parts of the code, so it is expected to be thrown when you're trying to normalize the zero vector. |
|
Thanks for looking into this @hpinkos and sorry for being not verbose. Here's the full story: We are trying to convert a set of obj files to a gltf file with the help of obj2gltf. The error message shows up in obj2gltf but originates from cesium (see stack below). Oddly enough, there are no vector normals in the obj file, so I can't see where this goes wrong along the way. Worth noting: We did translate all coordinates to a 0 0 based grid first, so some lower left coordinates are very close to 0, 0, 0 Here is the defaulting obj file: And here the corresponding code calling for obj2gltf: https://github.com/Geodan/3dfier-tiles/blob/master/src/obj2gltf.js Error Stack: |
|
It looks like the error is coming from the part of the glTF pipeline that
generates vertex normals, it might be trying to generate normals for a
triangle that has two or more identical positions, hence the divide by zero
error.
I'm not getting any problems with the linked file and the obj2gltf command
line tool, though. You mentioned translating all coordinates to a 0, 0
based grid, any chance there's something going wrong in that stage?
…On Fri, Jan 20, 2017 at 4:04 AM, Tom van Tilburg ***@***.***> wrote:
Thanks for looking into this @hpinkos <https://github.com/hpinkos> and
sorry for being not verbose. Here's the full story:
We are trying to convert a set of obj files to a gltf file with the help
of obj2gltf. The error message shows up in obj2gltf but originates from
cesium (see stack below). Oddly enough, there are no vector normals in the
obj file, so I can't see where this goes wrong along the way. Worth noting:
We did translate all coordinates to a 0 0 based grid first, so some lower
left coordinates are very close to 0, 0, 0
Here is the defaulting obj file: http://research.geodan.nl/
sites/cesium/data/object.tar.gz
And here the corresponding code calling for obj2gltf:
https://github.com/Geodan/3dfier-tiles/blob/master/src/obj2gltf.js
Error Stack:
{ [DeveloperError: normalized result is not a number]
name: 'DeveloperError',
message: 'normalized result is not a number',
stack: 'Error\n at new DeveloperError (/var/data/git_repos/3dfier-tiles/node_modules/cesium/Source/Core/DeveloperError.js:44:19)\n at Function.Cartesian3.normalize (/var/data/git_repos/3dfier-tiles/node_modules/cesium/Source/Core/Cartesian3.js:422:19)\n at Object.GeometryPipeline.computeNormal (/var/data/git_repos/3dfier-tiles/node_modules/cesium/Source/Core/GeometryPipeline.js:1176:28)\n at generateNormals (/var/data/git_repos/3dfier-tiles/node_modules/gltf-pipeline/lib/generateNormals.js:57:34)\n at Function.Pipeline.processJSONWithExtras (/var/data/git_repos/3dfier-tiles/node_modules/gltf-pipeline/lib/Pipeline.js:91:5)\n at /var/data/git_repos/3dfier-tiles/node_modules/gltf-pipeline/lib/Pipeline.js:194:29\n at tryCatcher (/var/data/git_repos/3dfier-tiles/node_modules/bluebird/js/release/util.js:16:23)\n at Promise._settlePromiseFromHandler (/var/data/git_repos/3dfier-tiles/node_modules/bluebird/js/release/promise.js:510:31)\n at Promise._settlePromise (/var/data/git_repos/3dfier-tiles/node_modules/bluebird/js/release/promise.js:567:18)\n at Promise._settlePromise0 (/var/data/git_repos/3dfier-tiles/node_modules/bluebird/js/release/promise.js:612:10)\n at Promise._settlePromises (/var/data/git_repos/3dfier-tiles/node_modules/bluebird/js/release/promise.js:691:18)\n at Async._drainQueue (/var/data/git_repos/3dfier-tiles/node_modules/bluebird/js/release/async.js:133:16)\n at Async._drainQueues (/var/data/git_repos/3dfier-tiles/node_modules/bluebird/js/release/async.js:143:10)\n at Immediate.Async.drainQueues [as _onImmediate] (/var/data/git_repos/3dfier-tiles/node_modules/bluebird/js/release/async.js:17:14)\n at processImmediate [as _immediateCallback] (timers.js:383:17)' }
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#4863 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFJTN_ComS75gm2mR0WV-NY8gZQh50D_ks5rUHiGgaJpZM4Li3so>
.
|
|
that error came on angular js error.now its fix
|
|
It seems I gave the wrong example file, apologies. Here is one that goes wrong: http://research.geodan.nl/sites/cesium/data/object2.tar.gz |
|
I'm not getting errors from the obj2gltf command line tool with this one
as-is either, so I think it might be the translation thing. Have you
considered using the node transform
<https://github.com/KhronosGroup/glTF/tree/master/specification/1.0#transforms>
attribute in glTF instead of translating the points in the obj file? This
might get around the problem if it's with translating obj positions.
…On Tue, Jan 24, 2017 at 10:29 AM, Tom van Tilburg ***@***.***> wrote:
It seems I gave the wrong example file, apologies. Here is one that goes
wrong: http://research.geodan.nl/sites/cesium/data/object2.tar.gz
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#4863 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFJTN6c2aho5I7F7HYcmaLdiIgxdOq74ks5rVhj1gaJpZM4Li3so>
.
|
|
I ran into this same problem, using the obj in the zip and |
|
Looks like it's happening at line 1178 of GeometryPipeline: Cartesian3.clone(Cartesian3.ZERO, normal);
for (j = 0; j < vertexNormalData.count; j++) {
Cartesian3.add(normal, normalsPerTriangle[normalIndices[vertexNormalData.indexOffset + j]], normal);
}
Cartesian3.normalize(normal, normal);In my case |
|
@JakeDluhy sorry for the extremely slow response. This case can happen if your model's winding order is inconsistent, see here: CesiumGS/gltf-pipeline#242 (comment) For now, if you can get your model imported into blender and then re-exported with normals, it should be able to go through obj2gltf without having to compute new normals. We're working on a fix in the meantime. |
|
Hi Guys, this is a little off topic, but same error. Looks like if you have a polygon covering the poles that has a fill a DeveloperError: normalized result is not a number error is thrown. The following code gives an example. Setting fill to false results in no error being thrown.
|
|
I get this while drawing walls. Here is sandcastle working and not working data example: |
|
You can reproduce this problem in the billboard sandcastle: https://cesiumjs.org/Cesium/Build/Apps/Sandcastle/?src=Billboards.html&label= Zoom in close-ish to the Cesium billboard and hold the mousewheel down to rotate. If you rotate over and over in random directions (basically spinning around) then the normalize error will occur.
|
|
Hi! I use the code on https://cesiumjs.org/Cesium/Build/Apps/Sandcastle/?src=Billboards.html&label= the function became function addBillboard() { } The problem really happens on normalize with (0,0,0) Its easy to correct the Cesium code. Just verify 3258 of Cesiun.js before calc result, verify if magnitude is 0; or to be more smart, verify before to call normalize, because normalizing a vector with zeros is everytime zero. |
|
@gtzaniboni It is expected that |
|
var greenPolygon = viewer.entities.add({ viewer.zoomTo(viewer.entities);` |
|
What you have is a polygon with a duplicate point in latitude/longitude, differing only in height.
This will work if |
|
Thanks for reporting that @chenluweix! We should be removing those duplicate positions to avoid that crash. I open up this pull request to fix that problem: #6731 |
|
@gtzaniboni thank you for answer, i''ve done a similar local fix myself ahah, and its kind of working, at least the app doesn't crash and i get to see the full tiles. But it would be great if someone from cesium with more context of the code, could solve it. |
|
@andreddosantos does this only happen on iOS? Does the crash happen when there is no tileset loaded? Can you paste the callstack from the unminified version of Cesium? |
|
Hannah, it does not happens with me in a strict way... in other words, some
combination from pinch, rotate and other transformations done directly on
the canvas put the system in some situations that one ZERO vector was
passed to the normalize function.
We can reproduce it in a strict way forcing the normalize of a ZERO vector,
which is worng, but is the way to reproduce the error. But, the error
ocours when scale/rotate/translate the map by gesture...
thanks,
Em qua, 10 de out de 2018 às 11:18, Hannah <notifications@github.com>
escreveu:
… @andreddosantos <https://github.com/andreddosantos> does this only happen
on iOS? Does the crash happen when there is no tileset loaded? Can you
paste the callstack from the unminified version of Cesium?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#4863 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/Alh5m-YyL29LojlhthXrQ__TlrKSxodNks5ujgHLgaJpZM4Li3so>
.
|
|
Thanks for the update @gtzaniboni. I noted in #7143 (comment) that there seems to be an influx of camera related crashes and I'm hoping our graphics team will be able to look into it soon. |
|
@hpinkos Nope this is also happening in android. |
|
（1）在http://localhost:8080/Apps/Sandcastle/index.html?src=Rectangle.html&label=All里 }); |
|
@HuZhuangQiang I just opened a pull request with a fix for that issue yesterday: #7452 |
|
@hpinkos |
|
@HuZhuangQiang unfortunately no. We have a separate issue open for that here: #4746 var redRectangle = viewer.entities.add({
name : 'Red translucent rectangle',
rectangle : {
height: 0,
coordinates : Cesium.Rectangle.fromDegrees(-180.0, -80.0, 180.0, 90.0),
material : Cesium.Color.RED.withAlpha(0.5),
}
}); |
|
We have also encountered this error. The cause was two identical points used for making a polygon. In other words, a zero-length line seemed to be the cause or the absence of the third point in the polygon. Didn't work-out which one of these two though. |
|
@Gnumster do you have some sample code you can share with us to reproduce that error? |
|
I'm still having this error, randomly when interacting with features. |
|
I am getting this error when I use |
|
Range must be a non-zero, positive value in this situation where you are essentially defining a vector/line between two points. |
|
I am getting this error with a simple example: var viewer = new Cesium.Viewer('cesiumContainer');
//var dataSource = Cesium.GeoJsonDataSource.load({"type":"Polygon","coordinates":[[[0,0],[10,0],[10,5],[2,5],[2,30],[0,30],[0,0]]]});
var dataSource = Cesium.GeoJsonDataSource.load({"type":"LineString","coordinates":[[0,0],[10,0],[10,5],[2,5],[2,30],[0,30]]});
viewer.dataSources.add(dataSource);Note: The commented out polygon works fine. |
Weird. This renders: |
|
@electricsam thanks for reporting this, and @Maarondesigns thanks for the reduced test case. This looks like a separate issue where the geometry pipeline may be making an incorrect assumption. I opened a separate bug report for this here: #8464 |
|
I am having this error message though I do not know if it is related to this issue. Feel free to split it out. I didn't want to create a duplicate issue. I get this error message if I am using orthographic projection but not if I use perspective projection. It happens when using QtWebKit 5.6.1 (CentOS 6.10), 5.9.1 (CentOS 7.8), and 5.212-alpha3 (CentOS 8.2) as the "web browser". This is new for Cesium version 1.73. It did not happen with version 1.70. I have not tested version 1.71 and version 1.72. It happens when I call both flyHome and setView. Would appreciate if this could be addressed. It doesn't seem to break anything that I can see but the error message causes concern with the user of the product who thinks the product is broken when they see the error in the terminal (I redirect JavaScript console messages to the terminal). Below is a traceback for flyHome call: qrc:///map/cesium/CesiumUnminified/Cesium.js:83: DeveloperError: normalized result is not a number Thanks. |
|
@he-hesce are you able to reproduce this in the browser outside of Qt? If not it would be helpful for you to run off of the CesiumJS and git bisect to find where this break might have happened. Either way, feel free to open a new topic on the community forum (https://community.cesium.com/) to document this until it can be determined what the cause of the issue is and we can open a GitHub issue here. |
|
@OmarShehata, It would take some effort to get it running outside of embedded QtWebKit. I tried to create a minimal example to reproduce it with Sandcastle and latest Safari but I can't reproduce the error message there. For now I will downgrade to 1.70 (or 1.71 or 1.72 if they work fine) to get rid of the error message until I have time to return to this some day, and I'll keep trying new releases of Cesium to see if it goes away. |
|
@OmarShehata: I've now tested 1.70.1, 1.71, 1.72, 1.73, and 1.74. The issue was introduced between 1.70.1 and 1.71. For now I will use 1.70.1 as it is working. Cheers. |
have the same problem |
|
Did this ever get anywhere? Like @Gnumster almost 3 years ago, I accidentally supplied identical points to a PolygonHierarchy and suffered the same crash. Minimal sandcastle -- should crash after 10 seconds, when it tries to add a polygon that only uses the same point repeatedly. (I was reading coordinates from a WKT string, and accidentally passed the lat/lon to |
and others
The text was updated successfully, but these errors were encountered: