Content repository

Contribute models, textures, concepts and sounds here.

Moderator: PPS-Leaders

User avatar
x3n
Baron Vladimir Harkonnen
Posts: 810
Joined: Mon Oct 30, 2006 5:40 pm
Contact:

Re: Content repository

Post by x3n » Fri Jan 28, 2011 12:52 pm

Nice to see this topic coming up again.
we could try to use symbolic links to link files which are used in multiple textures
I'm unsure if this works on windows. I'd rather say we copy files if they are re-used. Because if you build a texture based on an image, which is also used for an other texture; then someone changes the image for the other texture, it could mess up your texture. If you copy the image, you have a defined state which should be preferable in most cases.

For textures we could also collect different layers for shaders, for example the bump map, etc.


about the naming convention: well, is it really that important? I mean it's like in coding, you shouldn't name a variable "a" or "v1", but apart from that it's rather unimportant, as long as it's understandable. "numberOfBots" or "botCount" or "numBots" or in some cases even "bot_count" are acceptable names for the same thing.
Same holds for models, textures, etc in my opinion. It shouldn't be named "spaceship.mesh" for sure, but something like "heavy_pirate_fighter.mesh" is ok. Maybe someone builds "heavy_pirate_fighter_2.mesh", but thats still ok in my opinion. Others prefer camelCase and some people may put the name of the ship or the author in the filename. As long as it's distinguishable it's ok for me.


about the info file / list of references: well that's new, at least for me. what's the reason for this? textures are listed in a material file, material files are listed in a mesh file... do we really require an additional file?
Fabian 'x3n' Landau, Orxonox developer

User avatar
greenman
Baron Vladimir Harkonnen
Posts: 360
Joined: Wed Oct 03, 2007 2:53 pm
Contact:

Re: Content repository

Post by greenman » Fri Jan 28, 2011 4:55 pm

i think at least for models it's quite annoying to get textures / texture file names out of a mesh file ?! that's why it would be nice to have a reference file with the path for textures and other dependencies in it.
There are only 10 types of people in the world: Those who understand binary, and those who don't.

User avatar
x3n
Baron Vladimir Harkonnen
Posts: 810
Joined: Mon Oct 30, 2006 5:40 pm
Contact:

Re: Content repository

Post by x3n » Fri Jan 28, 2011 5:12 pm

yes true, but why do you need to know the textures used in a model? i don't really see the benefit of it. of course there are a few cases where it may be helpful, for example to build a minimal data repository with only a few models and the associated textures. or maybe if you delete a model, you want to delete its textures; but if we use generic textures (metal, etc) textures are re-usable anyway. I just feel like it's a lot of work to write and maintain these files, with little to no benefit.

additionally, if you use a texture with bump maps, do you need to refer to the texture image and the bump map image separately? or do you only refer to the material file? because I assume the names of the used material files are easy to extract from a mesh file.

because assumptions aren't really helpful, I just had a look at a .mesh file. They're encoded, but the names of the materials are clearly visible right at the beginning of the file.

