Upgrade viewer specific APIs to v5

[sebjf]

Description

Once the viewer is V5 ready, we should move over some of the APIs that it solely uses to V5 style. These include at least some model and textures calls.

Goals

• There are no v4 style APIs without a v5 API equivalent that the viewer can use

Tasks

• TBD

Related Resources

Unity Issue: https://github.com/3drepo/3drepounity/pull/522

[FJThiel]

For future reference, APIs that the viewer currently uses and potential V5 equivalents.

Purpose	Format	File	Line	Version	Notes	V5 Equivalent	V5 Notes
Get model   properties	/<teamspace>/<modelID>/revision/<revision>/modelProperties.json	BundleLoader	498	V4		Maybe	No direct   equivalent for model properties, but there is one for model settings that can   be used for either individual containers and federations. Will need to   investigate closer what information is actually used by the viewer and what   is contained in the v5 APIs
Get repo assets	/<teamspace>/<modelID>/revision/<revision>/repoAssets.json	BundleLoader	582	V4?	Found only API for   a unityAssets.json. Likely the correct one just for models with repobundles	No	Not apparent to me   what could serve as an V5 equivalent
Get metadata	/<teamspace>/<modelID>/revision/<revision>/assetsMeta	BundleLoader	697	V4?	Cannot find direct   equivalent in documentation that would take assetsMeta, though there is a   meta/all.json that looks similar.	No	No GET access for   metadata
Get group objects	/<teamspace>/<containerID>/groups/<groupID>	ModelController	1587	V4?	Cannot find an   exact match. There is a version that could fit, but it has an additional   sections for the revision in it which is lacking in the viewer version	No	No GET access for   groups. Only a POST that appears as if it returns a list of group information   after provided with IDs to lookup.
Loading model   settings	/<teamspace>/<modelID>.json	ModelController	3337	V4		Yes	Access for model   settings for containers, federations, and drawings exists
Fetching group   (for the views)	/<teamspace>/<modelID>/revision/<revision>/groups/<groupID>	ViewsManager	226	V4		No	No GET access for   groups. Only a POST that appears as if it returns a list of group information   after provided with IDs to lookup.
Get view info	/<teamspace>/<modelID>/viewpoints/<viewID>	ViewsManager	232	V4		Partially	There is an API to   get a list of views but apparently none to get the info of a particular view
Get map texture	/<teamspace>/<modelID>/maps/here/<currentZoomLevel>/<nx>/<ny>.png	HereMapCreator	86	V4		No
Get map texture	/<teamspace>/<modelID>/maps/hereaerial/<currentZoomLevel>/<nx>/<ny>.png	HereAerialMapCreator	41	V4		No
Get map texture	/<teamspace>/<modelID>/maps/herehybrid/<currentZoomLevel>/<nx>/<ny>.png	HereHybridMapCreator	41	V4		No
Get map texture	/<teamspace>/<modelID>/maps/herepoi/<currentZoomLevel>/<nx>/<ny>.png	HerePOIMapCreator	41	V4		No
Get map texture	/<teamspace>/<modelID>/maps/heregrey/<currentZoomLevel>/<nx>/<ny>.png	HereStreetMapCreator	41	V4		No
Get map texture	/<teamspace>/<modelID>/maps/hereterrain/<currentZoomLevel>/<nx>/<ny>.png	HereTerrainMapCreator	41	V4		No
Get map texture	/<teamspace>/<modelID>/maps/heretollzone/<currentZoomLevel>/<nx>/<ny>.png	HereTollZoneMapCreator	41	V4		No
Get map texture	/<teamspace>/<modelID>/maps/heretrafficflow/<currentZoomLevel>/<nx>/<ny>.png	HereTrafficFlowMapCreator	43	V4		No
Get map texture	/<teamspace>/<modelID>/maps/heretraffic/<currentZoomLevel>/<nx>/<ny>.png	HereTrafficMapCreator	41	V4		No
Get map texture	/<teamspace>/<modelID>/maps/heregreytransit/<currentZoomLevel>/<nx>/<ny>.png	HereTransitMapCreator	41	V4		No
Get map texture	/<teamspace>/<modelID>/maps/heretruckoverlay/<currentZoomLevel>/<nx>/<ny>.png	HereTruckOverlayMapCreator	43	V4		No
Get map texture	/<teamspace>/<modelID>/maps/osm/<currentZoomLevel>/<nx>/<ny>.png	OSMMapCreator	86	V4		No
Get subobject	/<teamspace>/<modelID>/meshes/<meshID>	PhysicsService	181	V4?	No equivalent   found in the docs	No
Get Unity Asset   Bundle	/<teamspace>/<modelID>/<bundleID>.unity3d	BundleLoader	205	V4	The actual URL   appears not to be assembled in the viewer but instead has come from the asset   list retrieved earlier	No
Get Repo Asset   Bundle	/<teamspace>/<modelID>/<bundleID>.repobundle	BundleLoader	209	V4	The actual URL   appears not to be assembled in the viewer but instead has come from the asset   list retrieved earlier.     Not listed in docs	No
Load Asset Maps   for Container	/<teamspace>/<containerID>/revision/<revisionID>/supermeshes.json.mpc	BundleLoader	386	V4?	No mention in   docs.	No
Load Asset Maps   for Federation	/<teamspace>/<modelID>/revision/master/head/supermeshes.json.mpc	BundleLoader	432	V4?	Pretty much the   same call as the one directly above, but with fixed revision, since   Federations are not allowed to have revisions.     No mention in   docs.	No
Get texture	/<teamspace>/<containerID>/<textureID>.texture	TextureManager	143	V4?	URL is actually   assembled in the textureHelper class.     Not mentioned in   the docs	No

