Comments (28)
Please don't make them "rough." If you want to take a shot at doing a complete and careful writeup, then please do so, but doing "rough" edits will create more work for both of us.
from 3d-tiles.
Omitting instance.batchId
when header.batchTableLength === 0
seems fine to me and should be easy to handle on the client side.
from 3d-tiles.
Sounds good, updated the spec in 17743a0.
Please update CesiumGS/cesium#3158 if you haven't already.
from 3d-tiles.
All updated there.
from 3d-tiles.
Thanks 👍
from 3d-tiles.
We have a lot of fields that say "This must be greater than or equal to zero" that are of type uint32
. Is that redundant?
from 3d-tiles.
Good catch, #40.
from 3d-tiles.
Hi all,
we are now stating to implement I3DM for our vegetation datasets.
After reading the spec I have a couple of questions and suggestions for improvements.
-
the instances field should be extended to include position, scale, rotation and the model's center point. This could be done by adding more numbers to each instance, e.g.
Tx, Ty, Tz, Rx, Ry, Rz, Ra, Sx, Sy, Sz, Cx, Cy, Cz
( T: translation, R: rotation as rotation axis vector and angle in rad, S: scale, C: center point within the model used for positioning). See [http://www.web3d.org/documents/specifications/19775-1/V3.2/Part01/components/group.html#Transform] for X3D Transform spec.
or simply by using a transformation matrix ,e,g
1.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 1.0 (like in gltF Node)For visualizing tree models the rotation could be set randomly, giving the final model a more natural touch. Scaling in all 3 dimensions is also important for tree models.
-
the in the instance field, the location is given as longitude, latitude. Is the instance always positioned on the terrain in Cesium? A height or elevation field should be included. Secondly, the height could be relative to ground or absolute.In our case we have always absolute coordinates, so relative to ground is not really necessary. Others might want to convert 2D shape files.
-
Giving the location as longitude latitude means that coordinate transformation is necessary for each instance. Could this be also relative to a tile center in Cartesian coordinates? If so, a CESIUM_RTC point must be included somewhere.
-
My plan is to process a vegetation dataset which contains many different tree species, each with its own prototype. I would like to include all of these in a single I3DM file. Is it possible to provide several models in the binary glTF block and make references from the instances field? In this case there should be a proto identifier along with the transformation. Maybe using batch IDs, which are stored in glTF, e.g.
batchId, 1.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 1.0, instanceId
(instanceId here is what is now called batchId in the current I3DM spec.).
If batchId cannot be used for geometry instancing, then maybe we can have an array of glTFs?
best regards,
Arne
from 3d-tiles.
Thanks for the feedback @arneschilling. The i3dm format is definitely a work in progress, storing only the longitude and latitude was a temporary solution for just getting something simple to work. We have considered a lot of the points you mention and the final version of the spec should look similar to that.
from 3d-tiles.
@arneschilling thanks for this input. As @lilleyse noted, it is inline with the direction i3dm
is heading and I expect the tile format will be flushed out this summer as we work towards a draft 1.0 spec. Keep an eye on this issue.
In the meantime, for (4), use a composite tile to combine multiple i3dm
tiles.
from 3d-tiles.
@lasalvavida @lilleyse here's what I propose to finish up the i3dm
tile format:
- Instead of storing
longitude
andlatitude
as doubles, storex
,y
,z
in WGS84 quantized in the same manner as the glTF extension. Store any metadata needed to decode in the tile's header. - Instead of assuming east/north/up, store each instance's rotation as an oct-encoded normal that transforms from the instance's local coordinate system to WGS84.
- Introduce
batchId
semantics,TILES3D_SCALE
andTILES3D_NON_UNIFORM_SCALE
that are uniform and non-uniform (vec3
) scale respectively.- @lilleyse if it is reasonable enough, we should expose these through the Cesium API and allow Declarative Styles to modify these.
- Consider storing SOA instead of AOS for better compression?
Long-term, if we need to optimize the case for instances "on the ground" with or without a rotation, we can, but let's not introduce special cases like this until truly needed.
from 3d-tiles.
@lasalvavida also, I'll do the spec updates and you can focus on the implementation.
from 3d-tiles.
Instead of assuming east/north/up, store each instance's rotation as an oct-encoded normal that transforms from the instance's local coordinate system to WGS84.
@pjcozzi Do you think maybe we should use a quaternion here instead? It might be useful to be able to make instances face different directions.
from 3d-tiles.
For example, if I have an instanced streetlamp,
I want to be able to rotate the instances so that they overhang the street.
Talked with @lilleyse and you should be able to do this with two vectors, which may be preferable to a quaternion.
from 3d-tiles.
Instead of assuming east/north/up, store each instance's rotation as an oct-encoded normal that transforms from the instance's local coordinate system to WGS84.
@pjcozzi Do you think maybe we should use a quaternion here instead? It might be useful to be able to make instances face different directions.
Sorry, I mean to stay store two normals. The third normal is just z = cross(x, y)
. This is enough to define a transform to rotate from the local coordinate system to the global one (at load time, you can construct a 4x4 matrix with this as the top-left 3x3 rotation and the position as the top-right vec3 translation). Let me know if you need help with the math.
The normals are preferred over the quanterion for simplicity, which is important for making this a standard.
from 3d-tiles.
With only 2 axes/normals you need an additonal vector for scaling along x/y/z. Using 3 axes would provide enough information for rotation, scaling, shearing. I am sure we can find the math for translating this into a 4x4 matrix.
from 3d-tiles.
@arneschilling the third vector is just z = cross(x, y)
as described above. Note that these are of unit length so that they can compress well. Scaling will be handled with semantics in the batch table as described above, #33 (comment). This approach should meet all your use cases with a concise representation.
from 3d-tiles.
@pjcozzi, @lilleyse What do you think about making the gltfFormat header field an options bitmask? Like this:
7-5 | 4-3 | 2-1 | 0 |
---|---|---|---|
For future use | 0 ->east/north/up , 1 ->2 normals , 2 ->2 normals oct-encoded |
0 ->lat/long , 1 ->lat/long/height , 2 ->x/y/z , 3 ->x/y/z quantized |
0 ->glTF uri , 1 ->glTF embedded |
Doing this has the benefit of making sure that existing i3dm models don't break with these changes.
from 3d-tiles.
This is too complicated and backwards compatibility with existing i3dm is not important since it is not widely used. I would stick with what I proposed above; providing this many options makes the spec harder to implement, harder to understand, and harder to get standardized.
from 3d-tiles.
Alright, will do. My only real concern here is that forcing support for oct-encoding and quantization instead of making it optional may make it difficult for other engines to implement.
from 3d-tiles.
@pjcozzi For decoding the quantized coordinates, my suggestion would be to just store a vec3
float scale and have the origin implicitly at (0,0,0)
. Where in the header do we want to store the scale; should I just tack it on the end?
from 3d-tiles.
Also do we want to store that as float32
or float64
?
from 3d-tiles.
There should be a float64 vec3
"origin", then each instance should be quantized float32 vec3
, which will be decoded and added to the origin.
Yes, the origin can be added to the end of the header along with any other decode data, mirroring the glTF extension.
from 3d-tiles.
Maybe I should have been clearer. Quantization is usually a scale and a translation. I'm saying to just store the scale and use the min long/lat/height from the tile json as the translation.
from 3d-tiles.
For precision, we'll want to store the translation as doubles and, to save memory, each instance as floats so I don't think we should use the min for translation. This is similar to CESIUM_RTC.
from 3d-tiles.
Cesium updates by @lasalvavida are in CesiumGS/cesium#4101.
I'll do spec updates after code review.
from 3d-tiles.
@pjcozzi Do you mind if I put in a pull request for some rough spec updates while it's still fresh in my mind?
from 3d-tiles.
The final touches are being added to #100, which I expect will be merged tomorrow.
from 3d-tiles.
Related Issues (20)
- Clarify the use of non-8-bit-channels in property textures HOT 1
- How to format data HOT 1
- glTF metadata uses integers where it should use "glTF IDs" HOT 1
- Inconsistency in tile schema and its description
- Cesium 1.1 tiling data failed to load
- Clarify details about `featureCount` and `nullFeatureId` HOT 4
- Can Earth Explorer 3D Map with Augmented reality be added as Viewer?
- Can Map Data Explorer iOS and Android be added as Viewer - it supports 3DTILES
- Selection Issue with GLB Model Organized by Tileset.json HOT 2
- Basic, minimal examples; sources for README figures HOT 10
- EXT_mesh_features Clarification: How many feature ids does an indexed geometry have when ids are implicitly derived? HOT 7
- EXT_mesh_features Rendering: How to visualize "interpolated" features? HOT 8
- 3D-Tiles 1.1 Implicit tile about .subtree binary file HOT 6
- Implementation notes refer to `bufferView` where `bitstream` should be used
- 3D-Tiles 1.1 implicit tile : Octree HOT 2
- 3D-Tiles 1.1 voxel HOT 1
- Clarification for content availability of implicit tileset roots HOT 4
- 3D-Tiles 1.1 voxel HOT 3
- 3D-Tiles 1.1 voxel's customShader HOT 1
- 3D-Tiles 1.1 binary .voxel file HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from 3d-tiles.