Reused components are scaled incorrectly when using IfcAxis2Placement3D

[muren400]

When geometries are being reused by mapping and placed using IfcAxis2Placement3D, they might be scaled incorrectly if Axis or RefDirection aren't normalized vectors.

DirectionRatios for axis and direction needs to be normalized here:

BIMserver/BimServer/src/org/bimserver/geometry/StreamingGeometryGenerator.java

Lines 881 to 882 in 2942448

	List<Double> axisDirectionRatios = (List<Double>) axis.get("DirectionRatios");
	List<Double> directionDirectionRatios = (List<Double>) direction.get("DirectionRatios");

Can't share the model this happened with, but I can try to recreate a simple example with two cubes.
Axis and RefDirection looked like this:
#50313=IFCDIRECTION((0.,0.,110.))

[hlg]

Indeed, you are right. I did a review of the functions during fixing #1127, but apparently, not everything was fixed back then (e.g. scale). Will keep the implementation close to the specification derived axis function. I minimal example would be great and can be used to secure the fix with a unit test.

[muren400]

Here's a small example file. It contains two cubes that should have the same dimensions.

cubes.ifc.txt

I can also provide a PR once the change is tested on our side.

[hlg]

I don't understand why the cubes look of same dimension in BIMvie.ws.

Well, there might be some compensation for the error in the binary serializer or even BIMvie.ws.

[muren400]

I saw the error in bimsurfer 3 and BIMvie.ws. Do you have Optimize mapped items (more reuse) enabled in the server settings?

[hlg]

I tried with and without resuse and optimization. But will check again.

[muren400]

Ok weird. Just checked myself again. The behaviour occurred in the real model on both bimsurfer 3 and BIMvie.ws but for my little test model it only occurred in bimsurfer 3.

[hlg]

I also get the same transformation from the JSON serializer for both geometries, except for the x-offset:

[1.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 1.0]
[1.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.19500000000000098, 0.0, 0.0, 1.0]

This is really weird, because the offset comes from the exact same axis placement.

[muren400]

What does the transformation look like during the checkin?

When I put a breakpoint here it looks like this:

BIMserver/BimServer/src/org/bimserver/geometry/GeometryRunner.java

Line 799 in 2942448

this.streamingGeometryGenerator.setTransformationMatrix(geometryInfo, totalTranformationMatrix);

[2.0, 0.0, 0.0, 0.0, 0.0, 4.0, 0.0, 0.0, 0.0, 0.0, 2.0, 0.0, 0.19500000000000098, 0.0, 0.0, 1.0]

Also now I get the incorrect scaling in BIMvie.ws again as well. Maybe I checked the wrong model earlier.

[hlg]

No, I get the properly resolved transformation in that place. It seems as if under certain conditions, the "Representations" attribute is not filled from the query and the first run to identify mapped geometry for reuse skips those. Subsequently, those representations are treated as ordinary geometry objects and the proper transformation is provided from the render engine.

BIMserver/BimServer/src/org/bimserver/geometry/StreamingGeometryGenerator.java

Lines 333 to 334 in 2942448

	Set<HashMapVirtualObject> representations = representation.getDirectListFeature(representationsFeature);
	if (representations != null) {

I also tried regenerating geometry instead of full checkin - same result. I was not able to reproduce this so far, but I see how it would go wrong.

[muren400]

Ok so after some digging I think I found the reason for the different bevaviour.

Our version of the BIMserver includes a different fix for #1342.
The preliminary fix mentioned in that isssue apparently does not eliminate all duplicate stackframes and as a result the representationsFeature is missing the directReferences of the returned object.

For some reason I never submitted a PR for this, but I can if you're interested.

You can check the commit here:
WeltWeitBau@85355ce