Hi everyone
I try to read the example .i3dm file in Sandcastle of 3d-tiles-transform branch, and have problems about the Specs\Data\Cesium3DTiles\Instanced\InstancedWithBatchTable\instancedWithBatchTable.i3dm
In this file, the BATCH_ID property is hard to interpret.
Firstly, the featureTableBinaryByteLength = 452, the BATCH_ID.byteOffset = 300; So I think the length of batch_id in binary should be 152 byte. Since the datatype of bathch_id is uint16 (2 byte), there are 76 batchid for 25 instances. So how many vertices in each instances have batch_id?
Secondly, I used nodejs buffer.readUint16LE() to read batch_id, the first 25 values are from 0 to 24. But from the 26th one, the values all became 0, and the last value is an extremely large one.
I can’t find any description about batch_id in featureTable specification. It will be really helpful to have someone point out my mistake.
Any help appreciated
Best
Chris
Hi Chris,
I see a featureTableByteLength of 352. So that would give the BATCH_ID section 52 bytes, and I’m assuming those last two bytes are only there for padding (I didn’t generate that tileset). So that would give each instance its own batch_id. (Unlike b3dm which is one batch_id per vertex, here it’s one batch_id per instance). Those numbers from nodejs seem correct to me then.
The feature table spec doesn’t go into detail about BATCH_ID. Instead each of the tile formats will go into more detail about it (like the i3dm spec) and we are currently writing a batch table spec that should be ready pretty soon.
Quick correction, I meant to write featureTableBinaryByteLength.
Hi Sean
I remove the last two bytes in featureTableBinary, and it still works. In addition, I find there are 3 spaces after the featureTableJSON (I don’t know if it is necessary, I use the instancedWithBatchTable.i3dm in 3d-tiles-transform branch).
Now I am writing a new .i3dm, with my own .glb model. BUt I can’t see the model displayed.
In my model, there is only one cube (size: 555), the position is [0,0,0].
I use the transform property in tileset to place the cube in a specific location, and use region to define the boudingVolume.
When I load the tile in Sandcastle of 3d-tiles-transform branch, I can’t see the model and boundingVolume. Only the camera is set to the right place.
I upload my tileset.json and .i3dm. Can you check them if you have time?
Thanks
Best
Chris
在 2016年9月6日星期二 UTC+8上午1:02:29，Sean Lilley写道：
10.i3dm (155 Bytes)
instRect.glb (3.85 KB)
tileset.json (636 Bytes)
The purpose of the empty bytes and whitespace is to ensure that the buffers are byte-aligned properly. I think the 2 bytes after the featureTableBinary may have been unneeded, but the 3 spaces after the featureTableJSON are important to ensure the featureTableBinary begins on a byte-multiple of 4. Check out this section of the spec for more details: https://github.com/AnalyticalGraphicsInc/3d-tiles/tree/master/TileFormats/FeatureTable#implementation-notes. This also is why it doesn’t load in Cesium.
Hi Sean,
I modified the bytelength of the featureTableJSON in my .i3dm from 79 to 80, that let the featureTableBinary begins on the byte 112 (32+80). But it still doesn’t work.
So I modified the bytelength of the featureTableBinary from 14 to 16. it doesn’t work.
Then I even moditied the bytelength of the batchTableJSON from 15 to 16. But again, it doesn’t work.
I upload the .i3dm that only the featureTableJSON part is modified. Can your check it again please if you have time.
Thanks again
Best,
Chris
在 2016年9月7日星期三 UTC+8上午7:21:23，Sean Lilley写道：
1.i3dm (153 Bytes)
That new file works for me, check out the attached screenshot. The only think I had to do was rename 1.i3dm to 10.i3dm so the tileset.json references the right file.
Thanks Sean,
Sorry, I made a stupid mistake. I didn’t copy the .glb file in the same folder. After copying the .glb, I manage to load a single cube in Cesium.
Then, I tried to create more cubes, but I met something strange: The instances I create is different in size and color, and may be even different in origin. (See the figure below)
The green one is the first cube I created, the position is [0,0,0], the batch_id is 0; As you can see it is smaller and lower than the others.
The yellow cubes are in positions [-20,0,0] [-10,0,0] [10,0,0] [20,0,0]. They are bigger, and in different color from the green one (I didn’t set any color property).
I think the five cube ought to be the same, but they don’t.
I upload the new tileset.json, rect5.i3dm, and the original .glb again.
Can you check it again please? Thank you very much.
Best
Chris
在 2016年9月7日星期三 UTC+8下午9:26:14，Sean Lilley写道：
instRect.glb (3.85 KB)
rec5.i3dm (221 Bytes)
tileset.json (640 Bytes)
I am using the 3d-tiles-transform branch of Cesium
You can move over to the 3d-tiles branch now, we merged the 3d-tiles-transform branch in. There was a bug we fixed in the process which is what caused the strange box sizes.
As for the colors, this is happening because the 3D Tiles sandcastle demo automatically styles the instances if they contain a “height” property. This is mainly for illustration of the dynamic styling feature, but you can turn it off by deleting the code:
var properties = tileset.properties;
if (Cesium.defined(properties) && Cesium.defined(properties.Height)) {
tileset.style = new Cesium.Cesium3DTileStyle({
// “color” : “color(‘#BAA5EC’)”,
// “color” : “color(‘cyan’, 0.5)”,
// “color” : “rgb(100, 255, 190)”,
// “color” : “hsla(0.9, 0.6, 0.7, 0.75)”,
“color” : {
“conditions” : {
“${Height} >= 83” : “color(‘purple’, 0.5)”,
“${Height} >= 80” : “color(‘red’)”,
“${Height} >= 70” : “color(‘orange’)”,
“${Height} >= 12” : “color(‘yellow’)”,
“${Height} >= 7” : “color(‘lime’)”,
“${Height} >= 1” : “color(‘cyan’)”,
“true” : “color(‘blue’)”
}
},
// “show”: false
// “show” : “${Height} >= 0”,
“meta” : {
“description” : “‘Building id ${id} has height ${Height}.’”
}
});
addStyleUI();
}
Or just click the Remove Style button.
Thanks Sean,
Now I use the 3d-tiles branch and display the model in a normal way.
在 2016年9月9日星期五 UTC+8上午8:37:01，Sean Lilley写道：
