This tweaked my interest too… Many moons ago i wrote a save file editor for the first warlords game.
Do you have a way to get the number of meshes/points/tris etc from your files. If you have a number of files calculating the field size can be done with matrix maths based on the filesize.
ax1 + bx2 + cx3 … = filesize
where the coeffs a,b,c etc are the number of tris / points etc in the file and x1 and x2 are the field sizes… The tags give some indication of what data is in the file.
While I wait for a correlated .stl and .cdt file, here is my plan.
Assumptions (that would make life easy):
-The data may be organized in a weird way (spacers, padding bytes between interesting bytes, normals over here, verts over there etc) but I’m going to assume it is not “encrypted” in any way.
-The order of the vertices in the .cdt file is hopefully the order that will be in the resulting .stl file
-The origin of the .stl file is the same as the origin in the .cdt file. Eg, hopefully there is no trasnform (swapping of x,y,z or a “centering” of the origin to the median point) which happens in the .stl exporting process.
General Plan
-Identify one to several vertices in the .stl file which has a unique x,y,z position (prefereable the first vertex).
-Unpack the “Field” area of the file in 4 bite chunks with offsets of 0,1,2,3 and call them “unpack_0” …“unpack_3”
-Search for the unique x,y,z coordinates in each of my unpackings. When (if) they show up in unpacking_0, 1, 2, or 3 should allow me to identify the spacing between interesting parts of the file (or the modulus of that spacing). This is also assuming that we don’t coincidentally get an accidental binary representation of the float we are looking for. I think the chances of this are small…1/2^32?
Anyway, that is my plan for now!
Also, here is an image of the mesh in test.cdt using a trial version of another software which just allows me to view the file (hence the following screen shot). It will not tell me how many triangles are in the mesh but it will tell me the bounding box. So, I have 6 values to look for :evilgrin:
Size : 14.662982 19.656751 18.770734
Min : -15.912982 1.250000 0.025000
Max : -1.250000 20.906750 18.795734
ok, new data set…you can get it here
http://dl.dropbox.com/u/2586482/patmo.cdt
Using my trusty hex_editor, found that…
Field0_1 starts at: 11348
Field0_8 ends at: 1189059
Using my trial version to view the file (I don’t have the .stl yet)
First thing we notice, is that the max x, min y, and min z are the same as the other file. I will therefore discard those in my search and just look for the min x, max y and max z.
Furthermore, because this is a rectangular mesh, there should be LOTS of vertices (corresponding to the edges) with exactly the same x or y at the min x, max x, min y, max y.
Also, because the spacing of these vertices should be on the range of 30 to 200 microns, we can expect lots of similar values to the 2nd decimal place assuming units are milimeters (.05 mm…)
Next post, I will show you what I find when I go searching!
That is a great idea. I will have to marinate on how to exploit that.
Mighty purrrty mesh that scanner produces 
Some good ideas you have there in your plan… as you said it would be nice if the .cdt and .stl don’t differ via a transform to make comparing easier…
… and would be nice if the contents of the .cdt weren’t encrypted in anyway.
Although, I wouldn’t be too surprised if they did decide to employ some form of encryption to keep nosy people out.
Guess you are about to find out :evilgrin:
Nope, I haven’t given up, I was just waiting for that stl file. Well, here it is. This was produced using the Rhino with Dental Shaper add on as suggested earlier by batFinger
Feel free to download it for anyone playing along
http://dl.dropbox.com/u/2586482/Patmo.stl
Initial Info:
There are 6169 vertices and 11622 faces as reported by the blender mesh data
The bounding box and min/max x,y,z values seem to not agree with the previewer software though they are close (see post # 23)
ob = bpy.context.object
me = ob.data
box = ob.bound_box
for i in range(0,8):
vert = [box[i][j] for j in range(0,3)]
print(vert)
Later I plan to:
-Decode the .cdt assuming 32bit float (offset 0,1,2,3) and search for all values which fall within the absolute min/max range specified by the bounding box just to get an idea whether the actual numbers are encrypted or not
-decode the entire .cdt using 32bit integer (signed, unsigned?) and look for the values 6169 and 11622
Can you produce a file with the tags and the byte size inbetween the tags. Like in post 23. The 1177711 for fields0 to 8 doesn’t really play nicely with 6169 or 11622. If you find a block that drops out an integer when you divide… you’ll be most of the way there… oh and the filesize
PS have you considered emailing S…a and requesting the file spec?
:-/ hmmm. Interesting idea. Somehow I don’t think they would like that, but you don’t get what you don’t ask for.
Ok, here are some intial results. I haven’t had much time to play lately and wont have much until next weekend either. But for now…
Script 0. Unpacking the whole dang file in 4 byte integer (int, uint, long, unsigned long) yields no result for the number of faces or the number of vertices. Unpacking in short or unsinged short yields 7-9 instances of both the vertex number and the face number. I need to examine where these instances occur…next time.
Script 1. Searches for all of the possible floating point values by unpacking the Field0_1 to Field0_8 region in 4 byte chunks with an offset of 0,1,2,3, (thereby finding any and all possible floating point values). If they are in the range of possible values as inidcated by the .stl bounding box, I store them and count them.
Results:
At each offset, it finds around 11000 reasonable values
If the mesh has 6169 vertices and 11622 faces, we might expect then
(x,y,z) for each vertex and (i,j,k) for each face normal = total floating points
61693 + 116223 = 53373
or, if the .cdt file does not store normals
6169*3 = 18507
This would mean that my script is finding ~20% of the floats at each offset if the cdt file includes normal data, and ~60% at each offset if it does not include normal data. Here is the kicker…
Assume I’m talking absolute value here. The range for float values in the face normals is [0,1] and the range for float values in the mesh vertex data are [.025, 17.5]…so, they only partially overlap. Eeek, how am I to tell whether
-should I search for values between .025 and 17.5 and pick up some normal data inadvertently?
-should I search for values between 0 and 17.5? What about all the 1 e -37 crap that i get? Surely those are false numbers
-In each of those scenarios, what are the chance I’m counting random hits. Eg, what percentage of the whole domain of 32 bit floats is [.025, 17.5]? I must do this calculation sometime…would have been a good homework back in the day.
-should I count the vertex data with an x,y,or z coordinate above 1 and look for data in the range [1,17.5] so that I am sure I am looking for real numbers (and the occasional chance occurrence)…me thinks so, but I will do this tomorrow. This also assumes the face normals are normalized…More and more ASSumptions.
Sigh…enough for tonight…you will need “patmo.cdt” saved in your C:/ drive
http://dl.dropbox.com/u/2586482/CDT_Test.blend
Ok, I’ve kind of let this thread die. Both because I have been busy, and the posts I have made haven’t been very clear.
Today I hope to put that back on track.
Mainly, I have a lack of a reliable mesh which I know exists in the file. There are commercial software which can convert the mesh data in the .cdt to .stl format or view/analyze the file. The two I have access to give different results as follows.
-“Dental Shaper for Rhino” gives a mesh which is 1.3% larger in every dimension thank does the “Delcam Exchange viewer”
-“Dental Shaper for Rhino” gives a different domain and range for the x coordinates (although the mesh is not mirrored) so this indicates a funky coordinate system convention in one of the softwares (either the file originator, dental shaper or delcam exchangee).
Here we see the discrepancy in the bounding box sise, and the x coordinate sytem…
Delcam Bounding Box: [x:[-14.75, -1.25], y:[1.25,17.45] z:[.025, 3.70]]
Rhino Bounding Box: [x:[1.27, 14.99], y:[1.27,17.73] z:[.025, 3.76]]
-Assume that normal data and vertex data are both stored as 32Floats.
-Assume that the normals are normalized, meaning the maximum float value in any of the normal vectors is 1.
Here is the script I use to look for all the floating point values in the .CDT file with an absolute value greater than 1 and less than 17.73. That should exclude any of the the normal data, and account for the discrepancy in the x axis bounding box.
import bpy
import struct
import math
#Load the file
file = 'C:/patmo.cdt'
CDT = open(file,'rb')
cdt = CDT.read()
#Load the info from the .stl object imported int Blender
ob = bpy.data.objects['DentalShaper']
me = ob.data
#count all the floating point numbers in the .stl with abs
# greater than 1
xs = [abs(v.co[0]) for v in me.vertices if abs(v.co[0])>1]
ys = [abs(v.co[1]) for v in me.vertices if abs(v.co[0])>1]
zs = [abs(v.co[2]) for v in me.vertices if abs(v.co[0])>1]
n_floats = len(xs) + len(ys) + len(zs)
#isolate the maximum
maximum = max([max(xs),max(ys),max(zs)])
print(maximum)
#Byte in the .cdt file which we suspect the data begins
#eg, right before 55AA55AAField0_1
beg = 11348
end = 1189059 #is the ending byte of "Field0_8"
#32 bit Floating point numbers are 4 bytes long
chunk = 4
steps = math.floor((end - beg)/chunk) #this should be an integer, but just in case
#keep track of the total number we find.
total_floats = 0
#try offset of 0,1,2,3 to find every possible float value
for offset in range(0,4):
#add space and identify the offset
print(' ')
print('The offset is ' + str(offset))
#we could just count, but memory is cheap, so i will store
#for later use.
possible = []
#upack the file in 4 byte chunks, starting at the 55AA55AA
for i in range(0,steps):
a = beg + offset + i*chunk
b = a + chunk
#use little endian floating point
j = struct.unpack('<f',cdt[a:b])[0]
J = abs(j)
#test to see is the value is valid
if J < maximum and J > 1:
#keep track of it if it is
possible.append(j)
#display how many possible floating point values we think we have
L = len(possible)
total_floats += L
print(L)
print('the total number of valid float values in the stl file is ' + str(n_floats))
print('the total number of valid float values in the cdt file is ' + str(total_floats))
The results are as follows:
So, pretty good results. 608/18507 is only 3% “extra” floating point values in the .cdt file which I think is probably just random error in the sense that I am unpacking all the data in 4 byte chunks…now, I need to examine the spacing between said numbers!!
Hey! I’ve been a little busy and have only been visiting this site on breaks to view some art. But, I have some free time coming up and thought I might finally take a look at the patmo.cdt file and help you figure it out.
(assuming you are still trying to write a Blender converter for it or have you given up? )
Wow, I’m actually not subscribed to this thread, and I was just pulled to check it in a moment of procrastination. I’m not one for fate, but I think this means I need to stay the course here. I haven’t had as much time lately, and I was a little discouraged but I’m still game to play. I found another section of the file which intrigues me. There is a “Model” section which is empty before a step in the CAD process, and then gains dat…whereas the “Fields” stay constant. So what I’m thinking, is that the “Model” part of the file contains connectivity data (integers representing vertex indices) after the data is meshed. The sensor is 640 x 480, so a single scan is 307,000 vertices, (maybe that corelates with the size of the fields) yet our single scan mesh is way fewer vertices…meaning there is some meshing and decimation going on. It’s been two weeks since I was looking at this so I need to reset (and reread this thread!) I think all the links/files are still active in this thread. Let me know if you need any of the files.
this weekend I will
-review this thread, to see where my wanderings left off
-Compare the number of bytes in the Fields to (307k vertices) * (3 floats/vertex) * (4 bytes/float)
-Compare the number of bytes in the “Model” to (11622 faces) * (3 integers/face) * (2 bytes/integer)
… (ignore)
[quote=“patmo141,post:32,topic:524718"”]
Wow, I’m actually not subscribed to this thread, and I was just pulled to check it in a moment of procrastination.
[/quote]
Had some spare time coming and actually never bothered to reverse anything before. Seemed like an interesting challenge…figured I might as well try it once in my lifetime so I came back :eyebrowlift:
I’ll have to go back and read some of your posts (tomorrow) too to catch up on all your findings… I remember seeing you found the number of vertices and faces in the mesh. That could be extremely handy. As well as wrote some code for gathering statistics at each byte offset (also useful).
Anywho, I dl’ed your patmo.cdt and the link still worked 
.
Decided to breakdown the file before doing data searches just get a better understanding of whats data and whats crapola so below are some preliminary findings (copied 'n pasted from my notes in Notepad (rawr Notepad!)). [letter after the numbers signify what number system that number is in. h=hex d=decimal]
Breakdown of test file patmo.cdt
--------------------------------
File Start:00000000h
File End :0013E63Bh
--------------------------------
Records Found:
-01. "Status" start: 00000000h (slen 6d) (full 69d) (data 11d)
-02. "CStatus" start: 00000045h (slen 7d) (full 563d) (data 507d)
-03. "Thumbnails" start: 00000278h (slen 10d) (full 10,716d) (data 10,660d)
-04. "Field0_1" start: 00002C54h (slen 8d) (full 307,439d) (data 307,383d)
-05. "Field0_2" start: 0004DD43h (slen 8d) (full 608,416d) (data 608,360d)
-06. "Field0_4" start: 000E25E3h (slen 8d) (full 8,048d) (data 7,992d)
-07. "Field0_8" start: 000E4553h (slen 8d) (full 253,808d) (data 253,752d)
-08. "Field1_1" start: 001224C3h (slen 8d) (full 67d) (data 11d)
-09. "Field1_2" start: 00122506h (slen 8d) (full 67d) (data 11d)
-10. "Field1_4" start: 00122549h (slen 8d) (full 67d) (data 11d)
-11. "Field1_8" start: 0012258Ch (slen 8d) (full 67d) (data 11d)
-12. "Field2_1" start: 001225Cfh (slen 8d) (full 67d) (data 11d)
-13. "Field2_2" start: 00122612h (slen 8d) (full 67d) (data 11d)
-14. "Field2_4" start: 00122655h (slen 8d) (full 67d) (data 11d)
-15. "Field2_8" start: 00122698h (slen 8d) (full 67d) (data 11d)
-16. "Field3_1" start: 001226DBh (slen 8d) (full 67d) (data 11d)
-17. "Field3_2" start: 0012271Eh (slen 8d) (full 67d) (data 11d)
-18. "Field3_4" start: 00122761h (slen 8d) (full 67d) (data 11d)
-19. "Field3_8" start: 001227A4h (slen 8d) (full 67d) (data 11d)
+20. "EAreaPreparation" start: 001227E7h (slen 16d) (full 310d) (data 254d)
+21. "EAreaOcclusion" start: 0012291Dh (slen 14d) (full 133d) (data 77d)
+22. "EAreaAntagonist" start: 001229A2h (slen 15d) (full 131d) (data 75d)
+23. "EAreaField" start: 00122A25h (slen 10d) (full 133d) (data 77d)
-24. "Vds" start: 00122AAAh (slen 3d) (full 109d) (data 53d)
+25. "Triangle" start: 00122B17h (slen 8d) (full 67d) (data 11d)
+26. "CutTriangle" start: 00122B5Ah (slen 11d) (full 67d) (data 11d)
+27. "Model" start: 00122B9Dh (slen 5d) (full 112,479d) (data 112,423d)
-28. "CLines" start: 0013E2FCh (slen 6d) (full 127d) (data 71d)
+29. "Gdm" start: 0013E37Bh (slen 3d) (full 67d) (data 11d)
+30. "MillBottomPreview" start: 0013E3BEh (slen 17d) (full 67d) (data 11d)
+31. "MillPreview" start: 0013E401h (slen 11d) (full 67d) (data 11d)
+32. "VDSTriangle" start: 0013E444h (slen 11d) (full 72d) (data 16d)
+33. "SinterSupport" start: 0013E48Ch (slen 13d) (full 68d) (data 12d)
+34. "ConnectOrders" start: 0013E4D0h (slen 13d) (full 160d) (data 104d)
-35. "SLA" start: 0013E570h (slen 3d) (full 68d) (data 12d)
-36. "MCXLModel" start: 0013E5B4h (slen 9d) (full 68d) (data 12d)
+37. "BridgeMultiLayer" start: 0013E5F8h (slen 16d) (full 67d) (data 11d)
(not sure why
brackets screwing up above formatting.. just copy n' paste it all into Notepad for easier viewing if needed)
- Numbers on the left are order in which the records appeared in the file (37 records found).
- Next is the record description string.
- <b>start:</b> is where that record begins in the file (its hex offset)
- <b>slen</b> is the length of the description string.
- <b>full</b> is the size of the record in bytes. (record header + data)
- <b>data</b> is the number of bytes in the record that refer to actual data [vertices, normals, etc] (Model = 112,423 bytes ; Field0_1 = 307,383 bytes of data ; etc)
Haven't bothered to compare the sizes of <b>field_</b> and <b>model</b> to your findings yet to see if they reveal anything (kinda lazy at the moment for math :p). Nor have I bothered to look at the data in each record.
<i>Quick observation: lots of records have a length of 67-bytes and all have 11-bytes of actual data. The data of these records are identical. Probably some significance to that (will think about later).</i>
-------------------------------------------------------------------
Below is a break-down of how each record is stored in the file (so you can skip crapola and focus on actual data):
- each record starts with a 4-byte prefix <b>55AA55AA</b>then...
- 33-byte string description field then...
- 1-byte for something then...
- 6-bytes for something then...
- 4-byte integer describing length of data (in bytes) contained in this record then...
- 4-byte integer describing length of something then...
- 4-byte describing something then....
- array containing all the <i>actual data</i>
So each record has a 56-byte header describing the data then is followed by the actual data for that record. Same thing written programmatically:
Rest for another day. Sleep time :ba:Awesome. This is line with what I have found (I should have shared my spreadsheet with you) which has the starts and lengths of all those segments, but it is good that we arrived at the same place independently. The “empty” (67d rather) blocks will fill up if the .cdt file is saved further down the road at further steps in the design process. Here are some videos which show the the whole design process to help you understand what those other blocks probably mean. This is from a slightly newer version of the software (just released and which actually has a new file spec the …but the concept is the same, and the ability to save a legacy .cdt files)
that patmo.cdt file has 1 image in the “lower jaw” folder, 0 images in the opposing and 0 images in the buccal bite
Update:
Contents of each record inside the .cdt (new additions/changes underlined):
1. char [4] 55AA55AA start code
2. char [33] description field (last byte is 03h = end of text)
3. byte [1] TODO: seems to be a flag set to 01 or 02
4. byte [6] TODO: break this down farther
5. int length of the data block <i>compressed</i> (ie, item8)
6. int <i>length of data block when uncompressed</i>
7. byte [4] TODO: figure out what this represents
8. byte [--] <i>encrypted + compressed</i> data block
Each record’s 56-byte header is human readable, however, each record’s data is compressed and then encrypted on top of that.
Apparently they reeaaaallly didn’t want anyone to peek at their file’s contents. So don’t bother trying to extract model data (vertices, normals, etc) anymore with a simple read 0,1,2,3 offset strategy as its all scrambled junk (encrypted) and shrunk down (compressed).
What you can analyze, however, is notyourbuddy’s secret super duper decrypted decompressed patmo.cdt model data. :eyebrowlift2: All the data from the “Model” section of patmo.cdt I extracted and stored in the following binary file:
If you open it in a hex editor the beginning is as follows:
0000000: 0100 0000 0300 0200 0000 0000 0000 0000 ................
0000010: 0107 5665 7273 696f 6e09 0000 0009 0000 ..Version.......
0000020: 0000 0000 0000 0000 0001 0000 0019 1800 ................
0000030: 0066 2d00 00ff ff47 42ff ff47 42ff ff7f .f-....GB..GB...
0000040: 3fff ff57 42ff ff47 42ff ff07 40ff ff67 ?..WB..GB...@..g
0000050: 42ff ff47 42ff ffc7 3fff ff83 42ff ff47 B..GB...?...B..G
0000060: 42ff ffdf 3fff ff8b 42ff ff47 42ff ff1f B...?...B..GB...
0000070: 40ff ff93 42ff ff47 42ff ffff 3fff ff9b @...B..GB...?...
0000080: 42ff ff47 42ff ff07 40ff ffa3 42ff ff47 B..GB...@...B..G
0000090: 42ff ffc7 3fff ffab 42ff ff47 42ff ff03 B...?...B..GB...
Bytes 00-45 = Appear to be a header of some kind
Bytes 46-49 = 19 18 00 00 (reverse it) 00 00 18 19 (decode as 4-byte int = 6169)
Bytes 50-53 = 66 2d 00 00 (reverse it) 00 00 2d 66 (decode as 4-byte int = 11622)
This is followed by 74028 bytes of data.
The binary file’s 18507 floats converted to ascii. Every pair of 3 (i.e., each vertex) is listed on its own line. Entire ascii file can be downloaded here: http://www.mediafire.com/?ozlahvemkywe17b
Snippet from the file:
x y z
--------------------------------
50 50 1
54 50 2.125
58 50 1.5625
66 50 1.75
70 50 2.5
74 50 2
78 50 2.125
82 50 1.5625
86 50 2.0625
90 50 1.9375
94 50 2.8125
98 50 2.5625
102 50 2.875
106 50 2.75
110 50 4.25
114 50 3.25
118 50 2.6875
122 50 2.9375
126 50 2.25
130 50 2.875
134 50 2.6875
138 50 3.375
142 50 3.4375
146 50 3.1875
150 50 4.0625
154 50 4.0625
158 50 3.9375
162 50 4.4375
166 50 3.6875
170 50 3.75
Values in the hundreds? Bunch of 50’s? Not right. But, if you divide each value by ~39.37 the same data comes out looking like:
x y z
------------------------------------
1.27 1.27 0.0254
1.3716 1.27 0.053975
1.4732 1.27 0.0396875
1.6764 1.27 0.04445
1.778 1.27 0.0635
1.8796 1.27 0.0508
1.9812 1.27 0.053975
2.0828 1.27 0.0396875
2.1844 1.27 0.0523875
2.286 1.27 0.0492125
2.3876 1.27 0.0714375
2.4892 1.27 0.0650875
2.5908 1.27 0.073025
2.6924 1.27 0.06985
2.794 1.27 0.10795
2.8956 1.27 0.08255
2.9972 1.27 0.0682625
3.0988 1.27 0.0746125
3.2004 1.27 0.05715
3.302 1.27 0.073025
3.4036 1.27 0.0682625
3.5052 1.27 0.085725
3.6068 1.27 0.0873125
3.7084 1.27 0.0809625
3.81 1.27 0.103187
3.9116 1.27 0.103187
4.0132 1.27 0.100012
4.1148 1.27 0.112712
4.2164 1.27 0.0936625
4.318 1.27 0.09525
4.4196 1.27 0.106362
4.5212 1.27 0.117475
4.6228 1.27 0.100012
4.7244 1.27 0.1143
4.826 1.27 0.0873125
4.9276 1.27 0.104775
5.0292 1.27 0.115887
5.1308 1.27 0.138112
5.2324 1.27 0.12065
5.334 1.27 0.117475
5.4356 1.27 0.131762
5.5372 1.27 0.15875
5.6388 1.27 0.112712
5.7404 1.27 0.119062
5.842 1.27 0.1397
5.9436 1.27 0.141287
6.0452 1.27 0.119062
6.1468 1.27 0.136525
6.2484 1.27 0.150812
6.35 1.27 0.15875
6.4516 1.27 0.1524
6.5532 1.27 0.153987
6.6548 1.27 0.149225
6.7564 1.27 0.14605
6.858 1.27 0.150812
6.9596 1.27 0.200025
7.0612 1.27 0.173037
7.1628 1.27 0.174625
7.2644 1.27 0.1778
7.366 1.27 0.193675
7.4676 1.27 0.18415
7.5692 1.27 0.179387
7.6708 1.27 0.18415
7.7724 1.27 0.155575
7.874 1.27 0.1651
7.9756 1.27 0.187325
8.0772 1.27 0.176212
8.1788 1.27 0.204787
8.2804 1.27 0.217487
8.382 1.27 0.204787
8.4836 1.27 0.198437
8.5852 1.27 0.1651
8.6868 1.27 0.180975
8.7884 1.27 0.146052
8.89 1.27 0.193675
8.9916 1.27 0.203202
9.0932 1.27 0.200025
9.1948 1.27 0.23495
9.2964 1.27 0.207962
9.398 1.27 0.214312
9.4996 1.27 0.20955
9.6012 1.27 0.249237
9.7028 1.27 0.200025
9.8044 1.27 0.206375
9.90605 1.27 0.204801
10.0076 1.27 0.231775
10.1092 1.27 0.214312
10.2108 1.27 0.20955
10.3124 1.27 0.227012
10.414 1.27 0.225425
10.5156 1.27 0.20955
10.6172 1.27 0.223837
10.7188 1.27 0.23495
10.8204 1.27 0.227012
10.922 1.27 0.239712
11.0236 1.27 0.242887
11.1252 1.27 0.22225
11.2268 1.27 0.230187
11.3284 1.27 0.2032
11.43 1.27 0.230187
11.5697 1.27 0.284162
11.6332 1.27 0.223837
11.7348 1.27 0.246062
11.8364 1.27 0.250825
11.938 1.27 0.277812
12.0396 1.27 0.263525
12.1412 1.27 0.236537
12.2428 1.27 0.255587
12.3444 1.27 0.249237
12.446 1.27 0.23495
12.5476 1.27 0.206375
12.6492 1.27 0.230187
12.7508 1.27 0.227012
12.8524 1.27 0.233364
12.954 1.27 0.263525
13.0556 1.27 0.257175
13.1572 1.27 0.244475
13.3604 1.27 0.250825
13.462 1.27 0.250825
13.5636 1.27 0.2667
13.6652 1.27 0.249237
13.7668 1.27 0.255587
13.8684 1.27 0.28575
13.9701 1.27 0.288874
14.0716 1.27 0.252412
14.1732 1.27 0.255587
14.2748 1.27 0.261937
14.3764 1.27 0.292098
14.5796 1.27 0.277812
14.6814 1.27 0.277842
14.7828 1.27 0.301625
14.9458 1.27 0.284214
14.986 1.27 0.2667
1.5621 1.27 0.0555625
1.5875 1.27 0.0555625
Final full ascii file can be downloaded here: http://www.mediafire.com/?d3qvvg2w3h0djxw
Note the maximum x value is 14.986 (rounds to 14.99)
Note the minimum x value is 1.27
Of course I didn’t look at the entire file, but I’d imagine the y mins/max and z mins/max match as well.
m00psauce
:spin:
I am more than impressed. I understand everything you said there, what I don’t comprehend is how you arrived at those results.
Reversing things?
Encryption and compression, how on earth could you possibly figure out what methods to use? It seems like to empirically try all these things would take… infinite amounts of time by guess and check. So I assume there there is a general battery of tests a prudent de-encrypter or de-compressor might try first.
Want to give me 10-15 terms to google as hints to what you did?
-Patrick
[quote=“patmo141,post:37,topic:524718"”]
Encryption and compression, how on earth could you possibly figure out what methods to use? It seems like to empirically try all these things would take… infinite amounts of time by guess and check. So I assume there there is a general battery of tests a prudent de-encrypter or de-compressor might try first.
Want to give me 10-15 terms to google as hints to what you did?
[/quote]
Nope. 
I have no interest in making a company’s encryption and compression schemes public. Nor will I teach anyone how to…as such knowledge could easily be perverted and used for doing baaaad things.
What I will do is probably just write a generic c++ program and give it to you. It will allow you to define a .cdt file as input then receive a binary file as output.
The binary output file will be identical to the patmo.model binary file I posted in my last post.
So feel free to start writing a Python/Blender script to read that file and load the mesh into Blender (I have no interest in writing a Blender script atm so thats all you :evilgrin:).
Binary file structure:
Point taken. I am on the python script task. 
Below is the extracted “Model” data for patmo.cdt, test.cdt, and test2.cdt for you to play around with:
patmo.cdt : http://www.mediafire.com/?idcnd6mnb1f1oho
patmo.model: http://www.mediafire.com/?92wg2majh6829co
patmo.txt : http://www.mediafire.com/?vq017nt2ddk4u37
test.cdt : http://www.mediafire.com/?377kwca0dmauan7
test.model: http://www.mediafire.com/?01aoswa4re14ky2
test.txt : http://www.mediafire.com/?ahqr6t6ha45p6v4
test2.cdt : http://www.mediafire.com/?m62gz8p6iv8fi66
test2.model: http://www.mediafire.com/?9z2p6m5elu6acao
test2.txt : http://www.mediafire.com/?1gb28mwoad5uz1o
---------------------------------------------------------------------
(the patmo.cdt extracted data above is identical to what I uploaded earlier, but I’m posting link here again so we have a post where all the data is together)