Download 3d google maps for blackberry

By joining Download. Free YouTube Downloader. IObit Uninstaller. Internet Download Manager. Advanced SystemCare Free. VLC Media Player. MacX YouTube Downloader. Microsoft Office YTD Video Downloader. Adobe Photoshop CC. VirtualDJ Avast Free Security. WhatsApp Messenger. Talking Tom Cat. Please check settings. Hi, I liked your post. Wanted to check if google hangout can also be installed in BB10 same way?

From where the. How can I download the installer? Please help. Please help with solution. Are you kidding me? I can install using android apk without any hassle, why go through all this hassle?

Search Search for: Search. Switch skin Switch to the dark mode that's kinder on your eyes at night time. Switch to the light mode that's kinder on your eyes at day time. Raise your voice Cancel reply. How do I install on my bbz We did not have to look at the Archive. The code was easy to read, the data all in one place. We did not have bad surprises with the buffers decoding. So getting data out of the Marmoset Viewer was a good introductory exercise, but things are going to get wilder with Sketchfab and even worst with Google Maps.

After this exercise, you may be tempted to write and distribute a little script that basically convert a mview file into an OBJ, or any other format. I must argue against that. I am not concerned about the Marmoset company, but about the community of creators who rely on these great platforms to showcase their work. It is possible to get their work, this post shows it, and it would be absurd to try to hide it, but it is nevertheless not a reason to make it accessible to random script-kiddies.

The rise of platforms like Sketchfab is a good thing, and although I believe in open content, I also know that 3D content creation is not the most financially rewarding occupation.

So please don't do that, by respect to the creator's work. And anyway, you would not be allowed to use it for anything, legally speaking. We are carried away by our success with the Marmoset Viewer and now want to get some 3D models from Sketchfab. Let's try for instance with this construction vehicle that I bought beforehand. We can start by applying the same recipe as with the Marmoset Viewer.

Open up the network inspector, and load the page. The first thing we can notice is that the viewer implements a progressive loading:. So we can already be sure that the data does not come in a nice single query like a mview archive. On another hand, we also see that each texture is loaded as a regular file that can be easily saved.

The heaviest query is a 2 Mo. The bin suggest that it is a binary blob, likely to be 3D data, and the. It means that the file is compressed with a standard gzip algorithm, which can be uncompressed by 7-Zip , for instance. This is a cubemap, a lighting texture surrounding the scene, not our geometry.

We will look for other such compressed files, and in particular filter queries by type to keep only those fired by "XHR", the XMLHttpRequest object we already looked at with Marmoset. Another noticeable file is file. How interesting! What is convenient, is that the OpenSceneGraph format uses terms very close to OpenGL vocabulary, so we might not need to look at the viewer's code!

This is cool, because if you were afraid by the 6k lines of Marmoset Viewer, you are not going to love the 60k lines of Sketchfab's one. It occurs 17 times, so it must actually contain a concatenation of all the buffers of the scene.

The suffix of the DrawElements sections specifies the bit depth of the indices in the index buffer. Let's consider for instance the first one:. To test this, we must find the point attributes used in this call. But there are 6 occurrences of VertexAttributeList.

To determine the one to use, it must be in the same Geometry node, so likely the first occurrence after the DrawElementsUInt will work. This will select the whole Geometry block, and you'll know where to look for the appropriate VertexAttributeList. There are items. Each item has 3 component. But what component? Integers, Floats? Encoded on 16 bit, or 32 bit? Since the word "stride" doesn't appear anywhere in the file and all attributes start at different offsets, we can conclude that Sketchfab viewer or OSG.

JS, should I say uses the data layout that I called "A" above. In this case, the stride is the size of the item. Regarding the component type, the mention to Int32Array suggest that they are 32 bit signed integers.

This really doesn't look like a truck. As it turns out, I underestimated the "Encoding": "varint" line. This is an encoding used to represent series of integers in a more compact way than just concatenating them. Well, Marmoset vertex attributes were not compressed; here they are compressed twice!

We can find details about varints here. So I made a little varint. Still not working. I performed some basic checks with my varint decoder, and in particular when I decode the TexCoord attribute, the decoding process stops right before the offset at which the Vertex buffer starts, so this must be right. I did not want to do that at first, but I ended up reading the viewer's source code.

I found the varing decoding function line and it matches my implementation. I found bounding box correction, I read the vertex shader. Decoding the index buffer seems complicated as well. The index buffer includes a header, and my attempts to get something out of it were unsuccessful. So, shall we give up? No, I think it is time to step back a bit. We focused on trying to decode the data as it comes from the server, when it first reaches the client's computer.

But instead of mimicking the data decoding process performed by the viewer, couldn't we let it do its job and extract the data after this is done? Intercepting the data between the server and the viewer was convenient, because the network monitor gives us direct access to all the resources.

But once in the memory of the JavaScript VM, it is not so easy to to extract it, even with the Memory Inspector provided by the browser's tools. Furthermore, some of the data handling is done in the vertex shader, so on the GPU. This will hence never be accessible from the browser. This is where RenderDoc comes in. Think of it as the browser's developer tool, but for monitoring the GPU. RenderDoc records all the calls to the graphic API and their arguments, so that it is able to fully replay it and inspect it step by step.

