Texture Library

After topic split I’m answers hire even if it is connected with my plugin.

Example building with windows textures:

Currently textures in my plugin are assigned to buildings using tags: “building:material=” or “roof.material=”.
For example building on the right is tagged as building.material=stone and tree building on left as building.material=birck. If there is more than one texture for building material, the display one is chosen randomly from texture set assign for this material. Of course in future it will be possible to make some more advanced assign using eg colors. But I am strongly against to put inside osm database texture names.

In my opinion wiki page http://wiki.openstreetmap.org/wiki/Texture_Library sholud conteins all textures and metadata, like texture size in real world (width x hetight) without any connection to osm data.

In other hand you have wiki page: http://wiki.openstreetmap.org/wiki/Kendzi3d/textures Where you can make assigment from osm tag to texture/material.
You can do it this way:
Let’s assume that you have new building material named “stone” to which we want assign texture.
You need to create new row to table in section “Key format for building facade” like this:

After using option “Load texture from wiki” new texture should appear in plugin.

If you don’t want use wiki page to configure it you can edit configuration inside xml file.
The same example. You want to add new texture to **stone **material. You need to add this lines to xml:

You need to put this lines to file: resources\textureLibraryInternal.xml inside kendzi3d.jar or to file:
“{JOSM_DIR}/plugins/kendzi3d/resources/textureLibraryWiki.xml”
which is created and overwritten after each use of function “Load texture from wiki”

You need to manually download texture to file “{JOSM_DIR}/plugins/kendzi3d/textures/any_unique_file_name.png

The problem with wiki is the restriction: maximum 900 textures in ONE page. If we use wiki, we should divide content into many pages and use texture library only for linking to the subpages.

OSM-3D should also be supporting this rather soon (hopefully) :slight_smile:

Ok, good point, that makes sense. But what happens, if there are various images for a single ID? Is it then in the responsibility of the renderer/viewer which to choose?

Ok, we can do it this way. I wasn’t aware of the existing material tagging conventions.

I am not sure if I get your point, but this seems to me like a solution which is too much tailored for your plugin. (please correct me if I’m wrong :-))
Please don’t get me wrong, your tool is brilliant, but regarding the tagging, we should clearly go for a viewer/editor independent solution.

As always, the process of “tagging” a building texture must be as easy as possible for the mapper.
In my opinion, there should be only two easy steps:

  1. Looking up a suitable texture in the online repository
  2. Tagging the object with the appropriate texture ID

Everything else should be done by the individual renderers and the mapper shouldn’t have to care about that.
At least at the moment this is in my opinion enough to start with. In the future, further options on how the facade has to be applied, might be added (e.g. repeating the window templates etc.)

Cheers,
Matthias

I have added a naming rule to the wiki. What do You thing about it? I Think, rules for naming can be helpful for newbies for searching and adding of new elements. I afraid, we have without rules a lot of very similar textures with different names.

There [1] i describe the idea of generic texturing. The Question and research possibility is: Is it possible to generate textures such [1] from [2].
Unfortunately is the name of this page not the best. Is it possible to change the name of wiki page without changes of content? I would say, for [1] is the name Generic_textures better than recently used name.

[1] http://wiki.openstreetmap.org/wiki/Texture_table
[2] http://wiki.openstreetmap.org/wiki/Texture_Library

There are some good ideas about naming of textures. Please discuss about it, there are already some people ready to make textures. The definition of naming is here very important.

I agree.

Why don’t chose randomly from set/group. In this way each building well be looking differently?

Do we really want to assign textures id’s to osm data?

Sorry I wanted only to show how to configure plugin and test new textures. May by it shouldn’t be in this topic. I certainly should not concern those that mapping.

Why not to use tags roof:material and building:material eg.
roof:material=brick
building:material=roofTitle

Unless we realy want to use the exact texture ID like this:
roof:material.texture=brick1234
building:material.texture=roofTitle9321

Hind created a site to collect textures and uploades some Russia-related textures:
http://openworldtextures.org/

vvoovv, I can write about OWT by myself. :slight_smile:

This is not for Russia-related textures only, but for all. Try to upload, then you see it. :3
Also, there is only public domain textures now.

Hind:
Great, just do it! :slight_smile:

So, umm.

When I was driving the car today, I tried to look at some buildings, and thought for a second what it would take to make a good texture for it. There’s so much variation, that most buildings need several different “tiles”, and they’re hardly ever reusable in other buildings. But maybe you prove me wrong :slight_smile: Any thoughts on the numbers?

Thats true,
I wrote already in the Russian Community: we have 4 possible ways:

  1. Do nothing ( done)
  2. Do strong generalized texturing ( only 10-20 different textures for everything) Pro: Simple and easy tu understand Con: Looks like shit
  3. Do exactly textures for every possible facade (impossible because millions of textures)
  4. For typical, not so important buildings the use of multitexturing=background texture and exactly positioned doors, windows and other elements. Pro: Few hunderts of textures are enough Con: The software for should be developed first.

I think, 4 is the good answer and for very important and known unique buildings 3.

Guys,
take a look: http://scenery.x-plane.com/library.php?doc=about_facades.php
This is approach no. 2.: Nobody see, the textures are generalizes, on the first view from top it looks absolutely cool, but when You´re on the street with mobile navi or augmented reality, You are unhappy about results You see.

Isn’t there a final option 5, which is to take a photo of the building and warp/fit it to the building model (as seen in Sketchup). I guess this is doable for the most important buildings, then we default to 3 then 4 then 2 then 1.

Hi Oliver, could You explain it again with other words?

Under Your 5 I understood 3

Sorry for my english :3
I think that the multitexture should be described by a formulas containing a placement algorithm and an occurrence frequency of each subtexture.
Also, subtextures can have an alpha channel for soft mixing with background subtexture or just for adding individual details like as air-conditioners and graffities. :smiley:

Of course Hind.
One thing more:
I still think about composite textures. Let me a little time, I describe the idea detailed and email it to You and other interested people.

I wrote the page:
http://wiki.openstreetmap.org/wiki/Seamless_Textures

I hope sombody can help to translate it into enlish. Hind, Could Yo translate it into russian and put Your input? I mean, You´re verya professional with texture making. Maybe you have some comments, references? Please feel free to add information to this page.

Under 3, you are still talking about “textures”, which could still be small images used to cover the walls of the building. These could be “picked” from a photo of the building, but we wouldn’t be using the whole photo to cover the face of the building. That is the difference I meant between 3 and 5. If/when this gets written up in the wiki, we should reorder these to go from simplest / most general to hardes / most specific.

You´re wright. We have to make difference between repeatable small textures (“seamless” textures and phototextures)
“phototexture” means: unique pict (prepared photo) without repeating per each facade.

If possible to You - lets´c come togeteher on the weekend to sketch up the specification/description for the wiki.