[FJThiel]

@carmenfan
Are we still using model properties?

While mocking the test environment for my new route I noticed a few peculiarities in my local deployment that I use to check whether all is mocked as it would be in production:

• My ref nodes in the scene collection do not appear to have a _rid field, as the route expects.
• My stashes don't have the modelProperties.json files

I tried a Postman request via the v4 API against my local and it does return with a 200, but the json has only its basic structure without any file content.
Are we just keeping this route around for legacy reasons or do we want to axe it in v5?

[carmenfan]

Are we still using model properties?

As far as I'm aware, model properties is still being used/called for the sake of the viewer knowing what to hide by default when we present the model. Unless it has another way of finding out this information (i don't think there is, at least not easily) I don't think it can be axed.

My ref nodes in the scene collection do not appear to have a _rid field, as the route expects.

again, i don't think we've axed it, I just edited a federation and the new records had rid in it. this was done in staging, which should have the latest version fo bouncer (5.13.x)

I'm suspecting you have a dodgy bouncer build 🤔

[carmenfan]

@FJThiel just sanity checked, it's definitely still setting the _rid
https://github.com/3drepo/3drepobouncer/blob/staging/client/src/functions.cpp#L203

https://github.com/3drepo/3drepobouncer/blob/staging/bouncer/src/repo/core/model/bson/repo_node_reference.h
https://github.com/3drepo/3drepobouncer/blob/staging/bouncer/src/repo/core/model/bson/repo_node_reference.cpp#L65

[FJThiel]

@carmenfan
Thanks for checking! Though it means that I now can't trust my local DB anymore...

Is there a way for me to connect myself to the mongo DB on staging to get a more accurate picture?

[carmenfan]

if you ask @nkuberaf he can probably hook you up with access

[FJThiel]

@sebjf @carmenfan

Currently, the viewer does not receive information whether the model is container or federation so it gets this through a call to the v4 API for the model settings.

The new v5 API call for model settings however requires that knowledge already since it has container and federation paths. It also requires the project ID, which is also not passed into the viewer. I would suggest to expand the info that the viewer receives through the initial LoadModel call from the frontend by these two attributes as part of this issue and Viewer #566.

[sebjf]

Hi @FJThiel, yes unity-utils should be updated to take this from now on. The only question is whether we need a shim there for embedded viewers @carmenfan?

(In which case, I'd say unity-util should do it, i.e. figure out which it is and pass the appropriate arguments to unity)

[carmenfan]

yes do the change on unity util and we can get someone from frontend to adjust the call @sanmont3drepo fyi

As for the workaround, i'd say let's skip for now, I'll double check to see if there's anyone other than cbim using the embedded viewer

[FJThiel]

Okidoki. Just that I understand this correctly, you want me to just change the method in unity util and let the frontend team figure out how to get project and fed info there?

Edit: If I am already touching that method, would you mind if I also throw out the branch parameter? It is still in there but not even passed on to Unity anymore.

Edit 2: Also, I would like to take the opportunity to unify the terms we use there for teamspace. In the space of this one function, we call it teamspace, database, and account.

[sebjf]

you want me to just change the method in unity util and let the frontend team figure out how to get project and fed info there?

yes

throw out the branch parameter

yes

take the opportunity to unify the terms we use there for teamspace.

Internally for sure, for public APIs lets wait and see who else is using the embedded viewer.