Latest Contributions by RobBever

Is there any hope of ever having a way to create 3D models in memory without using model files? I have lots of use cases for that, to the point where I rigged up a way to automatically build different colored .obj/.mtl files so they can be loaded in. But since I can't use a local Uri in memory, I have to write all of them to disk and load them that way. Supporting a Uri to load data from memory and from project resources would be a great improvement, but even better would be some way for me to define a model in memory with the ArcGIS engine API, since that's what I really want to do. ... View more

I'm sure it's related. I haven't found any model format where the origin point is honored. I tried lots of formats, .obj, .dae, .fbx, etc. Is there any model format where the origin is actually used when the anchor point is set to Origin? Even if it isn't the most convenient format like .obj, I might be able to work with it. Also, would it be possible to load models from memory or from project resources? It's a real pain to have to write a model file out to disk just so the engine can read it back in again. Uris can do references to project resources or memory, but the ArcGIS engine doesn't support Uris of that kind, even though it takes in a Uri to read the model. The way the anchoring works makes it impossible to know where anything will be anchored. At best I've had to rig up prefab models that I can dynamically modify where I've been able to trick the engine into anchoring where I wanted. If the model was, say, a building or a tank, there's no way to work with the unknown averaging algorithm in play. Anything that isn't symmetrical gets a set of anchor points that are, from the user's perspective, basically random and which he has no control over. I've had users ask me to put an RF pattern 3D model into the scene, or the scan area of a camera, and I can't do it, because it would be asymmetrical, and while I can generate the model, I can't anchor it where it needs to be. ... View more

Tried this in 200.0.0 and the performance is much worse than 100.6.0. The Windows Game Bar stuff shows an FPS readout. When rotating the Line of Sight demo in 100.6.0 earlier, I got around 10-12 FPS consistently, while it was loading and when it was finished loading. (This is on a laptop, not a powerhouse.) I ran the same in 200.0.0 right afterward, and the FPS was comparable while loading and then dropped to a consistent 6-7 FPS after everything was loaded. I observed this years ago when I tried to upgrade past 100.6.0. The 3D performance was significantly degraded in my application as well, and I had to stick with the old version. Is there any plan to fix this? It's easily visible in your own demo application. Please just revert to 100.6.0 in your demo app and run one of the complex demos like Line of Sight, and then run the same in 200.0.0 and see that the performance was much better previously. I use the 3D display for my application, and the performance in the later versions isn't good enough for me to work with. I hope that you'll make this a priority to fix. ... View more

Here's an example of the problem. I modified my CubeEdge.obj file to have one highest point. So when I do Top as my SceneSymbolAnchorPosition, it looks like this: So I can't control where the anchor point will be. The Y value is set to the max Y value, but for the X and Z values the engine is doing some kind of average of the other points, and not using the topmost point as the actual anchor point. That means I have no direct control of where the anchor point actually is, since Origin doesn't respect the model's origin and is just Bottom. I really hope you can make Origin respect the origin point of the model file. That would solve most of the problems I have with this. ... View more

Hey Michael, I didn't get a chance to test out the preview. Is the stuff from the preview in 200.0? Looking at this in the latest 200.0, it seems the behavior has changed, which is mostly good, but I still don't see how I can use this consistently. This is better in that the top and bottom stay attached to the point now in DIPS mode: But the origin point is still not respected, which makes it basically impossible to put a non-symmetrical model where I want it, unless your algorithm happens to pick the center I want. This is a cube from a .obj file where the origin is in the center. The sphere is centered on the anchor point, and the SceneSymbolAnchorPositions are, from left to right, Center, Origin, Bottom, Top: This is a cube where the origin is at one of the corners, same deal, SceneSymbolAnchorPositions are, from left to right, Center, Origin, Bottom, Top: Here's an arrow model: So it's not centered w.r.t. the front to the back, and I can't use the origin to set the center point, so I'm back to being stuck because I don't know what algorithm you use to decide what the "center," "top" and "bottom" of the shape are, and Origin seems to be the same as Bottom. Even if I orient my model vertically, I still don't know how Bottom decides the anchor point from the model, so I'm not sure if I can get it to anchor where I want. For example, the arrow model has multiple points that would be at the lowest Y value; does it average them? If I make one point the very lowest point, will it consistently pick that point as the anchor point, or will it average it against other points? Is there any intention to make the Origin SceneSymbolAnchorPosition use the actual origin point from the model? Origin would be by far the most useful of the four modes, and the only one that guarantees me that I can put the model where I want it. ... View more