NB RenderDoc is not intended to be used as a hacking tool, and is not supported for that. It is a GPU debugger, but as a side effect of being a good debugger, it gives us access to the data we need. Before trying more complicated stuff, it is good practice to start with a simple example. I will use for this an OpenGL 4. Its render function is very minimal:. We build this, then launch it with RenderDoc. The application will run with an overlay with information about the graphical API in use OpenGL, here and the frame number.

As it says, press F12 to capture a frame. In the RenderDoc window, the capture appears, and you can double click to open it. You will then see the list of rendering "events" in the Event Browser window.

We recognize our calls to glClear and glDrawArrays. The buffer swap is done in the main loop, by glfwSwapBuffers. And what about the glUseProgram for instance? For some reason, only calls that affect the framebuffer are displayed here, but you can see the other calls when selecting a line in the Event Browser.

The other key element of RenderDoc is the Pipeline State panel. It describes the state of the GPU's rendering pipeline during the draw call. The first step, VTX, describe the draw call input, so the vertex attributes, and the topology. Exactly what we were looking for! In this example, there are two attributes, vPosition and vColor. There is no index buffer, because glDrawArrays is not an indexed draw call. It assumes that the index buffer is [0, 1, 2, The right arrow in the vertex attributes array leads us to the Mesh Output panel, and there is again good news here.

This panel shows all the values of the input vertex attributes, but also the output of the vertex shader! And we can easily save them to disc. We now know how RenderDoc works, and we have an example to experiment with set up.

But let's head back to our original problem. We need to capture frames in the browser. Logically, we try to launch the browser from RenderDoc, as we did with our little test program.

Unfortunately, this does not work, neither will it work with other browsers. I am not sure exactly why, but the use of process forks and some other advanced mechanism must loose RenderDoc. Since RenderDoc needs to get attached before any graphical operation is initiated, we will use the --gpu-startup-dialog argument available in Chrome. It opens a popup telling on which GPU chrome is running, and does so before initializing the graphics. So we can launch chrome, attach RenderDoc, and only then press the Ok button on the popup.

For convenience, I created a shortcut with the target:. It is important that after the injection, and after you validated the popup, the status box in RenderDoc shows something different than None in front of "API:". Now, open the Sketchfab page of your choice, and take a capture using F To ensure that the capture will include the part about the 2D model, turn the 3D view at the same time. This way, the GPU will have to recompute it. This time, the render events list is much longer than in our example.

This may vary, but I have calls to the graphics API recorded, organized in many passes. If you have significantly less events, or just a single render pass, this might be that you captured a compositing pass, drawing the UI of the browser instead of the viewer events.

There are many draw calls. Some render the same list of attributes, with the same index buffer. Typically, the first pass, or the two first passes, are rendered from the position of the light, and used to compute the shadow maps. Track the draw calls that use all the textures, using the Texture Viewer panel. In my case, it is in pass 3. My pass 3 has 5 draw calls. The last one has only 4 points, it is the ground plane. The previous one are the two parts of the mesh, with for each one a triangle strip followed by a triangle list to fill the holes.

This matches the description found in the JSON file. Note that the vertices in the CSV are sorted, and potentially repeated, according to the index buffer, so you don't have to worry about this.

This is a very basic algorithmic exercise: given a list of indices [1, 2, 3, 4, 5, 6, 7, Note that the second triplet is 3, 2, 4 and not 2, 3, 4 in order to preserve the face normal. Every odd triplet must be reversed like this. Once again, I don't want to make it easy for anybody to download models from Sketchfab, so I won't provide any full-featured script. I will have less concern regarding Google Maps.

If you are publishing content on Sketchfab, you might be a bit worried. But don't worry too much. It is still a lot of work, and skilled work, to steal your models, so in many cases if you sell your model at a reasonable price it will remain more expensive for a company to steal than to buy. And it gets even more complicated when your model is animated, or uses advanced rendering effects.

If you really freak out, add watermarks directly on the textures of the model. Of course it does not protect the geometry, but what is a geometry without its texture? Especially if it is a low poly on which a high definition model has been baked. If you sell point clouds from 3D scans, don't include all the points in the WebGL preview, or maybe show the true density only on one part of it.

If you sell triangles, cut you mesh into many little meshes, it'll get longer to retrieve it. I don't know, get inventive, or trust people. Anyway, it remains illegal to use your stolen models, which adds another cost to the thief. Which data bottleneck should we focus on? The main difference between Google Maps and the previous examples is that Google Maps never loads the full 3D model of the whole world , obviously. Instead, it uses a powerful Level of Detail LoD mechanism and streams the geometry at a resolution depending on the distance to the view point.

There may be more than 10 levels of details covering a well scanned area. Ideally, we would prefer to find how to decode the queries, and even how to emit them. This way, we would be able to query the higher resolution models for a whole region. This never happens in practice, because of the LoD mechanism, so intercepting the data when it reaches the GPU does not allow for this. At least, not from a single capture.

When one moves around in the Google Map's 3D view, data comes in a lot of little queries encoded using protocol buffer and raw octet streams, which are very dense and so hard to decode without the format information. It does not contain meta information like the data keys of a JSON file.

So it is capital to hand on the source that decodes this data. But if you got lost while analyzing Sketchfab viewer's code, you'll never come back from Google's code exploration. Google uses a lot of optimizations that make their code totally obscure.