How to generate VEF files?

[fnicollet]

Hello,

I am not sure where to post this question, so i'll try here, feel free to move it around.
In the "cadastre" tutorial, you download some VEF files (jenstejn.vef.tar / jenstejn-village.vef.tar) from melown's CDN.
These VEF files seem to be textured 3D models in the VEF format/spec "True3D". I understand you are working with your own 3D format, but how exactly do you create these VEF files? I looked into GDAL and couldn't find anything (not very surprising though).
In your demos, you have whole cities as VEF files, so you must have converted open data somehow to VEF.

Can you give me some hints please?

Thanks,
Fabien

[ladislavhorky]

Hi Fabien,

the cities are not open data and actually came out of our photogrammetry software. We just released few of them under 'CC BY-NC 3.0' licence for the purpose of demos and tutorials.

The VEF format (see spec https://github.com/Melown/true3d-format-spec) is an open interchange format for 3D data. More specifically it is a thin wrapper around a bunch of textured hierarchical georeferenced meshes.

Ladislav

[fnicollet]

ok, the spec is open, which is a good thing, but then how do you generate these VEF files outside of your photogrammetry software? Or is this VEF format reserved for your own use (and your commercial activity is based on creating those VEF files so you would rather not share)?

[ondra-prochazka]

Hello Fabien,

Quite the contrary, we encourage people to use VEF in their own software. Compared to some other formats used essentially for the same purpose, VEF is lightweight and easy to work with: it is basically just Wavefront OBJ mesh with some JSON geospatial metadata, optionally multi-resolution and optionally split into multiple files.

How you generate it depends much on where your data comes from. For a simple mesh, you can probably do it by hand. For a more complex input, you can implement your own VEF writer based on the spec. If there is use case for such a writer outside the scope of photogrammetry (production of 3D city models from aerial images), we might even look into doing it ourselves.

[fnicollet]

Thanks for your input on this :).

I am not sure yet what kind of 3D data it would be, as it would be provided by our customers, so it can be shipped in various formats (LIDAR LAS files, shapefiles with elevation data, OBJ files, DXF, CityGML, etc.) and we would need to be able to answer as if we could support it or not.

Let's imagine a simple use case of new building implementation. We would need a 3D scene with global elevation surface (like the viewfinder dataset your provide), the building might be published as a OBJ file, and we would need to display just the height of the buildings in the area (as simple extruded polygons for instance).

Right now I would say that I don't know how to do any of it :).
Even if the VEF format is a rather simple spec, I wouldn't know where to start. There are come CPP files in the repo, probably to encode them but we are mostly a Java/JavaScript team, so I don't even know what it really does or how you would create a " OBJ mesh with some JSON geospatial metadata"!

Fabien

[davidmtech]

Hello Fabien,

there is new tutorial which demonstrates how to import OBJ models on the client side and display them in the map. It may be interesting for your case. Processing OBJ models on the client side works good for models which are not very memory intensive, but in most cases it should work very well.

David

[fnicollet]

Thanks, that's a very interesting tutorial, it could indeed be useful for small objects

…

On Wed, Oct 4, 2017 at 5:32 PM, David Levinsky ***@***.***> wrote: Hello Fabien, there is new tutorial <http://vtsdocs.melown.com/en/latest/tutorials/importobj.html> which demonstrates how to import OBJ models on the client side and display them in the map. It may be interesting for your case. Processing OBJ models on the client side works good for models which are not very memory intensive, but in most cases it should work very well. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#17 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABLtoT3RSld2Pr4HO34fJkYJ7gKkSACoks5so6UNgaJpZM4OlSqi> .

-- Fabien Nicollet Tel : +33 (0)6 60 54 72 20