[2.1] SceneNode position - rounding? truncated resolution? Topic is solved

[Spectre]

Hello, I'm porting Ogre1 code to Ogre2, and Ogre2 seems to have a bug where scene nodes are placed not exactly, but with some margin of error. Huge seams are visible between the map objects, but only in ogre2 - physics engine displays objects being placed exactly, and ogre1 too had placed them flawlessly in that regard.

I've noticed that seams between the objects are repeating every 312.0 units, so the placement error is consistent and depends on distance, if that helps debugging the problem.
My first though was something regarding float precision, but this can't be a concern in such short distances less than 1000 units away from the origin, not to mention ogre1 and physics engine don't suffer from it, unless Ogre2 scene nodes use 16bit floats or something?..

[dark_sylinc]

I can't zoom in on the image, postimg appears to be broken right now.

If you're importing a v1 mesh to v2, we default to using 16-bit half for vertex position. Make sure when importing this does not happen do that full precision is used, ag least for the meshes where exact precision matters (like the floor tiles if I understood correctly)

Edit if that's not it, try compiling Ogre without OGRE_SIMD_SSE2

[Spectre]

Yes, I'm creating mesh from raw data via binding buffers, which is done via v1 mesh, that is then imported into v2 mesh. How do I control how the import treats vertex data? V1 mesh is created with VET_FLOAT3 as VES_POSITION.
Although I don't believe it's the mesh that has the bug, or I would've seen these seams more often, I believe it's the world positions that are at fault (though I'll definitely test that before recompiling Ogre). How do simd computations tie into node positions? Can you elaborate on how to compile Ogre without that flag, or, where can I read about changing compilation settings? //What are repercussions of turning off sse2 for ogre?

______________
edit: found the "convert to half-pos" flag right in the ImportV1(), yes that was the culprit, thank you.
//Apparently big enough meshes do start to lose precision with float16, but it were vertex positions and not scene node positions. What threw me off was that the seams were perfectly lined up through the entire map in neat squares as if I'm looking at a dev grid from above.

[dark_sylinc]

Yes, I'm creating mesh from raw data via binding buffers, which is done via v1 mesh, that is then imported into v2 mesh. How do I control how the import treats vertex data? V1 mesh is created with VET_FLOAT3 as VES_POSITION.

At some point you are either calling MeshManager::createByImportingV1 (new Ogre versions) or Mesh::importV1 (older versions).

Both functions accept the following arguments:

Code: Select all

bool halfPos, bool halfTexCoords, bool qTangents

Set "halfPos" and "halfTexCoords" to false instead of true.

If you're importing using OgreMeshTool, do not use the "-O pu" flag ("-O qs" is fine)

How do simd computations tie into node positions?

When compiled with SSE2 flag (on by default), Ogre performs most computation from SceneNodes position using SSE2. The changes section in the manual describe it.

Can you elaborate on how to compile Ogre without that flag, or, where can I read about changing compilation settings?

Compile Ogre from source and turn off OGRE_SIMD_SSE2 from CMake GUI.

The build scripts make it much easier, but you'll have to edit the commands:

Where it says:

Code: Select all

%CMAKE_BIN% -D OGRE_USE_BOOST=0 -D OGRE_CONFIG_THREAD_PROVIDER=0 -D OGRE_CONFIG_THREADS=0 -D OGRE_BUILD_COMPONENT_SCENE_FORMAT=1 -D OGRE_BUILD_SAMPLES2=1 -D OGRE_BUILD_TESTS=1 -D OGRE_DEPENDENCIES_DIR=..\..\ogre-next-deps\build\ogredeps -G %GENERATOR% -A %PLATFORM% ..

Change it for:

Code: Select all

%CMAKE_BIN% -D OGRE_USE_BOOST=0 -D OGRE_CONFIG_THREAD_PROVIDER=0 -D OGRE_CONFIG_THREADS=0 -D OGRE_BUILD_COMPONENT_SCENE_FORMAT=1 -D OGRE_BUILD_SAMPLES2=1 -D OGRE_BUILD_TESTS=1 -D OGRE_DEPENDENCIES_DIR=..\..\ogre-next-deps\build\ogredeps -D OGRE_SIMD_SSE2=0 -G %GENERATOR% -A %PLATFORM% ..

What are repercussions of turning off sse2 for ogre?

Merely lower performance. But it may also have greater precision due to how handling floats in SSE works.