More requirements for DB schema

[Dimitrios.Ververidis]

Hi,
we have some ideas/propositions for Speckle Database schema that can boost usability :

a) Is it possible to have a low poly model for preview. Downloading big streams/commits for a brief preview is not very user friendly when we want to compare multiple of them.

b) Can access rights be at the level of an object: Personal, Organizational, Review only, Open

c) Interconnection among Streams: Is there a way to relate Streams, e.g. if the projects are related

Best,
Dimitrios Ververidis @ PrismArch

[dimitrie]

Hi @Dimitrios.Ververidis! Nice, though questions. The easy ones:

b) Object level permissions: it’s theoretically possible, but we don’t want to go down that way. We control access at the stream level. We are looking into enabling a clear information “state” protocol, on the lines of “WIP”, “Released”, etc. There’s quite a few topics:

Idea: Version (/revision) control through Speckle (with metadata, information states and projectroles)

Hi everybody, Below I tried to explain my idea (and ideals) about version control and I hope it’s clear what I mean, and what I think is needed in terms of addition to Speckle . (I searched around the forum for a similar topic but i couldn’t find anything this specific). I’d like to be able to use version control in the Speckle environment to keep track of which version each commit is, for example P00.01, P00.02, P01, P01.01, etc. I think that this is needed to be able to easiliy co…

and

Speckle + ISO-19650 standard

Hey all, I think Speckle has come a long way from just being able to share some information between software, to a full-on GIT approach on geometry and collaboration between models and disciplines focussed on objects and I think this can be the future of changing the way we approach our design processes. As I am working on projects with (Dutch/Belgian) contractors and clients, I am still struggling to propose Speckle as it is (for most our cases) only applicable for work in progress informatio…

c) Not currently. I’d suggest some nifty usage of branches - you can have a branch per “sub-project”. Ideas are being shaped up in several threads, including here: Limit stream access to registered users

a) Low poly: This i’d be interested in scoping a bit more. I’m not sure of any intelligent decimation algorithm that we could run out of the box on any mesh we find, but I suspect this would be a way to go. This could be exposed via a separate server endpoint that would stream a dumb-er version.

[jonathon (jonathon@stardotbmp.com)]

It depends on what’s being expected here. While not decimation per se, there are “shrink-wrap” methodologies possible, this might be fine in some preview cases, but not if the low-poly version was expected to be useful in other ways.

a) Low poly: This i’d be interested in scoping a bit more. I’m not sure of any intelligent decimation algorithm that we could run out of the box on any mesh we find, but I suspect this would be a way to go. This could be exposed via a separate server endpoint that would stream a dumb-er version.