Jump to content
The Dark Mod Forums
Sign in to follow this  
Fingernail

Models Directory Structure

Recommended Posts

This had got quite out of hand, with people shoving stuff in "Props" directory etc. with no real order.

 

So, we decided based on a logical progression of how the textures are organised, to sort the models into themes, that is "Mansion", "Cathedral", "Crypt", "City" etc.

 

This doesn't impact on generic models, such as "Loot", which will have it's own folder.

 

It just makes sense, considering both textures and SFX are being organised in this way.

 

So, as an example, there'd be Mansion/Furniture/Chairs/Chair1

or Cathedral/Furniture/Pews/Pew1

 

but Loot/Plates/SilverPlate1

and Plants/Trees/LargeOakTree1

Share this post


Link to post
Share on other sites

It doesn't make sense to put models in a folder named mansion. People look for tables, lights and such stuff and not mansion or crypt. That may be usefull for very specific models, but not for the majority.

 

So models should be grouped on their usage and not where they usually are put. For textures this makes sense, because textures are used for a specific theme.

 

I also wonder who is "we" who have decided this, because I haven't seen any mentioning of this. ;)

Edited by sparhawk

Gerhard

Share this post


Link to post
Share on other sites

You weren't on IRC.

 

Why shouldn't models also be used in a specific theme? You don't go around sticking church doors in a house, now do you? We should IMO promote these themed ideas.

 

In the end, it'll be exactly the same as textures. One way is not really 'better' than another, it's simply the overall continuity.

Share this post


Link to post
Share on other sites

Which IRC would that be? If there is a fallback it would be nice to mention this somewhere.

 

Models can be used in any kind of environment. So it doesn't make sense to put models in a theme as textures.


Gerhard

Share this post


Link to post
Share on other sites

Channel is full. Haha! What crap IRC is that?

 

If a texture is used out of place thats ok. When I look for a texture it is ok to group them to a theme because they are much closer associated. Even so it would make sense to have wood, stone, etc. groups. For models this is not the case. When I want to place a table I look for a table. And usually I don't look for a table that fits in a crypt. What criteria would you use to determine that a specific table belongs in a crypt and not in a mansion? Of course there are overlaps but I seriously doubt that you go looking for a model based on the place.

 

EDIT: I'm on irc.quakenet.org #darkmod


Gerhard

Share this post


Link to post
Share on other sites

So can we have some opinions from mappers? I was on IRC with Fingernail and the conclusion was that this structure is also not the best one. What we thought would be helpfull is to group the textures and models according to this:

 

Textures:
walls/gothic/texture...
walls/victorian/texture...
floor/gothic/texture...
...
wood/texture...
stone/texture...
etc.

Models:
table/victorian/model...
table/gothic/model...
table/generic/model...

 

Does this make sense? IMO the current structure is not really good for searching specific objects, but instead of creating a new structure in a rush, we should consider it first.

 

My idea was that a mapper will have a image in mind what the object should look like and selects an object according to this. Since that exact image may not be available in the repository he will need to find one that matches or can be used as an alternative. This indicates to me that an organization according to theme, as we have it now, like mansion, crypt, etc. doesn't really make sense. IMO a mapper would not think, I need this table and it looks like it could be a mansion table so I look into the mansion folder. Instead he will more likely think like this: I need a table, so let's look for a table. Maybe he knows exaclty whaht style this table should be in, so he might know that he needs to look into Victorian tables.

 

I think that this doesn't make sense and will not allow for a fast browsing. Since we don't create THAT many different objects (for a given type that is) my position is to put all tables into a single folder with accompaning screenshots and a map which includes all the objects so the author can easily browse the repository for objects he needs without the needs to memorizing where particular objects are. The distinction of the tables would be then in the name of the file, instead of the folder.

Sample:

table/Mansion_low_rich_0001.lwo
table/Dungeon_office_wood_0001.lwo
...

 

This way an other will have all tables in a single folder but he still knows what theme a particular objects is supposed to be in.

 

Any comments?


Gerhard

Share this post


Link to post
Share on other sites

I think grouping them into types rather than themes would be better for the models. If I wanted to grab a table I'd want to see what I have to select from, cuz there might be a model in there that works better than one I had in mind.

 

