A standard C corp (and more relevantly its officers) is legally obligated to maximize profit for shareholders at the expense of any mission.
For a B-corp if the investors sue the board or CEO for breaching fiduciary duty for not maximizing profit, the response is "we were following the mission (and you knew we would be following the mission going in), GFY"
Mastodon migration is not atomic and requires the instance you are migrating from to remain operational (and non-adversarial) long enough for all of your friends' instances to notice you have moved and update their contacts. It doesn't preserve your follows. On Bluesky you just need to push your repo onto a new PDS and sign a new DID telling the network which PDS has your data. Everything else is seamless and atomic.
> I think you're overestimating how taxing going "viral" is on an ActivityPub server. if one of your posts goes viral, it doesn't get hit for every follower you have. It'll only be a request per instance. Plus, task queues exist. Yes going viral is taxing on a server. it doesn't mean the solution is just to offload that burden to some centralized server.
I run a single-user Mastodon instance and replying to a viral post took me offline for like 24 hours.
Just gonna throw out a link to this whitepaper co-authored by the now-CEO of Bluesky and one of the lead authors of ActivityPub https://gitlab.com/-/snippets/2535398
Very interesting idea, although one potential concern, depending on implementation, is that a lot of landmarks are copyrighted in a way s.t. you can include them in maps of a larger area, but you can't provide them standalone (or advertise using their names).
Thanks! And no - we don't have whitepapers, but if you want to get a sense of our philosophical influences, I point to Daniel Ritchie (a prof at Brown)'s publications as he's one of our scientific advisers, although you'll have to fill in the gaps a bit as his work is mostly not specific to geospatial applications.
There are some limitations with getting big mesh models into Roblox but it's definitely possible - I'll ask if my engineer who's been working on testing that if he has recommendations.
Our inverse procedural modeling process produces 3D models representing/explaining the structures we see in our input sensor data, so it doesn't require hand-modeling first.
> Is the benefit that you then can store the parameters and use the model to regenerate the building, thus compressing the representation a bunch?
A few benefits - we can automatically generate the mesh model at different levels of detail by stripping out elements of the procedural recipe (rather than relying on mesh decimation which gives ugly results). And yeah, compression + error-correction also play a role. Plus compared to photogrammetric models, we have the metadata needed for interactive lighting/simulation.
Yes, we generate water-tight meshes for buildings that are 3D printable (and terrain can be made 3D printable pretty easily). Bridges are one of the weak-points in our current reconstruction process - the gnarlier bits of 3D road network inference is implemented internally, but there's a bit more work to get make the output pretty enough to pass through to end-users.
It looks like their core business model is modular asset packs, not necessarily tied to real world environments? Potentially some overlap, but I would guess it's unlikely we would be going head-to-head with them in most customer use cases.
For a B-corp if the investors sue the board or CEO for breaching fiduciary duty for not maximizing profit, the response is "we were following the mission (and you knew we would be following the mission going in), GFY"