Sorry I missed your last message. I'd be interested in helping to test if it's not too involved, for example if you have a beta version of your samples application I tested this in the latest ArcGISRuntime samples in version 100.13 and the problem is the same. I retried all the files I showed previously, and every problem I discussed is still here. To quickly summarize (these are new examples from 100.13): 1. In Dips mode, nothing is anchored correctly. If you zoom in far enough, the model will always diverge from the actual point in some way. Here you see a Dips cube and a Meters sphere (anchor point is Center). The cube is sticking out the bottom of the sphere when it should be centered in the same place as the sphere. Here, the anchor point is Bottom, and you can clearly see that the model is not attached to the anchor point, which is given the same point as the Meters-based sphere: Here it's anchored to Top, and you can see daylight between the actual anchor point and the model: 2. Origin and Bottom appear to be nearly the same in Dips and Meters modes. I have seen them diverge, but rarely, and Origin has nothing to do with the origin of the model under any circumstances in any model format I've tried (and I tried a lot of formats). Here's a cube which is centered at 0,0,0 in Dips: And here it is in Meters: Both are incorrect in the same way. No point of origin is respected in any of the tests I did, moving the origin around a cube model. The Origin anchor point definitely does not anchor at the origin, it's still similar to or the same as Bottom, and the Center is still using an algorithm that's difficult to figure out. It seems to be maybe a weighted average of face area, I think. Vertices that aren't part of a face are not considered, I know that much. 3. Much less important, but I can't do your SimpleMarkerSceneSymbols in Dips mode. It would be very nice to be able to create a cone, sphere or cube in Dips mode. I assume this is possible but was missed in the API or something. Generally speaking the SimpleMarkerSceneSymbols make sense in terms of how they work (though I'm still confused about how Center is calculated). Here I plotted them in a similar way to the other models: Their anchor points seem to work as desired, generally speaking. Their Origin anchor points clearly work differently than all other loaded models, since they seem to actually be in the center of the models, and I haven't seen any other case where I could get that to happen. If I could get the same behavior for loaded models I'd be very happy, though I can't test their behavior in Dips mode. 4. Minor issue, I wish I could load models from a pack Uri. If it doesn't work for some reason, that's fine, it's just strange using Uris but not being able to do it the same as I would in XAML to load a local resource file, I have to write the file to disk and load it that way.   The runtime performance of 3D appears to be better in 100.13, but from a quick test it still seemed slower than in 100.6. I haven't benchmarked it though, and it definitely appears to be improved from other versions between 100.6 and 100.13. I just realized I could orient my meshes vertically, since Top and Bottom are more consistent in their behavior, so I'm going to go try that, but it isn't a real solution for models that aren't symmetrical (since I don't know how the other axes are averaged), and even in Top and Bottom mode for Dips, the models don't really stay attached to the anchor point. Let me know if you may be able to fix this or if you can at least tell me how the centers are calculated. I can give you the sample code and models I used to do this testing if it would help you, it's similar to what I already provided in this thread. ... View more

Almost a year later and this remains a problem. I tested 100.11 and it also is far, far slower in 3D than 100.7, like 100.8, 100.9, and 100.10. This tends to indicate that whatever the problem is, it hasn't been fixed. Did you verify my results? Is there any possibility of getting the performance in 3D in future releases back to where it was in 100.7? I'm basically stuck not upgrading until the performance problems are resolved. Thanks. ... View more

Could I please get an update about this? I'd really like to know why the behavior is the way it is. It's very difficult to work with currently because of the inconsistency. I did quite a bit of work to demonstrate the issue clearly. It would help to know if you see the problem and if there's any possibility it could be changed or at least explained more clearly. For example, when it says "center," what does that mean? What algorithm does it use to determine where the "center" is, if it's not using the origin point? What algorithm does it use to determine "top"? Is "top" the highest point? What if there are lots of points at the top? Does it average the X and Z values, do some kind of weighted average, or something else? Any more info I could get would be great. I really tried to demonstrate the issue as clearly as I could, and I think I showed that there was a problem. Thanks. ... View more

I found cubes in .blend, .ply, .stl, and .dxf formats and they all behaved pretty much the same w.r.t. anchor points. Interesting that they still load fine despite being deprecated. ... View more

I found a .3ds cube. Here's that with my test setup: I got the cube from here: https://www.cgtrader.com/free-3d-print-models/games-toys/puzzle/rubiks-cube So it seems like all the different formats behave the same with respect to the anchor points, although I can't verify where the origin was for the .fbx and .3ds ones. Another test I did was to try adding a couple of points to the .dae cube, one at the center of the bottom, and one way lower but in the center, to see what that would look like. Here's what the result was with my test setup: Basically that's just a cube going from (0, 0, 0) to (1, 1, 1) with two additional points, (0.5, 0.5, 0) and (0.5, 0.5, -22), and an additional face going between the last two points. The cube looks squished because I gave all 3 dimensions the same size value, I expect that. This actually looks more reasonable; Meters/Origin looks good, other than the fact that the bottom corner of the cube is at the origin, so it shouldn't be centered where the sphere is, and Pixels/Origin looks similar and doesn't move around the sphere when you zoom as well. I'm interested in Pixels/Bottom though. I would expect it to have the bottom of the spike at the center of the sphere at all times, but it doesn't. In that picture you can see the lowest point is below the anchor point, but then if you zoom in you get this: So now I'm just confused about how any of these anchor points work. Any insights you can give would be very helpful. Thanks. ... View more

I found a .fbx cube as well. I don't know what the origin is for this cube, but the result is the same: Here's Dips/Center, still off-center when you zoom in: I got the example .fbx file here: https://www.cgtrader.com/free-3d-models/various/various-models/simple-cube-1x1 ... View more

I really want this to work, so I went ahead and made an equivalent .dae file cube and ran my test again. That's another format I could work with. The cube has the same vertices as before, it's a 2-unit cube centered at the origin. So the corners are (-1, 1, 1), (1, 1, 1), (1, 1, -1), (-1, 1, -1), (-1, -1, 1), (1, -1, 1), (1, -1, -1), (-1, -1, -1). It appears to me that the results are the same. Here I've added Bottom to my list to see how that anchor point compares, and I've added text labels for the different types of anchoring and symbol size units, though you can't typically see them for the Dips-sized ones. The text labels' bottom left corner represent the center point. These results for .dae files appear to be the same as the results for .obj files. It seems that whatever the issue is, it's consistent. Note again that this is with the test app 100.10.0, I've attached my updated code for that as well. Simply place cube3.dae in your Output\WPF\<build type>\Resources folder to run this code (rename .xaml.cs.txt to .xaml.cs, of course). Meters/Center continues to work properly, and Meters/Bottom and Pixels/Bottom seem fine, but all the others are off from what you'd expect. Meters/Origin does not appear correct; the origin is in the center of the cube, but Origin and Bottom appear identical: Dips/Center once again doesn't seem to actually center. Note that the bottom left of the text represents the anchor point: Here again, the sphere is centered on the anchor point, this is still Dips/Center: If I understand the anchor points correctly, the cube should go into the center of the sphere, it shouldn't ever be below it when zooming in with this anchor point. Pixels/Origin and Pixels/Bottom appear identical: Surely with the origin being in the center of the cube, you'd expect that they'd be different. I also tried a cube .dae file where the center was (0, -1, 0), such that all the points were at or below a Y value of 0, and the result was the same. I assume if I had to I could split my model in half and use Bottom on the top half and Top on the bottom half to create one model that's centered at its origin point, but I can't necessarily do that with prefab models, or at least I don't know how. I tried another test where I had the origin point at (0, 0, 0) and had the vertices be (0, 0, 0), (2, 0, 0), (0, 2, 0), (0, 0, 2) etc., basically the same cube shifted by (1, 1, 1) so its origin is at the center. Here's what that looks like: It looks exactly the same. The origin of the model appears to not affect how the anchor points work. It appears that Bottom means Bottom Center, although I don't know how the center point is calculated. I would have guessed it would be more like Bottom Origin. This also means that I can't directly control where the Top and Bottom anchor points are either, since I don't know the calculation of the center point. (Is it calculated only with respect to the points on the plane with the bottom? Or is it the center point of the whole object in X and Z?) From what I was able to find, supported formats are .obj, .dae, .3ds, and .fbx. So far the anchor points work the same in the first two, but they work as you'd expect with your prebuilt shapes from SimpleMarkerSceneSymbol. Is there any way to get the same behavior you get with SimpleMarkerSceneSymbol shapes for my 3D models?   Oops, it won't let me attach the .dae file, here it is, cube3.dae: <?xml version="1.0" encoding="UTF-8" standalone="no" ?> <COLLADA xmlns="http://www.collada.org/2005/11/COLLADASchema" version="1.4.1"> <asset> <contributor> <authoring_tool>Google SketchUp 8.0.11752</authoring_tool> </contributor> <created>2012-04-27T21:07:03Z</created> <modified>2012-04-27T21:07:03Z</modified> <unit meter="0.02539999969303608" name="inch" /> <up_axis>Z_UP</up_axis> </asset> <library_visual_scenes> <visual_scene id="ID1"> <node name="SketchUp"> <node id="ID2" name="instance_0"> <matrix>1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1</matrix> <instance_node url="#ID3" /> </node> <!-- <node id="ID28" name="instance_1"> --> <!-- <matrix>1 0 0 118.1102362204724 0 1 0 118.1102362204724 0 0 1 0 0 0 0 1</matrix> --> <!-- <instance_node url="#ID3" /> --> <!-- </node> --> <!-- <node id="ID29" name="instance_2"> --> <!-- <matrix>1 0 0 118.1102362204724 0 1 0 -1.4210854715202e-014 0 0 1 0 0 0 0 1</matrix> --> <!-- <instance_node url="#ID3" /> --> <!-- </node> --> </node> </visual_scene> </library_visual_scenes> <library_nodes> <node id="ID3" name="cube_component"> <instance_geometry url="#ID4"> <bind_material> <technique_common> <instance_material symbol="Material2" target="#ID6"> <bind_vertex_input semantic="UVSET0" input_semantic="TEXCOORD" input_set="0" /> </instance_material> </technique_common> </bind_material> </instance_geometry> </node> </library_nodes> <library_geometries> <geometry id="ID4"> <mesh> <source id="ID7"> <float_array id="ID10" count="24"> -1 1 -1 1 1 -1 1 1 1 -1 1 1 -1 -1 -1 1 -1 -1 1 -1 1 -1 -1 1 </float_array> <technique_common> <accessor count="8" source="#ID10" stride="3"> <param name="X" type="float" /> <param name="Y" type="float" /> <param name="Z" type="float" /> </accessor> </technique_common> </source> <source id="ID8"> <float_array id="ID11" count="48">0 0 -1 0 0 -1 0 0 -1 0 0 -1 0 1 0 0 1 0 0 1 0 0 1 0 1 0 0 1 0 0 1 0 0 1 0 0 0 0 1 0 0 1 0 0 1 0 0 1</float_array> <technique_common> <accessor count="16" source="#ID11" stride="3"> <param name="X" type="float" /> <param name="Y" type="float" /> <param name="Z" type="float" /> </accessor> </technique_common> </source> <vertices id="ID9"> <input semantic="POSITION" source="#ID7" /> <input semantic="NORMAL" source="#ID8" /> </vertices> <!-- <triangles count="8" material="Material2"> --> <!-- <input offset="0" semantic="VERTEX" source="#ID9" /> --> <!-- <p>0 1 2 1 0 3 4 5 6 5 4 7 8 9 10 9 8 11 12 13 14 13 12 15</p> --> <!-- </triangles> --> <polylist count="6" material="Material2"> <input semantic="VERTEX" source="#ID9" offset="0" /> <vcount>4 4 4 4 4 4</vcount> <p>0 3 2 1 0 1 5 4 1 2 6 5 3 7 6 2 0 4 7 3 4 5 6 7</p> </polylist> </mesh> </geometry> </library_geometries> <library_materials> <material id="ID6" name="material"> <instance_effect url="#ID5" /> </material> <material id="ID13" name="Color_005_"> <instance_effect url="#ID14" /> </material> <material id="ID21" name="Color_A06_"> <instance_effect url="#ID22" /> </material> </library_materials> <library_effects> <effect id="ID5"> <profile_COMMON> <technique sid="COMMON"> <lambert> <diffuse> <color>1 1 1 1</color> </diffuse> </lambert> </technique> </profile_COMMON> </effect> <effect id="ID14"> <profile_COMMON> <technique sid="COMMON"> <lambert> <diffuse> <color>0.4470588235294118 0.4470588235294118 0.4470588235294118 1</color> </diffuse> </lambert> </technique> </profile_COMMON> </effect> <effect id="ID22"> <profile_COMMON> <technique sid="COMMON"> <lambert> <diffuse> <color>0.8 0 0 1</color> </diffuse> </lambert> </technique> </profile_COMMON> </effect> </library_effects> <scene> <instance_visual_scene url="#ID1" /> </scene> </COLLADA> ... View more

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. ... View more

I've been using packages.config, yes. I knew there was a new way for .NET Core, but I didn't realize they made that available for .NET Framework as well. Thanks for pointing that out, looks like it's not too hard to switch. I'll definitely look at that. I don't like to use relative paths for the package directory (my project needs it to be linked to "$(SolutionDir)\packages"), so I'll have to see how that gets along with package references. Please see my results in 100.10.0 once I was able to build and run the example app, which I posted to this thread. The AnchorPosition issue is the same, the behavior is identical. The 3D framerate is also still much lower than in 100.6.0, see my example videos. ... View more