Kendzi3D - 3D Viewer as plugin for JOSM.

There is also a case when building:part=no. Please consider it also :wink:

Tags building:part=no and building:parts=* were added in v224.

I don’t see rendered building:part=yes (without building=yes) in v224, only building=yes (without building:parts=) and building=yes + building:part=yes (without building:parts) are rendered.

Check in v226, if it isn’t working please send example.

Hi kendzi,

There is menu item in the plug-in “3d->Adv->Export models to files”. Does it work? I only get message about unexpected error…

Is it possible to support *.x file format as export format?
http://en.wikipedia.org/wiki/.x
http://msdn.microsoft.com/en-us/library/windows/desktop/bb172982(v=vs.85).aspx

I need models in x format because, because models in this format are required for the CityGuide. CityGuide is navigation program with support of OSM-maps, it is capable of 3d rendering, but it requires models in this format.

I am now searching for a way to obtain models from OSM, at least for the most notable buildings.

This option should work. It provide very basic support for exporting models to collada file. Output location is hard-coded to C:\out\export.0.dae /multiText/out.dae. Output directory have to exist before you start export.

If it is not working please send me an exception.

The bigest problem with exporting models from application is that I’m using multi-layer-textures for windows or colored walls. Unfortunately I didn’t find any universal 3d model format which support it. It is theoretically possible to do with collada, but non of viewer I test is supporting it. X3D file have support for multi-layer-textures but it don’t work with blender or few viewer I test. The most popular 3d file format like OBJ don’t support multi-layer-textures at all.

I check X-file format, it seam like some binary blob from Microsoft DirectX, I don’t plan to add exporter for it, but it should be possible to convert it from collada to X.

So if you have any idea witch file format could be used, please write.

Documentation on MSDN is very unfrendly. There is several variants of format, both binary and text - http://msdn.microsoft.com/en-us/library/bb173014.aspx
Check also these page with examples of it:

http://paulbourke.net/dataformats/directx/
http://ru.wikipedia.org/wiki/X_(%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%82_%D1%84%D0%B0%D0%B9%D0%BB%D0%BE%D0%B2) (in russian)

I fount this plug-in for blender to export x files. You can easily import my collada output to blender.

Are you sure that CityGuide is not supporting OBJ files?

Because I would rather add OBJ exporter then X file. Obj format is much more common and better documented.

I get the following error:

There is API, which accepts only *.x format. But i guess I can convert from OBJ, if I get OBJ output.

I exporter is fixed in v231. You can try convert output to x using blender.

I saw discussion about hipped roof:

Both roofs you can test in kendzi3d:
First example can be tag with roof:shape=hipped. It generate square like roof even for non square building outline. Maybe it should be named square hipped?
Second with tag roof:shape=9.0. It generate roof with const angles. For square like outline, output will be same as for hipped roof.
Roof type 9.0 need some better name but I don’t known how it should be named.

Please test them.

Kendzi,
o-sewa ni narimasu I am your debtor.
Export to collada works, and I even can open results in Deep Exploration. I still need to do some testing, but looks i can do what i need)


The first pic is rather about translation of the word hip into russian.

if you ask my opinion, it is quite simple:
what is now called hipped should be renamed to primitive_hipped or be dropped. I do not know any building to which it can be applicable.
roof:shape=9.0 should be renamed to hipped. It is realy what is needed.
It also works with simple rectangular buildings.

Both buildings on the screenshot have roof:shape=9.0, but should have roof:shape=hipped.

I think, that it is incorrect rendering. When I write building:levels=1 + roof:height=3, I want to say, that building have one level and roof with height with 3 meters, and a roof is above base of building. I think, that approximate height of building (if there is no roof:height building:height or height) should be calculated as building:levels3 + roof:height (or roof:levels3, if there is no roof:height).

However if there are building:height=10 and roof:height=3 it should mean that total height of the building is 10, not 13.

How it should behave when there is only building:levels tag?
What if it is building:levels and roof:angle tag?

I guess that those are questions with no true answer. I also do not completly agree with Dinamic. 3 meters most probably make a story :slight_smile:

Please consider the following buildings:

is it a levels=1 or levels=2?

this one is definitly levels=1

I think it should be tagged with
levels=1 and roof:levels=1

levels=1 and roof:height=0.5

In case when height is not setup:
when there is building:levels and roof:levels tag kendzi3d behave exactly how you described.

when there is building:levels and roof:height tag, I thing it be should as it is. So roof height is sub from building height calculated based on levels. But maybe some one have any other idea?

What will you say, if I show you another buildings?


Do you want to say, that tagging building:levels=1 + roof:height=2 is wrong?

Do you want to say, that such model (tags building=yes + building:levels=1 + roof:height=2 + roof:shape=gabled) is correct?

What about this:

is it building:levels=0? :wink:

In my opinion building:* tags should express overall stats of a building: total height and total number of levels, including attic/loft

I think this is building:levels=0 and roof:levels=2 as described in Wiki.
building:levels is used 2 054 368 times on a way. If you want to change this, there are many buildings to correct…

It is building:levels=2 or building:levels=0 + roof:levels=2.

Note, that the upper point of normal level (where people can live) can be lower, than upper point of building. And the difference is usually equals namely roof:height.

I think in such manner:

  1. if there are N levels (both building’s levels and roof’s levels), we should write building:levels=N or building:levels=K and roof:levels=M (N=K+M, because roof:levels is “number of floors within the roof, which are not already counted in building:levels=*”).
  2. if height of roof is 2 meters, we can write roof:height=2 (if there is also level in the roof, we can also write roof:level= ).
  3. So if building has 1 level and roof with height 2 meters, it is correct to write building:levels=1 + roof:height=2. And exact height of all building in this case is “average height of level”*“number of levels” + “height of roof”.

Algorithm “we think, that height=building:levels*3” is wrong, because it doesn’t take into account, that building can have roof with height, but without level!


Kendzi 3D v242 doesn’t work with wall=no and building=roof.

left building:

right building: