Infrastructure: GEMSTEP Agent Rendering and Mirroring - [merged] #455

Closed benloh closed 1 year ago

In GitLab by @daveseah on Oct 4, 2020, 21:12

Merges gemsrv/tracker-ux-1 -> dev

This the first release of the GEM-STEP rendering system, which allows us for the first time to see Agents created from Agent Templates and jiggle-around running their own programs. While there is yet no provision in this code to actually modify these behaviors outside the development environment, this release does represent a giant step toward having a minimally functioning modeling tool when we combine it with the prototype UI. Woohoo!

WHAT TO SEE

The work is visible in APP_SRV, which is the server app framework that works with realtime graphics libraries. The installation process is the same as always: first pull the repo and switch to the dev branch, then issue these instructions while inside the gsgo directory:

npm ci
npm run bootstrap
npm run app           # this just runs the app_srv module

The APP_SRV runs on localhost, so open Chrome and browse to localhost and press return. There is no port number (e.g. :3000 as GEM_SRV uses) because we are serving the application on default web port 80.

You have the choice of running Generator or Tracker. Make a note of the IP ADDRESS that is reported in the terminal output when run npm run app, so you can browse to it from a remote machine on your LAN.

Here's what each test program does.

Generator

This code exercises the simulation engine (running in a browser for development purposes). It does the following operations:

Defines an Agent Template that does a "jittering" action under script control.
Instantiates 50 agent instances from the Agent Template.
Maps Agent instances into a DisplayList, 30 times a second, using the new SyncMap class. Because we have 50 agent instances, we have 50 corresponding DisplayObjects in the DisplayList.
Handles drag and drop of sprites, which also updates the underling Agent instance properties.
Renders the DisplayList locally which converts them to Sprites with another SyncMap instance.
Broadcasts the DisplayList to any remote that listens to the NET:DISPLAY_LIST message.

Tracker

This code does not running the simulation; it only renders the DisplayList that it is listening for.

Listens to the NET:DISPLAY_LIST message, provided by Generator, which fires the event 30 times a second.
On receipt of a new DisplayList, it maps the DisplayObjects to Sprites using the SyncMap class. It should handle the addition and removal of Sprites based
Reflects the state of dragged objects on the Generator app; showing how specific properties appearance-agnostic concepts are mapped unto specific visual representations. In other words, the DisplayObject format encodes states of objects ("selected", "captive", "indicated", "grouped") instead of implementation-specific details like "color".
Exercises the new AssetManager, which is the beginnings of our system to share resources across the entire network. It will eventually enable us to further compress our DisplayObject size by transmitting textureID numbers instead of long URLs.

You can run the Tracker on multiple devices on your LAN, and they will all update at the same time from the Generator. However, you currently can not run multiple instances of Generator because of ID collision; this will be fixed in a future version by using the unique socket address to differentiate different streams. Having this differentiation scheme is essential for implementing "FakeTrack" and "Annotations" from multiple devices, which is part of the upcoming "mobile device and multi device addressing" phase of development.

Also missing from this release is the ControlObject stream that can feed input (such as selections) back to the main simulation. This is also dependent on multi-device addressing. We have a fairly good idea of how we can implement this using existing communication methods; it's just a matter of designing a logical system to keep it all straight.

Other Notable Changes

From the developer perspective, there are several new features of note:

Typescript! - Our major object classes are now written in Typescript, which helps with object design by enforcing data structure typing across the project. Both the simulation and rendering modules use Typescript. After many years of ignoring this we finally have found a use case where it is more helpful than hinderance.
Improved APP_SRV Routing - In our most recent versions of STEP, we have had a problem preventing all modules from initializing and running even if they weren't being used. This is partly due to the way modern code bundlers work, but also due to the way we defined our React routes by importing each master component. In our new version of APP_SRV, we make use of a newer technique to lazy load each top-level React Component on demand, which not only cuts down on bundle size but prevents multiple app subsystems from running at the same time. For example, in earlier versions of STEP loading the Admin Interface also loaded the Simulation, which lay dormant in code and caused strange conflicts with the phasing system. This also helps low-powered devices like Chromebooks and older tablets by reducing both code size and unseen background execution.
Better SystemInit - Related to Improved Routing, all of our main routes are now defined in a pages directory, which are pointed-to in the SystemRoutes.js file as before. While the routes are not as "automatic" as it is in GEM_SRV, it conceptually maps in a similar way. It is now the responsibility of each main route to initialize the modules they need to operate in componentDidMount(). For example, the Gatherer app needs both the Simulation module and the Renderer module, so it imports modules/sim/api-sim and modules/renderer/api-render to auto-initialize each module and make it available. The Tracker app, by comparison, just needs modules/renderer/api-render.
Better URSYS SystemHooks - In the past, it was difficult to know when you could safely use the UR.SystemHook() call. If you did it in the wrong place, your PhaseHook would never fire because the event probably had already happened. This is the case when using SystemHook() inside React Components, or trying to connect to a phase that hadn't initialized yet due to the vagaries of module import order. Now, SystemHook() will queue your hook requests if the target PhaseMachine does not yet exist, and you can define them in at module load time. As each PhaseMachine is initialized, it checks the queue to see if there were any registration requests and processes them...problem solved!
Restored URSYS Network Calls - In earlier versions of the GEM-STEP codebase, the URSYS communication module was incompletely ported from our previous version, so cross-network message calls were not functional. To be able to test Generator and Tracker together, we had to restore this functionality so it is back. You can now safely define and call messages on other remotes, and the operations of this feature (one of the trickiest bits of code in all of STEP) has been blueprinted. There are a few new semantics from previous versions, most notably the formalization of channels such a NET: and LOCAL:. This will help us manage multi-device traffic in the future without introducing another addressing mechanism just be creating a new channel name. This convention will eliminate the LocalCall(), LocalSignal(), LocalPublish() and NetCall(), NetSignal(), and NetPublish() methods in favor of just Call(), Signal(), and Publish(). This also applies to the subscriber side's LocalSubscribe() and NetSubscribe(). We can infer the intended destination of the message now through channel semantics. On a related note, we will be renaming Publish to Send, and Subscribe to Receive to better reflect their actual use; "publish" and "subscribe" are confusing semantics, I feel.
Visual Studio Integrated Debugging for both Server and Browser Targets - The new APP_SRV project include the launch.json file that allows you to debug your code from inside Visual Studio Code! We can debug NodeJS processes this way too, which cuts down tremendously on server debugging. It's dope!
Improved Terminal and Console Debug Output - The UR.Prompt feature has been reworked so the same code and color definitions work, and you can now specify the color you want now without editing URSYS Core. There are versions of this utility available for both Server and Browser URSYS clients. The terminal output when running the server and the colorful tags in the browser console are being generated by our utility, which preserves the line numbers the output is generated from unlike every other such utility; this is better for seeing WHERE in the code a certain log statement is occurring which is better for debugging at a glance. We also have a new row/column addressable text utility for Browsers, which is used for on-screen monitoring of changing data. This can best be seen in the Generator app.
Better Module Organization - The codebase has been further refactored to make it easier to see the divisions of modules. At the top level of modules, we have a runtime.js and runtime-datacore.js module that serves as our central repository. Subdirectories of modules contain independent runtime modules, each with their own entry point that initializes that subsystem. In theory, this makes it easy to copy entire modules by copying the folder, though there are dependencies in the new lib directory where our common classes are globally defined. There is a convention for writing these types of modules that is developing.
Improved Module Resolutions - Yay, module resolution path aliases have been added to the webpack and tsconfig (and by extension, eslint) so we no longer have to use ridiculously long relative paths when importing a module (e.g. import '../../../../sim/script/ops/basic-smc). Our new top level aliases are app, config, module, lib, step and script. This not only makes our paths clearer, but it also lets you move files around and you don't have to rewrite your dependencies every time. The path aliases are matched across all three subsystems for bundling and live-linting in the editor. YOU'RE WELCOME.
New PixiJS Renderer and Screen Manager - We have moved away from ThreeJS and are using PIXI.JS because we don't anticipate needing 3D rendering capabilities. The new library is also hardware accelerated and seems to have excellent performance, and it seems to follow familiar conventions due to it being inspired by other scriptable applications (Flash, in particular). We have also improved the way we are drawing the screen that contains the renderer that is much more resistant to weird spacing by using CSS Grid instead of the janky DIV-based approach. It's simpler and better than CSS Flexbox, which we are using in GEM_SRV.
Fancy New Classes - We've modularized some of the most useful code bits from STEP and other Inquirium projects MEME and NET.CREATE. In particular, the PTRACK entity tracking system has been generalized into the SyncMap class and its supporting Pool and MappedPool classes. As a result, it is now very easy to do the PTrack-style differencing operation between sets of related objects that share the same id, and the use of a common ID makes it easier to do remote lookups because you can also call DATACORE to get the agent, display object, or visual object. Another new class is the AssetManager, which is the beginnings of our network-wide asset management system.

That's everything that I can think of in this build that's new! If you have any questions, just ask Sri.

In GitLab by @daveseah on Oct 5, 2020, 12:36

added 2 commits

3e836bd8 - docs: update october 2020 report, devlog, topical notes
8419ba4d - tracker-ux: nomenclature change in methods: "syncedObjects" is now "mappedObjects"

Compare with previous version

In GitLab by @daveseah on Oct 5, 2020, 12:56

fixed test instructions: "npm run app" should be "npm start"
test works on dev machine
pull fresh repo to macmini running catalina
realize that npm run app should have worked; reported error is because URSYS hasn't been built on a fresh install
correct npm script to include 'build'
confirm works on machine
commit change and request check

In GitLab by @daveseah on Oct 5, 2020, 13:00

Error on connect from remote machine: Error: Failed to lookup view "/Users/sri/Dev/merge-tests/gsgo/gs_packages/app_srv/built/web/index" in views directory "/Users/sri/Dev/merge-tests/gsgo/gs_packages/app_srv/views" at Function.render (/Users/sri/Dev/merge-tests/gsgo/node_modules/express/lib/application.js:580:17) at ServerResponse.render (/Users/sri/Dev/merge-tests/gsgo/node_modules/express/lib/response.js:1012:7) at /Users/sri/Dev/merge-tests/gsgo/gs_packages/app_srv/src/server-webpack.js:144:9 at Layer.handle [as handle_request] (/Users/sri/Dev/merge-tests/gsgo/node_modules/express/lib/router/layer.js:95:5) at next (/Users/sri/Dev/merge-tests/gsgo/node_modules/express/lib/router/route.js:137:13) at Route.dispatch (/Users/sri/Dev/merge-tests/gsgo/node_modules/express/lib/router/route.js:112:3) at Layer.handle [as handle_request] (/Users/sri/Dev/merge-tests/gsgo/node_modules/express/lib/router/layer.js:95:5) at /Users/sri/Dev/merge-tests/gsgo/node_modules/express/lib/router/index.js:281:22 at param (/Users/sri/Dev/merge-tests/gsgo/node_modules/express/lib/router/index.js:354:14) at param (/Users/sri/Dev/merge-tests/gsgo/node_modules/express/lib/router/index.js:365:14) at Function.process_params (/Users/sri/Dev/merge-tests/gsgo/node_modules/express/lib/router/index.js:410:3) at next (/Users/sri/Dev/merge-tests/gsgo/node_modules/express/lib/router/index.js:275:10) at /Users/sri/Dev/merge-tests/gsgo/gs_packages/app_srv/src/server-webpack.js:130:5 at Layer.handle [as handle_request] (/Users/sri/Dev/merge-tests/gsgo/node_modules/express/lib/router/layer.js:95:5) at trim_prefix (/Users/sri/Dev/merge-tests/gsgo/node_modules/express/lib/router/index.js:317:13) at /Users/sri/Dev/merge-tests/gsgo/node_modules/express/lib/router/index.js:284:7

In GitLab by @daveseah on Oct 5, 2020, 13:20

added 1 commit

9d946792 - tracker-ux: fix serving of index.html by replacing res.render() with res.sendFile()

Compare with previous version

In GitLab by @daveseah on Oct 5, 2020, 13:23

The issue was that the old index.ejs file was leftover in the built directory. This template was used to hold the window global variables for setting URSYS configuration; this was replaced with the getinfo webservice API, and index.ejs became index.html.

Fix is to disable the view engine and then use res.sendFile( filePath ) instead of res.render( filePath )

In GitLab by @daveseah on Oct 5, 2020, 13:26

unmarked as a Work In Progress

In GitLab by @daveseah on Oct 5, 2020, 13:33

added 1 commit

d2070ac9 - Update October 2020 Report.md (hard tabs in code example)

Compare with previous version

In GitLab by @daveseah on Oct 5, 2020, 13:36

added 1 commit

7e797f8f - Update October 2020 Report.md

Compare with previous version

In GitLab by @daveseah on Oct 5, 2020, 14:18

added 2 commits

02b89d13 - tracker-ux: fix last found typos in report
7850e22a - tracker-ux: fix index page title

Compare with previous version

In GitLab by @daveseah on Oct 5, 2020, 14:20

mentioned in commit b6f9db281e77d18d31a8b04145f5236dc5da4ca4

theRAPTLab / gsgo