Kendzi3D - 3D Viewer as plugin for JOSM.

Please repack file
/home/matthias/.josm/plugins/kendzi3d.jar
Inside this archive copy file /resources/log4j.properties to location /log4j.properties

Run JOSM in console as before and send logs.

Is anything displayed inside Kendzi3D window?

Back at home I could download the plugin without any problems. Maybe you can host the Kendzi3D where the other 2 plugins are hosted.

Plugin was moved to different hosting yesterday, so it should work. I will move preset tomorrow.

Thank you! But now at home I can’t test it by the other internet provider. Here the download work well and openstreetmap.org.pl is working too. For me it was interessting that I could donwload too plugins and but not the third main plugin.

For me it is mystery why it wasn’t working. Where was complaining from other people too. But it is problem with hosting. I hope that new location will work better. I will move all files in few days.

Hy, one question about the dormers:

What if the dormer don’t start at the edge of the roof. With the roof rows it is not optimal. it seems that there are only 5 rows possible, so i can let start a dormer at only 5 different points. it would be better if i could set the value in meter.
there is a tag in wiki:

http://wiki.openstreetmap.org/wiki/DE:3D_building/Dormer#Eigene_Gauben

3dr:dormer:1:depth=1m but it seems that it is not supported in the viewer.

EDIT:
i’ve seen you support several tags ‘…:color’. i think in OSM there is always used ‘…:colour’, the british notation.

I currently read only 5 rows. How many rows should be allowed?

This way of tagging dormers was shown as idea and it hasn’t been implemented yet. It is base on dormers index and maybe it isn’t best way to do it. If you have any ideas please write them on wiki in discussion tab (best in English).

Yes officially it is used colour tag in OSM, but many people use color so I support them both.

I don’t know if more than 5 rows are needed. but with this kind of tagging i could only split the roof in 5 parts, where I can place the dormer.
For example if I have a 5 meter roof and the dormer is 1m away from the edge, I have to place the dormer in row 2. and I have to set a row 5 with no dormer (‘3dr:dormers:front:row5=-’). if i don’t set row 5, the row 2 is in the middle of the roof.
Because of this I meant, setting the distance from the edge in meters with a tag would be better.

There are few things to work out with dormers. Currently the easiest way is to add tag 3dr:dormers:front:row5:depth for entire dormers row. We need to work out easy way to add custom tags for each dormer. Some time ago someone proposed to use nodes for dormers.

I for some time try to focus on adding new roof shapes and editor capabilities. So it is good time to write down some ideas about dormers.

New things:

  • Holes on flat roofs:

  • new half-round roof (5.2)

The round depends on roof:height tag.

In next release I will change behavior of roof:direction tag. Currently it is pointing form left to right side of building. After change it will pointing to roof front. As it is discussed here.

In current version v169 I added support for multi-layer texture. Netzwolf prepare multi-layer texture for colored brick. Currently it is possible to change only background color and color of mortar between the bricks can’t be changed. But it looks much better then old brick texture.



Currently roof parts of wall aren’t using new textures. Comparison between old and new textures:

Short description how to configure textures.

I hope Netzwolf prepare some more textures :wink:

There is also a roof:slope:direction (used by osm2world). Is this the same?

Chris

Currently it look like this:

roof:slope:direction tag should be interpreted the same as in Osm2World

Does lighting of the mortar between the bricks work correctly for you? If yes, how did you solve that?

That image is not correct regarding roof:slope:direction. The tag is currently only used for one roof shape in OSM2World, skillion/monopitched, where it is identical to the definition roof:direction for that roof shape: down towards the front.

If we agree to introduce roof:direction, I think roof:slope:direction will become redundant. I would continue to support it for backwards compatibility for a while, but discourage using it further, as it was never properly documented anyway.

Edit: typo

I didn’t. I think that can be done using two over layers for mortar. First combine (interpolate) alpha and color and on second combine lighting and alpha. But glTexEnvi is deprecated and in modern OpenGl this is solved by shaderes. So I don’t plan currently adding two over layers for mortar and windows.

But even without proper lighting new multilayer textures look better then old ones.

Nice description of glTexEnvi is here.

I didn’t understand your description here of this tag. I fixed image and I will fix it in my application soon.

After few trials it can be done using glTexEnvi But you can’t use ambient or diffuse color for coloring textures.

I archive this using one additional texture unit:

  • Unit 1
    Interpolate texture color with texture

  • Unit2
    Interpolate over-layer with previous result using alpha

  • Unit3
    Multiple by lighting (environment)

Result:

Advance of this is that it use transparency exactly like in Netzwolf css example.

  • In last version of plug-in was added support for basic roof lines:

It is very basic support for roof line tagging schema. I’m using algorithm invented by Tordanik. Which is really nice. Triangulation code come from hjanetzek. So results should be similar to O2W. It would be nice to known if you find some non working examples.

  • Basic editor for building height. It still need lot of work but it should be possible to use it.

Hy, i think it would be a good idea to set an default height for building=garage that is smaller than the default height for buildings. 2,5m for example.

Yes. May I suggest 2,70? this Height includes roof construction.
Best regards,
Marek

Hi guys, I hope it’s correct place to discuss this issue.

Kendzi 3d plugin is nice, but there is also a big problem.

Kendzi 3d extrudes the third dimention from the building outline (polygon or multipolygon with building=yes+building:levels) even if there are building parts (polygons or multipolygons puilding:part=yes), inside this building.

In the Simple_3D_Buildings http://wiki.openstreetmap.org/wiki/Simple_3D_Buildings it is stated that it should NOT be done:

As the result, some buildings are rendered correctly in F4 and completely wrong in Kendzi 3d:
Examples:
http://www.openstreetmap.org/browse/relation/2888456
How it is now:

How it should be:

(I’ve just removed Building=yes from the outline)

How it looks in F4
http://map.f4-group.com/#lat=56.3297870&lon=43.9981890&zoom=19&camera.theta=55.764&camera.phi=-160.715&la=la

Is this a known problem? Is it possible to fix it?

It’s important, because the common practice is to map the building outline with polygon with building=yes for 2d renderes, and add to the building=yes tags for the total height of the building and its total levels, even if the building has complex shape.

F4 map try to automatically connect building parts with outline and remove outline if it is not necessary. In kendzi3d you need to add all parts and outline to relation type=building then you should get the same result.

Example:
http://www.openstreetmap.org/browse/relation/3208173