However the material's name is not the filename. But that's a common "problem" (or let's call it difficulty) with materials which exist in the virtual space of ogre resources.
Fabian 'x3n' Landau, Orxonox developer

User avatar
Mozork
Mogthorgar, the mighty
Posts: 134
Joined: Wed Sep 24, 2008 3:27 pm

Re: Content repository

Post by Mozork » Fri Jan 28, 2011 5:48 pm

In my opinion this data/pool should be there to store the "source" of our content in a well structured manner, so that if someone wants to build upon something in our data repository or wants to enhance something, he can look in the pool and find all the necessary files there. To that end I think it's beneficial if for every model there is a list (or symbolic links) of all the material files and textures used. I don't think it's a lot of work to maintain it because you have to establish it once, when you upload your model incl. "source" and then update it only when new files are added.

User avatar
Mozork
Mogthorgar, the mighty
Posts: 134
Joined: Wed Sep 24, 2008 3:27 pm

Re: Content repository

Post by Mozork » Fri Jan 28, 2011 8:16 pm

Ok, I just tried how well symbolic links work with svn and windows and the conclusion is, that they don't. The symbolic link is replaced by e text file with "link path" in it, path being the relative path to the file it linked to.
So in my opinion we should go with the info file instead of symbolic links.

User avatar
greenman
Baron Vladimir Harkonnen
Posts: 360
Joined: Wed Oct 03, 2007 2:53 pm
Contact:

Re: Content repository

Post by greenman » Sat Jan 29, 2011 3:34 pm

i also think it's really nice to have an idea on which files are used by a model at one glance (either list in info file or links). especially if you quickly want to look at the texture file of a model it's quite annoying to look at the mesh using a hex editor (or whatever) to find the material name and then grep through all material files for the specific name... i've done this some times and i cannot say that i like it ;)
but if we use generic textures (metal, etc) textures are re-usable anyway.
i cannot really accept that point, because there will always be models (probably even the majority) with specific textures.

The symbolic link is replaced by e text file with "link path" in it, path being the relative path to the file it linked to.
hm... if symbolic links are just a text file with a path in it on windows then it's almost the same as having an info file with paths in it. the only problem i see here is how to create these "links" on windows ?
the question then is what is better on linux (cause i don't think it makes that much difference on windows ...): the info file or links?
both possibilities have pros and cons. but to keep the amount of files small it's maybe better to use one single info/ref file per model
There are only 10 types of people in the world: Those who understand binary, and those who don't.

User avatar
Mozork
Mogthorgar, the mighty
Posts: 134
Joined: Wed Sep 24, 2008 3:27 pm

Re: Content repository

Post by Mozork » Sat Jan 29, 2011 3:40 pm

Yes, I would decide against the symbolic links because that would mean more files, it's not so intuitive to create them in windows (and have them then work correctly on linux) and it may convey a false sense of security because when moving a linked to file on windows it will break and under linux it won't, with info files you have to adjust either way.

User avatar
x3n
Baron Vladimir Harkonnen
Posts: 810
Joined: Mon Oct 30, 2006 5:40 pm
Contact:

Re: Content repository

Post by x3n » Sat Jan 29, 2011 6:33 pm

I see your points about the info file. however so far only coders talked about models and textures, about what's useful and what not... maybe some modeling experts want to join the discussion? I'm still not sure why someone would have to examine the textures of a model... You can do that in blender, why do you need references in the filesystem?

But apart from that, I don't think links should be used in our repository if they're not platform independent. A text file gives more control anyway... for example if a model has different parts, you could make a list like car: textures a, b, c / wheels: texture d or something. Additionally you can add authors note and other stuff to the info file.

btw, I have to say, I'm astonished oli looks at model files :D
Fabian 'x3n' Landau, Orxonox developer

User avatar
BadElvis
Human Space Navy Lord Commander
Posts: 83
Joined: Wed Nov 14, 2007 1:07 pm
Contact:

Re: Content repository

Post by BadElvis » Tue Mar 01, 2011 7:16 pm

Hi guys,

I also think that all changes that reduce platform independence are not desirable. Therefore, symbolic links now seem like a bad idea to me (although I liked it at first).

My intent is to reduce the amount of textures (and media) we need in general: Reuse generic textures, low poly models, use as little model specific textures as possible. The reason is, that in my opinion, the media is too large.

Concerning the info-file, I think it is a good idea. I will help future developers reuse content that was made earlier. Whether it is XML or plain text, doesn't matter to me. I would stick to plain text. Transcribing it to XML certainly wouldn't be such a hassle.

Another point is, that we cannot rely on the material names that are generated automatically. Most likely they will be different after the transition to the new exporter for the new Blender.

User avatar
x3n
Baron Vladimir Harkonnen
Posts: 810
Joined: Mon Oct 30, 2006 5:40 pm
Contact:

Re: Content repository

Post by x3n » Wed Mar 02, 2011 10:19 pm

ok, so after we (finally) got an opinion of a content creator, I guess we go for the info file :)
My intent is to reduce the amount of textures (and media) we need in general: Reuse generic textures, low poly models, use as little model specific textures as possible. The reason is, that in my opinion, the media is too large.
By "reduce the amount of textures" you mean to move them into a "pool" where they stay available for modelers in future, or do you want to delete them completely?
Because a data pool is part of the discussion in this thread and stripping down the data repository for an upcoming release is one of our main goals.
However deleting content doesn't sound like a good idea to me, because if orxonox will grow, we will have more possibilities to re-use content and will also be ok to ship it with a large data package. so we will be able to use content which is unusable at the moment.
Fabian 'x3n' Landau, Orxonox developer

User avatar
Mozork
Mogthorgar, the mighty
Posts: 134
Joined: Wed Sep 24, 2008 3:27 pm

Re: Content repository

Post by Mozork » Mon Mar 07, 2011 9:09 am

Ok, so let me once again summarize:
  • Use game/data/pool as path
  • Same directory structure as existing data repository but deeper levels with additionally, e.g. {billboard,texture,...} , {metal, rock, ...} , {texture names}
  • For models one directory per model, with current state, old states, .blend files and screenshot of the model
  • Info (plain text) file with used/referenced material files, textures, ... belonging to a model in its directory.
  • AUTHORS file per directory (like CMakeLists)
What remains is, what should we call the info file (info.txt?) and how should it be structured.

I'd say:

Code: Select all

Name:
Tags:
Dependencies: (One dependency per line as relative path)
Authors:

User avatar
greenman
Baron Vladimir Harkonnen
Posts: 360
Joined: Wed Oct 03, 2007 2:53 pm
Contact:

Re: Content repository

Post by greenman » Mon Mar 07, 2011 10:50 am

about the authors files: maybe i authors file per directory is a bit too much (especially if we will use more directories than before). maybe we should put the authors files one (i.e. {metal, rock, ...}) or even two (i.e. in {billboard,texture,...}) layer(s) up ?!
There are only 10 types of people in the world: Those who understand binary, and those who don't.

User avatar
Mozork
Mogthorgar, the mighty
Posts: 134
Joined: Wed Sep 24, 2008 3:27 pm

Re: Content repository

Post by Mozork » Wed Mar 09, 2011 11:15 am

Two layers up sounds reasonable, then it would be on the lowest level of the structure in the data_extern.

What do you guys thing about the structure of the info file?

User avatar
x3n
Baron Vladimir Harkonnen
Posts: 810
Joined: Mon Oct 30, 2006 5:40 pm
Contact:

Re: Content repository

Post by x3n » Wed Mar 09, 2011 6:39 pm

I'd say keep it simple. As long as it's just for humans, add only information which is interesting for humans. For example I'm not exactly sure what "tags" means in your example... Tags make a lot of sense in a browser, to get all items of a given kind, but if you just look at a text file, it usually doesn't help. If we later decide to parse the files with a script, we can add more structured information.

About the authors file: We don't need a rule, just some common sense. We don't need 1 authors file for 1 model, but 1000 models in an authors file are bad as well. Look at our CMakeLists.txt files, the have a lot in common. We usually have one per directory, but we usually also create directories only if we can put a good number of files into it.
Fabian 'x3n' Landau, Orxonox developer

User avatar
BadElvis
Human Space Navy Lord Commander
Posts: 83
Joined: Wed Nov 14, 2007 1:07 pm
Contact:

Re: Content repository

Post by BadElvis » Thu Mar 10, 2011 2:26 pm

Why not make it a small XML file while we are at it. It is simple as well and still human readable:

Code: Select all

<info>
<name>whatever</name>
<author>John Doe</author>
<dependency>d1</dependency>
<dependency>d2</dependency>
<dependency>d3</dependency>
</info>

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest