Obj File Model Not Anchoring Properly

04-01-2021 01:52 PM
New Contributor III

Using engine v100.6.0, since as far as I know the 3D rendering speed problem introduced in 100.7.0 and worse in 100.8.0 is not yet resolved.

I have a simple .obj file. I simplified it as much as possible to determine why I was getting the behavior I was getting. Here's the .obj file, I'll also attach:


# Cube.obj

g Cube

v -1 1 -1
v 1 1 -1
v 1 1 1
v -1 1 1
v -1 -1 -1
v 1 -1 -1
v 1 -1 1
v -1 -1 1

f 1 4 3 2
f 1 2 6 5
f 2 3 7 6
f 4 8 7 3
f 1 5 8 4
f 5 6 7 8


So just a 2-unit cube centered at 0, 0, 0. I know there's a simple cube that can be generated; I'm just trying to understand the engine's behavior w.r.t. .obj files so I can make my own .obj files dynamically later.

I'm trying to anchor it at the center. This does not appear to work, either by AnchorPositioner.Center or AnchorPosition.Origin.

It seems clear that both Center and Origin should work the same. Here I've added this .obj file to my scene with its AnchorPosition set to Origin; I've also added a text label "0" at the given point and also I have a cone with AnchorPosition.Top which has its top set to the same point. In this case, the SymbolSizeUnits are set to Meters, and width == height == depth.


Obviously this is not correct. The origin is in the center of the cube. Here I'll try AnchorPosition.Center:


This looks right, although I've had problems with this when the points aren't as regular as this. So that looks correct.

Now we'll try SymbolSizeUnits.Dips, AnchorPosition.Center:


Now we're anchoring to the bottom again for some reason. This behavior is different for SymbolSizeUnits.Dips vs. SymbolSizeUnits.Meters, but shouldn't be.

Now I'll try SymbolSizeUnits.Meters, AnchorPosition.Origin:



This is anchored to the bottom too. It doesn't appear that I can do anything to actually anchor at the center in SymbolSizeUnits.Dips mode. It always appears to use AnchorPosition.Bottom instead.

Is there anything I can do differently to be able to anchor at the center?

It would be ideal if I could use AnchorPosition.Origin, since I can control that, but it doesn't appear to work in any of these cases. It appears to replace Origin with Bottom. Perhaps internally it translates .obj vertices so the bottom is placed at a y value of 0?

Also, can you describe the algorithm used to determine the centroid of the object? I was creating another object and it wasn't at all clear where the centroid was considered to be, and it was causing it to rotate the model away from the point I wanted it to center at.

I tried adding additional unused vertices to "balance" it so the center would be the right point, but it was unsuccessful.

Tags (3)
0 Kudos
22 Replies
New Contributor III

I've modified your Scene Symbols example to demonstrate the issue. Simply place my Cube.obj in the Resources folder when you execute the example app to test.

Here I've added a sphere using SimpleMarkerSceneSymbol in four locations, and added a ModelSceneSymbol of my cube .obj file in each of the four combinations above (meters/center, meters/origin, dips/center, dips/origin). I've attached the modified source file.

You can see that despite the center and the origin of the Cube.obj being the same, the behavior is not consistent:


Again, the order in this picture is meters/center, meters/origin, dips/center, dips/origin.

The only one that acts correctly is meters/center.

Meters/origin and dips/origin anchor to Bottom instead.

Dips/center however is an odd case. I've attached a video showing the strange behavior. When I zoom in, it moves off the center point and down, probably related to where the camera is. I can't imagine it represents the intended behavior.

Please let me know if there's a way to use AnchorPosition.Origin and have it work properly with .obj files. I'd really like to be able to anchor in the right place; otherwise it makes 3D models inaccurate to use.

Thanks for your help.

0 Kudos
Esri Frequent Contributor

We resolved an issue in 100.8 related to model symbol anchors, are you able to update to 100.8 or later and confirm if this issue is still reproducible? 

Also, the performance issue you mentioned that is not yet resolved - have you tested the current release 100.10?  


0 Kudos
New Contributor III

I haven't tested on 100.10. It's a bit of a hassle to update my main code.

I can test with your example app -- versions post-100.6.0 had noticeably degraded 3D performance even in the sample app, for example the viewshed city examples. I discussed this in a thread previously, but I didn't hear back if it was reproduceable on your end or if there was any intention to fix. I had a coworker try it and I tried on my two machines and it was consistently a much lower framerate on the newer versions. Versions 100.7.0 and 100.8.0 are unusable for me as a result.

Has the example app been updated for 100.10.0 yet? I pulled earlier today. It built but wouldn't run (missing dependencies) and it appeared to still be building for 100.9.0.



0 Kudos
Esri Frequent Contributor

Regarding building the samples - one of the team was just able to confirm that performing a Clean and Rebuild should resolve this issue. 

0 Kudos
New Contributor III

Sorry, I didn't see this until this morning.

I figured out the problem. It was twofold -- first, it builds in Visual Studio 2019 but not in Visual Studio 2017. Up to 100.8.0 at least builds in Visual Studio 2017, or maybe I have different components installed in the different versions.

Second, I assumed the master branch was the right one. I didn't realize there was a main branch. The master branch is still on 100.9.0, but the main branch is up to 100.10.0.

Once I switched to Visual Studio 2019 and the main branch it worked.

Esri Frequent Contributor

Thanks for confirming. `Main` branch is the default, but the original `master` branch was still accessible while we updated some CI internal processes. We have now removed the latter branch. Apologies for the mix-up.

0 Kudos
New Contributor III

No problem, thanks for explaining. I had just given up on getting it to build.

So now I've confirmed that my modified SceneSymbol.xaml.cs attached above builds as-is in the latest example app and the anchoring works the same as in 100.6.0, and does not appear to be as intended for .obj files. You can build it yourself and take a look.

0 Kudos
New Contributor III

This is all WPF, if I didn't say so.

0 Kudos
Esri Frequent Contributor


The main branch is updated for 100.10 - you should be able to pull and build that - if you can't we need to fix that.

Also the viewer in the Store has been updated to 100.10 (you might at least be able to use this for easily testing performance). 

Apologies you didn't see much follow-up on the original performance-related thread - it did spark an extensive internal discussion and investigation right down into our DirectX rendering code. There wasn't any obvious candidate improvement we could make there, but in our upcoming 100.11 release we do plan to include an enhancement to our underlying use of DirectX and it is certainly worthwhile you re-testing with that version. We also still have an active research project underway involving profiling the performance of rendering calls.