Manage textures in Inexor Flex

[aschaeffer]

Refactoring of the loading mechanism of textures and maps in order to use the Inexor Tree. This way we can automate the media management and provide user interfaces for creating or editing meta data of textures and maps.

Inexor Flex

• [x] Create a data structure for textures in the Inexor Tree
  • [x] Texture filenames (fully resolved absolute paths)
• [x] Create a TextureManager component for Inexor Flex
  • [x] Resolve textures from media repositories (filesystem / git / http+rest)
  • [x] Populating the Inexor tree
• [x] Create a data structure for maps in the Inexor Tree
  • [x] Map filenames (fully resolved absolute paths)
  • [x] Map configuration (from TOML)
  • [x] Textures
  • [x] Texture
    • [x] Address (tex-author, tex-name, tex-version)
    • [x] Texture configuration (scale, rotation, ...)
    • [x] Shader (shader-name, shader-params (glowcolour, ...))
• [x] On map load copy/mount the map information into the instance tree

Inexor Core

• [ ] Use the package.cfg in each directory to load the textures
• [ ] Load map configuration from the Inexor Tree
  • [ ] Map configuration
  • [ ] Map vars (skylight, ...)
  • [ ] Textures and texture configuration
  • [ ] Load textures
  • [ ] Read texture filepath from the Inexor Tree
  • [ ] Load textures from filesystem into gfx memory
  • [ ] Link the named shader
  • [ ] Add the shader parameters

[aschaeffer]

Layed the foundations

[IceflowRE]

Will this manager, manage missing textures from user made maps too? And send those to other players as well? (Only if you join an online match on this map of course.)

[aschaeffer]

@IceflowRE: This is our plan for resolving missing textures / media files in general:

• The media files (textures, models, maps) will be provided by media repositories. The media repositories can be either local (local filesystem) or remote (via git or http+rest). Remote repositories can be added and the content is fetched and stored locally. An updating mechanism fetches changes from the remote repository to the local copy.
• The media files also have meta data (like description, author, version, ...) and dependencies. For example: map A depends on texture B in repository X and texture C in repository Y.
• During map loading Inexor loads the texture from the local copy of added repositories. If a texture is referenced from a map but the texture is located in a repository which is not available locally, Inexor suggests you to add the remote repository.

It's also planed that media files have a version history, so a map A depends on version 2 of texture B, but map B depends on a newer version 3 of texture B. This way textures can be improved without breaking the look of a map.

[aschaeffer]

Added an update mechanism for git media repositories

[Croydon]

map.json -> #39

[aschaeffer]

https://github.com/inexorgame/inexor-flex/commit/8b92c2cc6b3f68a4248f82754047d1ded9b83c2f

Now we need a possibility to synchronize the tree nodes to core (using list sync?)

[a-teammate]

yay :)

In core the first step will be to just use the package.cfg in each directory to load the textures from there on. The second step will be the harder part (and we probably can leave it open for a while): we need:

• all basic info in the tree loaded by flex
  • scaling, rotation, .. (this is for orientation on the cubes)
• the shader name
  • i think: the name is enough for now, no uuid
• the shader parameters
  • each shader can individually have different settings attached (e.g. glowcolor for the glowworld shader)
  • i'd say: just copy them for now
    • for a linter or an UI, which automatically hints shader parameters, should be another issue

at that point we are at: "just load it from the tree. textures into gfx memory, link the named shader, add the shaderparameters"

[aschaeffer]

I've updated the issue description with your input

[MartinMuzatko]

In order to make the most out of textures, they should have further data attached. This would be very beneficial for sorting/filtering in e.g. the texture browser

Some properties can be inherited from the package (e.g. author, package name) some have to be defined on a per texture base.

• materials (wood, metal, glass, detail, grass, rock, snow, moss, etc)
• usage (trimming/border, detail, surface, terrain, etc)
• theme (modern, medieval, space, etc)

These properties need to be maintained on a per texture base, but the benefits would be immense. Sorting and filtering textures fitting to the current map is only the beginning. By attaching these attributes to textures, it is also possible to derive other properties like footstep sounds, durability or similar.

Also, an ingame texture browser could also allow attaching these informations, so there is no need to do this in configuration files only. This can be done as a community effort: if every texture is publicly available, users could also attach their information with it in a pull-request-like fashion.

Furthermore, if we make the octree with the used textures available in the tree, we could even let users explore how other users used a certain texture in a map for inspiration.