-
-
Notifications
You must be signed in to change notification settings - Fork 305
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add: seoul map import capability #92
base: master
Are you sure you want to change the base?
Conversation
Nice job! :) You're the first one to add a new map source ;) It must mean that despite all it starts to get readable. I'm having trouble with the global transform: It is not only the scale, there is some skewing in the matrices. I had a bit of a similar issue with maps.cz, yet unresolved. Reading the vertex shader, it looks like (RD1.9, GTX 1070) |
Didn't notice the skew as I tested with a few number buildings. Thanks for your quick review. |
Well the Another approach would be to notice that the website uses the https://openlayers.org/ (so do maps.cz and namur.be maps I believe) and extract info from their code. For instance, it seems they are using the default fov of 62°. Near and far planes are a bit more complicated to determine though as they depend on lods. |
There are other constants that I thought useless for building the scene, which I excluded with Worth to note, For example, from capture 1: {"$Globals":
{"_d": [0.0, 1.0, 0.0, 0.0, 0.007843137718737125, 1.0, 1.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0],
"_h": [3380.0, 0.0, 1.0, 64.0, 4095.0, 64.0, 64.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0],
"_i": [-128.86721801757812, 146.50613403320312, 3.7172875217708016e-15, 3.715873823781834e-15, 69.3901138305664, 272.08251953125, 6.903526466711099e-15, 6.900901511607558e-15, 0.0, 1.4782794866352394e-16, -1.0003803968429565, -1.0, 239.34097290039062, 177.24179077148438, 451.1508483886719, 460.20159912109375],
"_j": [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0],
"_k": [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0],
"_l": [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]},
"DrawCall": {"topology": "TRIANGLE_STRIP", "type": "SeoulMap"}} and from capture 2: {"$Globals":
{"_d": [0.0, 1.0, 0.0, 0.0, 0.007843137718737125, 1.0, 1.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0],
"_h": [2470.0, 390.0, 1.0, 64.0, 4095.0, 64.0, 64.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0],
"_i": [-37.10361862182617, 130.9170684814453, 3.3215295883745957e-15, 3.320484349717684e-15, 59.193946838378906, 82.06069946289062, 2.0819826321538367e-15, 2.0813274521691355e-15, 0.0, 1.4782794866352394e-16, -1.0003148317337036, -1.0, -264.4698486328125, -209.93690490722656, 308.6745910644531, 314.89434814453125],
"_j": [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0],
"_k": [0.0, 0.0, 0.0, 0.0, 975.0, 357.0, 2.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1170.0, 389.0, 2.0, 1.0],
"_l": [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]},
"DrawCall": {"topology": "TRIANGLE_STRIP", "type": "SeoulMap"}} Will do some investigation with those. Just FYI, I attach captured constants in text format. |
Interesting, those extra uniform seem to be present only for the ground planes, not for the building meshes, and in that case it looks like My best bet would be to use some least square regression on all matrices to extract the projection matrix. |
And some more info from smap using javscript console using chrome devtools. Seems like fov is 45 * PI / 180 = 0.785?. I could manipulate the fov using >>> application.mainMap().getView().getFov()
0.7853981633974483 // 45 * PI / 180
>>> application.mainMap().s.src.far // far and near changes with zoom in/out
66516.65499085707
>>> application.mainMap().s.src.near
6.046914858777795
>>> application.mainMap().s.src.qc // changes when window size changes
(4) [1920, 922, 0, 0] The aspect ratio should be 1920:922 then. |
Okay there was some progress.
function rdoC(a,b,c,d,e,f,g,h,k,m,n,p,q,r,t,u,v){a[0]=b;a[1]=c;a[2]=d;a[3]=e;a[4]=f;a[5]=g;a[6]=h;a[7]=k;a[8]=m;a[9]=n;a[10]=p;a[11]=q;a[12]=r;a[13]=t;a[14]=u;a[15]=v;return a}function rdoz(){var a=Array(16);rdoC(a,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0);return a}function rdrz(a,b,c,d,e){var f=b/2;b=e-d;var g=Math.sin(f);if(!b||!g||!c)return a;f=Math.cos(f)/g;return rdoC(a,f/c,0,0,0,0,f,0,0,0,0,-(e+d)/b,-1,0,0,-(2*d*e)/b,0)}pj=rdoz();
rdrz(pj,application.mainMap().s.src.fov,application.mainMap().s.src.jd,application.mainMap().s.src.near,application.mainMap().s.src.far); the matrix changes when right button is used, so the user should be careful. Also the window size must be retained. But at least the right button isn't used and window size stays the same, the user can continously capture the maps. Example:
extracted_projection_matrix_list = [1.1643550826861904, 0, 0, 0, 0, 2.414213562373095, 0, 0, 0, 0, -1.0004811657628294, -1, 0, 0, -14.763227768722993, 0]
matrix = makeMatrix(extracted_projection_matrix_list).inverted() @ makeMatrix(globUniforms['_f'])
print(matrix) Here are some concerns:
any suggestions? |
Congrats for this retro-engineering.
|
Hi minostauros! 한국분을 만나서 너무나 반갑습니다! ㅠㅠ |
@sk9288go 안녕하세요 :) |
Hi, |
HI! I have done this spring, but now it doesn't run with this error message. Can you tell me what I should modify? location: :-1 |
Importing from https://smap.seoul.go.kr/
#87
seoul map shares strategy 7 with Google Maps
Tested on Google Chrome 85.0.4183.121 (64bit), RendorDoc 1.9, RTX 3090