Hi Roland,
The model saved the path to the finest texture resolution. This is true for all of the representation of the model geometry. It is the responsability of the Run-time publisher to decide which resolution to get based on the pixel size. This is based on the need of the client device depending on:
- Screen size resolution
- Paging distance
In regards to the CDB API, the filename needs to be decomposed into parameters (cdbDB::fileParams) to request the texture.
For N00E000_D301_S001_T001_L07_U15_R79_TEX03.rgb, the texture name is TEX03.
OK, that seems fine, so for each texture I parse the string to extract the constant parameters N, E, D, S, T and the highest resolution texture constants L, U, R.
From L,U,R I can then calculate lower LOD's by the following
L! = L-n
U! = floor( U / ( 2^n ) )
R! = floor( R / ( 2^n ) )
so for my file example from before
N00E000_D301_S001_T001_L07_U15_R79_TEX03.rgb
N = 0
E = 0
D = 301
S = 001
T = 001
L = 07
U = 15
R = 79
To get lod 4 I would then get the values
L! = L-3 = 4
U! = floor( U / ( 2^n) ) = floor(15 / 8) = 1
R! = floor( R / ( 2^n) ) = floor(79 / 8) = 9
The easiest way for me to extract the filename is to search for the last '_' and last '.' and then trim the string between these values. The only problem I can foresee with this approach is is one of the filenames includes an _ in it, i.e. house_12. In this case I guess that it should be safe to use a hard-coded offset to the end of the R field as this part of the string is always the same length.
Does this all seem correct?
Could suitable convenience function(s) be provided to enable easy decomposition of such strings?
Roland, here is an answers to your question.
LOD, Up and Right indices (L, U and R) calculations seem correct. However, there is no "easy" way to extract the model component as there are no fixed offset to the end of the "R" field. U and R fields are variable in length. As well, in order to be compatible with future releases of the CDB Specification, all fields within a CDB file name should be parsed in order to extract the model component.
Rharris: we will look into what can be done in upcoming release of the CDB API.
Craig
I am currently trying to load a geospecific model using the cdb api and am unsure of how the texture part is supposed to work.
In my test cdb I get something similar to the following when querying the 3d model for a texture name
../../../301_GSModelTexture/L07/U15/N00E000_D301_S001_T001_L07_U15_R79_TEX03.rgb
How should I be going from this to loading the texture? The model seems to have been saved with relative paths and I guess that it should have been saved with no paths but that isn't a problem.
Should I be decomposing the string so that I can construct a cdbDB::fileParams to load the texture or is there something wrong with the texture name in my cdb?
Also should the texture name I pass in to cdDB::fileParams::m_acTexture be TEX03 or TEX03.rgb? It can't be the long filename because it exceeds the 32 bytes allocated to the string.