![]() ![]() Now these points can be heights or simply indexes of the texture / color / whatever used to draw that point - the range of values found in 3 maps checked is a bit small, so may be indexes rather than actual heights. Using the 1024 pts maps to use smaller fingures, it appears that the ""second block"" (should say "last") is 0x40401 long, each 513 bytes a 'FF' value seems to indicate the end of lines (or just particular bounds of the 18.wld), so some lines of 512 bytes to (may be) describe azimuts of 1024 pts one byte (with 256 possible heights) at every 2 pts (since values are not similar by word or nibble), it seems that heights are coded on 1 byte.īut, actually it's 512 intervals, so 513 pts, and 513 x 513 = 263*169 = 0x040401, got it. You already note it: the values of these blocks are ugly, they don't read like int or float (getting some values in 1e-38 or illogical set of int indicates most of time an error regarding assumed format.īut this point is actually only true for the beginning of the block, the second part (+/- the 20-25% last part) looks homogeneous, and *voila* I found my square! Possibly, but it is also possible that it defines any constant-size-info. no idea.Īnd the header would be a block that defines how the basic grid is built? Still what is the resolution of map and azimut - meaning how many bits to define each individual altitude? and how many points on the 1024 pts side?. Schematically, the floor is drawn by a set of points defining altitudes smoothed themselves (by splines or other bezier). Also the ground can not be decomposed in triangles, as for your try, the floor is corrugated w/o flat small structures. First, the texture is usually not a single file (reuiqred if the ground is one big set of triangles), instead several bitmaps are used (and found). ![]() The ground surface generated by a map-height is *not* like that. "Small" shapes, and also full dongeon, are built with vertices - meaning the classical triangles (could be also square) on which a texture is applied each point is defined by (x,y,z) (the spatial point) + (u,v) the coords on the (flat) texture bitmap the triangles can be as small (and many) than desired to provide a very smooth resolution, but usually it is possible to zoom enough the object to see the triangles (and not a truly curved surface). Very likely, the surface is not built with triangles. Actually, i have some ideas but I don't success to validate them. Now how the map-height is built ? No idea, I asked for advices from 3D modelers expert, nobody gave feedback. ![]() So far we don't explain any byte of this block, the assumption of a descriptive header is valid but not validated at all. ![]() In such case, the topo of the 1024x1024 pts square must be defined by 0x0C0400 bytes and thus an header of 0x0803 bytes is present (such header is may be present at the begening of the block, of course it is also possible that maps have a unknown / garbage / useless block of 0x803 bytes somewhere "near" the beginning (start, middle, or end of "map-height" block). Or the resolution is constant, I prefer that option for several reasons, in this case the data that defines the topography of a map 4 times bigger than another must use 4 times more data. May be the resolution (the distant between 2 pts that define the geometry/topography) of the map is not constant, in such case, somewhere in these data is coded that resolution, it must be found and used to try to undertsand the next data. ![]()
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |