Actually I want to place my 3D pipes on their real-world counter parts, but I have some problems with the positioning and the scaling, or I just don't understand the documentation on this topic.

See my attached images (Scaling_Issue_02.png and Scaling_Issue_01.png), for both images I had totally different Values for the various scaling parameters, but for me the sizes of the pipes looks always the same.

What I not understand is, why I have to scale my pipes, for example by the factor of 0.1 or something else. It feels a little bit arbitrary and I have no clue how to find the right values to get my real-world-scaling pipes.

So what is the best way to scale my pipes correctly, so that they match with their real-world counter parts?

Another question is the positioning. Where are the 3D-Models anchored when I give them a location? Is it the middle of the 3D-Model or the origin of the 3D-Model, which I specifiy for example with Blender? So in my case I use always the location where the origin of my Pipes are, but because of the scaling issue, I have trouble to validate the correct positioning of my Pipes.

I have also attached two 3D-Models which I'm using (geom_8.wt3, geom_0.wt3).

Robert Gregat

Normally I have no idea how big my pipe models are, but it should have the same size in AR then the real pipe, so that they should overlap.

By the way the documentation says

For drawables attached to AR.GeoObject, 1 SDU is defined as the screen-size of an object which is exactly 1 meter high and located 10 meters away from the viewer.

but what does that mean and how can i alter this value for a AR.Model Object to fullfill my needs?

Regards

Robert

R

Robert Gregat

said
6 months ago

Is it actually possible to disable the scaling in a way it is currently working? My models have the same dimension then their real life counter parts (in meters). In theory they should overlap perfectly.

Wikitude Technical Support

said
6 months ago

Hello Robert,

let's see if I can answer some of the questions you have asked:

Firstly, in regards to the scaling factors; I believe they are only applied to 2D drawables. I don't believe they are considered for 3D models. Admittedly, the documentation does not reflect that and even I had to check the code for myself and run some experiments to actually find out.

The intention of these scaling factors was to have some control over how the scaling works. This makes some morse sense when one considers that Wikitude's initial product was a sightseeing-type app. Images were overlaid and marked significant locations in the camera view. To not have very distant image overlays be unrecognisably small, or close image overlays be unreasonably big, the scaling could be clamped using these parameters. As I believe they do not apply to your use case of using 3D models, I believe we skip the details for now. Besides, they are explained quite well on this page.

Secondly, about SDUs for AR.GeoObjects; they simply mean, at least to my understanding, that whatever size your 3D model has, it will actually have at a distance of 10 meters. Since the aforementioned scaling factors are not applied for 3D models, I believe you can entirely neglect the concept.

Lastly, and most importantly, what you are trying to do is not really feasible using GPS location. The accuracy of GPS is about 5-10 meters, at best. It's therefore quite impossible to align objects to a degree of accuracy that would make the real world object overlap with the virtual object.

In any case, if you want to try anyway, I believe DBS and SDUs are concepts you do not need to concern yourself about. You would just need to make sure that your 3D model matches the real world object in size. To do that, you would likely need to adjust the scale property of the AR.Model object. The model should adjust it's size according to the actual distance of the device to the GPS location of the model.

- Daniel

1 person likes this

R

Robert Gregat

said
6 months ago

Hi Daniel,

thank you very much for this detailed explaination!

What you mentioned about DBS and SDU for 3D-Objects is something I also discovered. I implemented some range slider to change the values for AR.context.scene.maxScalingDistance, AR.context.scene.minScalingDistance and AR.context.scene.scalingFactor. I actually didn't noticed any changes for the size of my 3D-Models for different values of these settings.

I also totally agree with you that the accuracy of the internal smartphones GNSS-Receiver is not good enough. Google has some nice tricks to get in a city better results (Wifi and cell tower support), but I guess thats not common for all areas in the world. I also implemented a Kalman-Filter to smooth out spikes, but yeah a total overlay will actually not be possible with consumer grade hardware. Possible I have to connect an external low-cost GNSS-Receiver over Bluetooth with a good antenna to my Smartphone, to get better results.

About the scaling of a 3D-Model. currently I use the factor of 0.1 and the objects are still to big. How can i actually determine the right scaling value? is there any rule I can adopt? I created my 3D-Models in meter, so 1 Unit in Blender should be 1 Meter.

And lastly, is the anchor point for a GPS-Coordinate is always the origin of a 3D-Model?

Best Regards

Robert

Wikitude Technical Support

said
6 months ago

Hi Robert,

the Wikitude SDK will simply take whatever values are stored in the exported FBX file. So if a vertex is at position (1, 0, 0), it will be offset by 1 on the X-axis. For the case of a 3D model attached to a GeoObject that "1" should be 1 meter. For our tracking algorithms, it would be something different (this is where SDUs come into play).

Regarding Blender: setting the unit scale of the scene won't actually affect the size of the exported FBX file; the FBX file format does not, to my understanding, have the concept of a unit. So whatever vertex values your model has, be it meters, centimeters or inches, will result in the exact same model being exported.

Let's think this through for Blender's default scene. It has in it a cube with edge length of 2 (the vertices extending by 1 in each of the axes). If you export the default scene to FBX, you will have a cube the size of 2 meters for your use case. There is a caveat to be aware about, though. Exporting to FBX in ASCII format will behave as I have just described. Exporting to FBX in binary format will introduce a discrepancy in scale; namely 100 for whatever reason. To correct this, I suggest setting the exporting scale to 0.01 in that case.

I'm not sure where this discrepancy comes from, though. It could simply be Blender exporting differently, though. Or it could be a difference in the FBX file format version the Wikitude SDK is not prepared to handle yet.

Robert Gregat

said
6 months ago

Hey Daniel,

again thank you very much for this detailed explaination.

Currently I had no time to verify what you said about the binary FBX export. In Blender I use a modified version of a batch exporter for fbx and I have first to check if it use the binary version or the ascii version. I think it might be the binary version because that would explain why my 3d-objects are all to big in the AR-View. Next week I can give you further feedback about that.