Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

3D feature discussion #111

Open
lbud opened this issue Apr 16, 2018 · 11 comments
Open

3D feature discussion #111

lbud opened this issue Apr 16, 2018 · 11 comments

Comments

@lbud
Copy link

lbud commented Apr 16, 2018

This ticket is to track discussion on adding 3D features to the v3 spec.

  • Likely the most compelling use case for 3D is for line features

  • Polygons and points are less compelling:

    • We represent 3D polygons in existing vector tiles with a single height property. For more complex 3D shapes it seems it would probably be better to use an existing spec (glTF) rather than reinvent the wheel within VTs.
    • Supporting meshes would necessitate drastic retooling and probably won't work with our current feature model.
    • 3D point data could likewise be easily represented with a scalar property
  • Big question: what is the unit of the third dimension? One option would be to scale it to the other two dimensions' unit at a given YZ, though this would limit its extent to basically a vector cube.

  • Big unknown: how this would affect tile size

@jingsam
Copy link
Contributor

jingsam commented Apr 17, 2018

I think the hardest part is how to keep tile size small while transmitting fine 3D models. Is it tolerable to increase response time so as to get more accurate 3D models. I think there should be a trade-off between the tile size and the accuracy of 3D models.

@lbud
Copy link
Author

lbud commented Apr 25, 2018

@jingsam as noted above, we don't expect to add complex 3D models (like meshes or building models) in this version — at this point we're considering adding a third dimension to lines and points. We're certainly keeping a close eye on tile size regardless.

@lbud
Copy link
Author

lbud commented Apr 25, 2018

Tracking relevant branches (cc @mollymerp):

@mollymerp
Copy link

mollymerp commented Apr 25, 2018

@mollymerp
Copy link

note that since right now dimensions is a layer level field in the .proto file whereas in GeoJSON it can be feature level, geojson-vt can't safely infer from the GeoJSON object it is passed whether to treat features as two or three dimensional, so you need to explicitly set dimensions: 3 if you want the tiles to retain their z coordinates.

@andrewharvey
Copy link

See also https://www.cesium.com/blog/2018/04/09/draco-compression/ and https://github.com/google/draco

@muesliq
Copy link

muesliq commented May 18, 2018

I'd like to throw in the Terrain question mapbox/mapbox-gl-js#1489

@lileialg
Copy link

@mollymerp I followed what you wrote , but the point is still not 3d ,not extrusion,
my script:
var vtpbf = require('vt-pbf')
var geojsonVt = require('geojson-vt')
var fs = require('fs')
var geojsonVt = require('./geojson-vt-3d')
var vtpbf = require('./vt-pbf-vt3-3d')
var pbf = require('./vt-pbf-vt3-3d/node_modules/pbf')
var orig = JSON.parse(fs.readFileSync('/Users/lilei/Downloads/lilei.geojson'))
var tileindex = geojsonVt(orig,{dimensions: 3,indexMaxZoom: 15,maxZoom: 17, olerance: 3, extent: 4096, buffer: 64})
var tile = tileindex.getTile(16,53885,25046)
var buff = vtpbf.fromGeojsonVt({ 'geojsonLayer': tile })
fs.writeFileSync('my-tile.pbf', buff)

the mapbox-gl.js is from https://www.mapbox.com/labs-sandbox-demos/dc-lidar-vt3/

the geojson and pbf included in the zip file,
geojson&pbf.zip

Looking forward to your reply,Thanks

@korywka
Copy link

korywka commented Sep 13, 2018

@lileialg Have you resolved it? I have the same issue here:

https://bravecow.github.io/mapbox-3d/

@jsfeutz
Copy link

jsfeutz commented Oct 18, 2018

VT3 Spec shouldn't try and embed meshes or models into the tile, but be a reference system and handle complex/large assets with pluggable renderers created using things like mapbox's customlayer or unity

VT should be like HTML. html doesnt try to embed the image into the page.. but instead has a reference to an external asset which it lazy loads. The Html specification dictates tags for external assets like video, scripting languages , etc.

VT Lazyload Example:: At z0-12 load simple point or polygon. At z13-19 load low detail gltf model, at z20-24 load high LOD model. This opens up streaming/buffering assets(video, images, even bim models) and is not limited to one type. You can build renderers for any type of file/object.

I've have a simple prototype system that does this , videos at @jsfeutz(twitter).
Example
Vector tile geojson feature would look something like this:

   geometry: {type: 'Point, coordinates: [l, l] },
   tileset: {spec: {version 0.1},   <= tileset object  i borrowed from the work by 3D-tiles/cesium.
               z0: { renderer: "Point"}, <= between z0-11 render a point
               z12:{ renderer: "GLTF",         <= z12-z24 load and render model.     
                        translate: [0,1,0],
                        rotate: [0.5, 0, 1],
                        scale: 0.5,
                        cacheModel true,
                        cacheField: 'version',
                        version:  001,
                        children: [{renderer: 'image', <= children object handles multiple models/assets in tile.
                                        translate:[0,0, 0],
                                        uri:"s3://path/to/image.jpg",
                                        ],
                        uri:  "s3://path/to/model.glb" }}```

When the tiler gets the tile data.. it reads the tile set definition and initializes the the renderer defined in the definition and feeds the tiledata to that renderer.  Example of a 3D renderer is Andrew Harvey's work with three.js and mapbox. I have one for xeogl as well.

@Beilinson
Copy link

Is there any planned development on advancing the 3.0 spec and this 3D feature?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

9 participants