Texture Library

kendzi · 2012-04-12T19:16:43.000Z

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:

| “key” | “height” | “length” | “file key” | “file url”
| buildings.facade_stone | 2 | 2 | any_unique_file_name.png | http://url.to.file/

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”

marek_kleciak · 2012-04-13T05:50:48.000Z

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.

bvbmatze · 2012-04-13T07:06:26.000Z

Tordanik:

With the rapid progress of the texture repository, it’s high time for me to get textures to work in OSM2World.

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

Tordanik:

First, I do not think it is a good idea to have tags referring to individual image files. Instead, an ID should refer to a group of image files. So if an user uploads another texture depicting the same paving stone pattern (with different resolution, different lighting, optimized for grayscale rendering or whatever), these should be associated with the same id.

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?

Tordanik:

Second, the tagging should use key names consistent with the normal material tagging. One option is to always append a “texture” to the more abstract surface description, which would produce roof:material:texture, building:material:texture, surface:texture and so on.

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

kendzi:

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: […]

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:

Looking up a suitable texture in the online repository
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

marek_kleciak · 2012-04-13T09:22:22.000Z

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.

marek_kleciak · 2012-04-13T11:57:58.000Z

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

marek_kleciak · 2012-04-13T20:41:39.000Z

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.

kendzi · 2012-04-14T18:57:33.000Z

Tordanik:

First, I do not think it is a good idea to have tags referring to individual image files. Instead, an ID should refer to a group of image files. So if an user uploads another texture depicting the same paving stone pattern (with different resolution, different lighting, optimized for grayscale rendering or whatever), these should be associated with the same id.

I agree.

bvbmatze:

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?

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

bvbmatze:

Tordanik:

Second, the tagging should use key names consistent with the normal material tagging. One option is to always append a “texture” to the more abstract surface description, which would produce roof:material:texture, building:material:texture, surface:texture and so on.

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

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

bvbmatze:

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.

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.

bvbmatze:

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:

Looking up a suitable texture in the online repository

Tagging the object with the appropriate texture ID

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

vvoovv · 2012-04-15T21:12:36.000Z

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

Hind · 2012-04-16T03:28:10.000Z

vvoovv, I can write about OWT by myself.

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.

vvoovv · 2012-04-16T09:34:17.000Z

Hind:

vvoovv, I can write about OWT by myself.

Hind:
Great, just do it!

alv · 2012-04-16T19:08:53.000Z

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 Any thoughts on the numbers?

marek_kleciak · 2012-04-16T19:32:21.000Z

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

Do nothing ( done)
Do strong generalized texturing ( only 10-20 different textures for everything) Pro: Simple and easy tu understand Con: Looks like shit
Do exactly textures for every possible facade (impossible because millions of textures)
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.

marek_kleciak · 2012-04-16T19:59:29.000Z

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.

OliverLondon · 2012-04-16T20:57:52.000Z

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.

marek_kleciak · 2012-04-16T21:31:34.000Z

3 then 4 then 2 then 1

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

Under Your 5 I understood 3

Hind · 2012-04-17T06:06:24.000Z

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.

marek_kleciak · 2012-04-17T06:37:45.000Z

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.

marek_kleciak · 2012-04-20T09:20:25.000Z

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.

OliverLondon · 2012-04-20T10:39:28.000Z

marek kleciak:

3 then 4 then 2 then 1

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

Under Your 5 I understood 3

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.

marek_kleciak · 2012-04-20T11:08:32.000Z

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.