So I’m working on a modular building environment set for the marketplace, and having a BIG problem figure out how to actually naming all my darn elements. For example, having several wall sections, some with cutouts for doors and windows, and in different styles, what kind of naming should I use, without ending up with either long names (which at least are descriptive), or short names (which is practical, but less readable).
Currently I have something like:
I want to have some descriptive names, but afraid that it might not be readable, as long labels will just be cut off, and then it’s useless, for example the example above could end up showing as thumbnail and the name like this:
SM_wall_w_doorho… , SM_wall_w_doorho…
Which would make it hard to see what is what. Any good advice on how to name the different parts?
Yeah, those I’m all fine with, but that’s more about prefix and such, not about what would be good naming conventions for the descriptive names themselves. That’s the ones I’m struggling with, because I want them to be meaningful to other people then just to myself.
I think it mostly depends on what you and/or your team can understand. I think the only “rule” is that it stays consistent.
Personally I’m using “SM_<TILESET><ROOM/TYPE><ASSET><Identifier>” for my tileset based assets.
So, for instance, I’ll put which “level” they’re for in TILESET, like, Crypt, Dungeon, *Brothel *or whatever it is.
Then I’ll put it into a segment, like HallwaySmall, HallwayLarge, RoomShort, RoomTall, Entry, TortureChamber, etc.
Then I’ll name the ASSET something like, *Wall, WallDoor, WallDblDoor, WallCorner, WallAlcove, Floor, FloorInset, FloorDownSteps *and so on.
The Identifier I use less often, and that’s normally just an extra bit on the end if there’s multiple versions of the same “asset”, like if there Light1 &Light2, ColumnSimple & *ColumnOrnate *or DblDoorR &DblDoorL.
It’s really subjective in the end. Use whatever you can keep track. Some people like ridiculously long names and other’s like incredibly short ones. I personally fall somewhere in the middle and try to find a descriptive balance, but that’s not for everyone. shrug
Cheers, I’ll take that under advisement, I guess I should write down some rules for me to follow, and since I was going to include a excel sheet with all the elements and some properties so you can get an overview of the elements (such as optimal hole cutouts for windows ect), I might be able to get some ideas about what is the best way to get it consistent.
I personally like to find ‘groups’ for my stuff and work my way through the name by sorting them in more and more precise descriptions of the area the asset is used in.
Yeah, and actually related to that, how about the folder structure, I noticed that some just put everything into the root Meshes, Textures and Materials, and others split it up into folders with the object name, and have mesh, textures and materials for that model in there, such as a table or chair, while others split it up into categories, like /Walls/ , /Floors/ ect, for each main group. I personally like the last way the best, avoid too many sub folders, but have some base categories.
The “Skins” folders are where I’ll dump any textures that are mesh-specific along with their materials. I do that mostly because once they’re setup and applied to the mesh I never really care about them again unless I notice something wrong with them, and then it’s still easy enough to track it down by just keeping the name straight on everything.
Basically I like to group things based around where they’re used. If an object is only used in one tileset, then it’ll be grouped in that environments Objects folder rather than the global Objects folder.
Again I think this is personal preference . As far as I know, and someone correct me if I am wrong, the directory structure does not have any performance implications, just workflow ones. You can really just do whatever is easiest to keep track of. This is how I like to work, but I’m sure that structure will be absolutely maddening to some other people.