Texture Library

marek_kleciak · 2012-04-12T07:56:00.000Z

Hello bvbmatze,
good ideas, agreed
Please collect ideas for the naming. It´s not so easy. In particular, if we want keep it simple. I believe, we need something like texture=brick12345, because there are damn lot of different brick types. What about colors? The same patterns have many different colors…

The page is just the beginning: I think it´s important in the next days to generate some nice examples for the community, because the most user can not SEE what for fantastic possibilities are associated with it.

vvoovv · 2012-04-12T10:36:02.000Z

I think the Texture Library deserves a separate topic. So I created one. Marek you might wish to extend the first message in the topic.

marek_kleciak · 2012-04-12T16:03:28.000Z

Well,
we have 50 textures in 3 days.
We should think about server and namig of textures.
At the moment it is my free improvisation.

Tordanik · 2012-04-12T18:23:24.000Z

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

bvbmatze:

Now it’s just a small step to allow assigning these seamless facade textures to buildings
via OSM tags, isn’t it? Something like building:facade:texture=brick1, roof:texture=tiled1 or similar…

What do you think? There could be just another column in the table at the wiki page for defining the corresponding tag.

We can try something like this, but I have some comments regarding the tagging.

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.
The motivation for for not just replacing the existing image with the “better” texture is that “better” depends on the application - some time in the future you might even want to be able to upload .pov files for raytracing, or an intentionally cartoon-styled set of textures, or any other texture variants. But this should not affect the OSM database. Instead, the tagging just refers to the image group, and management of the variants is handled by the image repository.
In the short term, this means that we can of course start with another column in the table at the wiki, but with the understanding that the ids listed there are not supposed to be uniquely referring to a single image file.

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.

An issue might be the storage location of the image files, the wiki is certainly not the most sustainable option.

It’s clearly not an ideal solution, it just has the simple advantage of being available right now. A more elaborate solution would be nice, but somebody would have to set it up and commit to maintaining it.

marek kleciak:

What about colors? The same patterns have many different colors…

Yes, we probably need support for that, too. One option might be to use a grayscale texture for the pattern, and apply a shader to combine it with the base color from the building/roof:colour=* tags. I would need to try this to find out whether it looks good.

marek_kleciak · 2012-04-12T18:50:29.000Z

This project is pretty big. I think, it would be great to speak about possible solutions in the small group of interested experts. Maybe end of may? The next questions are:

1- Transparency of textures
2- Multitexturing
3- Cooperation in developing of software

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