I think we should get away from the subset mentality. It might work for organizing the mod, but when it's out and everyone is mapping it'll be more cumbersome than anything.

Share this post


Link to post
Share on other sites

Yeah. That was my intention. That doesn't mean that the organization can not help the mod as well, but we should focus on how the users will use our stuff instead of just looking how we can organize it for the development. These approaches don't need to be mutually exclusive.

 

And since Sneaksie is doing the model map, he should also participate in this reorg discussion. :)


Gerhard

Share this post


Link to post
Share on other sites

It's a bit unclear to me what's being said above. An image of an object in the repository.. what for? The editor displays the actual model (at least, it's supposed to, if the model is in proper form). But maybe I'm just not understanding the intention.

 

Anyway, I like the idea of grouping textures and models by type (floor/subtype, chair/subtype). The model file name distinction is really just more of the same, so I'm fine with that too. IMO, there are several ways to logically represent and catalogue these things, and this is just a couple of them. The only thing I have a strong opinion with regard to this is, I sure hope they (models and textures) include a /darkmod in front of them (as per the other discussion).

Share this post


Link to post
Share on other sites

That's ok. To show the model with an image, or even better with a map, has the advantage that the user can immediately see what the model looks like and for the map we will see if the model even works. In the editor the user only sees the model if he selects it and depending on the model that is not THAT good to see.


Gerhard

Share this post


Link to post
Share on other sites

Models work in the editor like everything else, Spar. It'll bring up a list and it'll show it in a little 3D preview window when it's highlighted...once it's in the editor it'll show up like it should once you go into render mode.

 

Mappers have lived with FAR less in the past, back when Q3 and Vampire were out all your props would show up as boxes no matter what. The way D3 is set up is perfectly fine for someone wanting to select a model since they can preview it beforehand quite easily.

 

And Sneaksie, the more I think about adding the /darkmod folder to the directory structure the more it makes sense. What if someone wants to mod the mod for instance, and wants to keep all our assets in the same place while he works with his own stuff seperately? That's just one of many reasons why we should go ahead and make the switch back to the old setup.

Share this post


Link to post
Share on other sites
To show the model with an image, or even better with a map, has the advantage that the user can immediately see what the model looks like and for the map we will see if the model even works.

But, do you mean that the mapper would look in explorer, or load up another map, to see what model to select? I'd just hammer through them brute force, myself. But the name descriptions you mention would certainly help there. :)

 

Renz: That's another mighty fine point (re: the textures). Surely, or at least we should hope, tons of TDM modding will happen. Like numerous others here, I'm half-German too (by parentage, not place of residence) so I just like things in neat little packages. Just. Like. So.

 

...Okay, so I'm anal-retentive.

 

I think I may have just made a racist remark. :blink:

Share this post


Link to post
Share on other sites

If we have a signpost with each model, telling the name, the mapper can easily find each mode when he goes through the map and of course screenshots can always be taken. The major point of this map would be for us to check if all the models work properly, because we would immediately see when one is screwed up. But it might also be usefull as a browser, even though I'm aware that it might be painfull to load up the map each time. That's why images should also be taken, but we don't need to do this right now.

 

Renz: Just because mappers have been putting up with far less doesn't mean there is room for improvement. Also the more important point is that we need such a testmap to see if all the models are working. I certainly don't want to run through several maps just to get a look at our models when somebody screwed up the material file.


Gerhard

Share this post


Link to post
Share on other sites

I think I may be able to create a quick "signpost" map entity that just displays text in its key/value pair as "debugtext" (the floating red text you see when you have various draw_ debug options on in D3)

Share this post


Link to post
Share on other sites

I should be able to add this by the weekend at the latest. It'll basically just be a new entity class that calls GameRenderWorld->DisplayDebugText or whatever it is with text in the entity's key/value information.

Share this post


Link to post
Share on other sites

So I was going about creating a new class to display text ingame, when I realized it's not necessary, because you can just put the signpost info in the "name" string of the entity, and use console commands to display entity names.

 

Create a placeholder func_static, if you want you can attach a model to it so it's easier to find ingame, then put the info you want displayed in the "name" string (you may have to use underscores instead of spaces.. not sure)

 

Once you've done that, there are two ways I can see right away to view the name ingame: In the console, type g_showentityinfo 1. This is option is not so good, since it shows the wireframe for EVERY entity and generally clutters up the screen.

 

A better option is "g_dragentity 1" This is used for dragging physics entities by left clicking, but it ALSO displays the name of the entity when you left click over it, even if it's a func_static (you may have to attach a dummy model like a box or something for this method to work).

 

So is that method of displaying the text you want (entity name string) okay, instead of changing the source code?

Share this post


Link to post
Share on other sites

I'll try it out.

 

Edit:

This seems to work fine, thanks Ishtvan for pointing it out. Makes me wonder though (I assume this is a question for spar): was the target_tip entity removed, and if so why? It could prove useful for sure.

 

Anyway, all should feel free to stop reading here. The next off-topic portion is the result of frustration and Love of the Thing. For fun, I thought I'd write down exactly what transpired in trying this, a very simple thing to do. I call it, "Fifteen Minutes with D3Ed." Keep in mind, most of this is nothing new or special - it's always this way. :)! Whoopee!

 

The change worked for the bookshelf, but wanted to try for something that's not specifically created as a func_static first. Let's try the chair. But now, the orientation of bookshelf is screwed up. Why? Suddenly it's 90 degrees to how it should be. Anyway... so I change the chair. In game, now the chair is a black box instead of a black chair. Sure enough, it changes to look like that in the editor when I exit game mode. WTF? Delete shelf and chair and start over. Shelf is first not showing, so I clone it, and delete the original. (Note: insert "failed to create entity") messageboxes at random, the more, the merrier!) The clone is a rectangle of approx right size, but is not the bookshelf. Okay... create chair. Chair is a black box. WTF? Compile (unnecessary, but at this point...why not, right?) Editor crashes. YAY! Get back in. Bookshelf is still a rectangle only, and now it's a bit sunken halfway through floor. Interesting, since I didn't touch it. Ooops, that's right! I forgot about that "whereever you set the origin, you're stuck with it forever!" bug, YAY. Delete both and recreate. Two black boxes again. Hrm, what's wrong here? Launch the map - as I do, in the background, the black chair-box vanishes! LOL! That's a new one! Exit game mode, back in the map, now the chair-box is a single point, no bounding box, no model, nada. I think I've created a quantum singularity using D3Ed. Damn, where is Einstein when you need him. Perhaps I can find Stephen Hawkings instead. To delete the singularity, I use area select.

 

And here's the best part. I deleted the map and started over with the copy I have from the CVS. Everything worked fine. Without a single hitch. Even though I did the same exact thing.

 

I once read a study where rats were tortured with an electric floor in their cage. At first, they fought against it, jumping, running around frantically, etc. But in time, they stopped fighting. They just stood there getting shocked non-stop, without putting up any struggle. The finding was that the rats that became hopeless, and learned that they are helpless to fight, developed far more cancers than those in the control group. Interesting finding, that. Somehow I think it applies to D3Ed.

 

God, this editor REALLY sucks sometimes. Badly. Hard to believe that such a buggy thing comes from id software, but then again, JC didn't write it. Say what you will about id games, they are usually not riddled with bugs and on the contrary, are rather stable and solid. DromEd has fewer (or less severe) problems than this thing. Best of all, it's moody. Sometimes it's perfect. Other times...

Edited by SneaksieDave

Share this post


Link to post
Share on other sites

I don't envy you guys that have to work with the editor... at least when something goes wrong with code it's usually my own fault. :) (Although we do have our share of "systems we can't touch because the source was not included in the SDK" to work around).

 

All the name strings that are assigned by default in the game take the form blah_blah_blah, so I'm not sure what effect putting spaces and slashing in there would have; maybe that is causing problems, but probably not since you said you got it working fine.

 

Also, it might help to use the "signpost on a model" thing for a separate model that always works, (like a D3 crate or something) that you put next to /above the model that you want information on.

 

I don't know about the target_tip entity myself, if it had to do with the frobbing system then you'd best wait for Sparhawk to answer. As far as I know though, we didn't remove any entity definitions, we added our own def file that should only add to the existing D3 definitions, not remove any.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...