Where would you look for LOD models?

[Springheel]

I've made an LOD entity for the builder bed, which is a bit high poly by default (1900). I'm not entirely sure where to put it though. Most of the existing LOD entities are in a folder called "Nature", which makes sense as they are mostly nature models. I don't want to start making separate folders for every type of model that gets a LOD version, though.

 

Would "LOD" be a reasonable folder to make, and then have subfolders inside it, the same way "movables" works? Or should I make a "static" folder to counterbalance movables? (Movables are already entities, so LOD stages can be built into them directly).

 

What would be most intuitive for mappers?

[Airship Ballet]

An LOD folder with subfolders would be best, I think.

[Obsttorte]

If you are talking about the lod entities, it may be sufficient to add "lod" somewhere in the name.

[SteveL]

I agree with Obs. A LOD folder is fine for as long as they're rare novelties. If we start to make more of them though we'll end up with a lot of duplicated folder structure. I like the idea of leaving the folders as they are and adding LOD to the name. That'll make them easier to find too. People would forget to check a lod folder, whereas a model with LOD in its name in the normal folder will advertise itself as being a high quality alternative to the standard models.

[Springheel]

At the moment, placing static models is usually done using the "create model" window. Although there are a couple static models that have entities, the vast majority do not. There seem to be three folders under "create entity" that currently that have static models-- "items" (horribly out of date), "static" (just a few LOD models) and "nature", which is obviously only nature models.

[Airship Ballet]

It depends on how many there are going to be, so if this isn't a really rare occasion then I'd change my vote to adding LOD to the name. It makes sense, given that people will rarely be searching specifically for a LOD model, but rather have an object in mind and discover there's a LOD version. I would urge you to make sure that it becomes the uniform standard for TDM, because as it stands the file structure can be horrendously inconsistent.

[Xarg]

the file structure can be horrendously inconsistent.

 

Prime example of this being the skin browser (I'm using 1.8.0, it's possible 1.8.1 has done something about this, but I don't think it has), which has most of the available skins dumped into the root folder it searches through, resulting in hundreds of items being on the same list, its hard to tell if they're sorted by any criteria other than semi alphabetically. I know someone has suggested it before, but a tag system would be amazing for speeding up the find time for items in all menu aspects of DR.

[SteveL]

At the moment, placing static models is usually done using the "create model" window. Although there are a couple static models that have entities, the vast majority do not. There seem to be three folders under "create entity" that currently that have static models-- "items" (horribly out of date), "static" (just a few LOD models) and "nature", which is obviously only nature models.

 

Ah, I hadn't thought about the fact that we use a completely different menu and browser for models vs other entities.

 

It's a pity if there's no way to get them to show up in the models list. They all end up as func_statics once placed in the map. Perhaps we could somehow expand the "Static Models" folder in the entity chooser to show all models, LOD entities plus the obj and lwo models.

 

In the meantime, I change my vote to the "static" folder in the entity chooser. We might be able to expand it later, and I reckon it's better than having a special LOD folder because that'll complicate things if we start to add LOD animated props. People wouldn't know whether to check the "Animated props" folder or the LOD folder.

[Springheel]

It depends on how many there are going to be,

 

Not sure. There aren't many right now, but who can say in the future?

 

I'd change my vote to adding LOD to the name.

 

That doesn't answer the question of where to put them though. In terms of future-proofing, we can always change which folder entities appear in, since it's just a spawnarg and it doesn't affect maps. Changing the name of an entity causes problems for any map that uses that entity.

 

Ah, I hadn't thought about the fact that we use a completely different menu and browser for models vs other entities.

 

Yes, that's what makes this difficult. I know that when I'm mapping, I only go to the entity window if I plan on adding a movable, loot, or light. If it's just a regular model, I use the model window.

 

The best solution, from a user standpoint, would probably be to merge those two functions somehow, so that there is no more "create model" function--instead you go to the "static" menu in the "create entity" menu. And then LOD models would be merged into the list of static models, so mappers don't even need to know if they're LOD or not.

 

But I don't know how much work that would be to set up...the two windows do operate slightly differently. "create model" shows associated skins as a dropdown menu, for example, while "create entity" doesn't.

[HMart]

For the LOD system it would be nice if DarkRadiant separated the lod models from the original models in a separate tab perhaps called LOD or by using some color coding on the models name, this would be possible only using the LOD folder idea because lod models would need to have a distinct naming scheme from the original model, for example modelname_lod1 or lod_modelname_1, this so not brake past missions like Springheel said.

 

Don't know how you guys work with lod's but this is how i envisioned a eventual LOD workflow in DarkRadiant

 

1 - select your static model/entity using the create model/entity option

 

2 - put them on the map

 

3 - select them

 

4 - go to the entity tab

 

6 - click the assign lod stage button

 

7 - browse for the respective lod model (inside the LOD folder) and click assign, chose the view distance click OK, repeat for the other stages.

[Lux]

7 - browse for the respective lod model (inside the LOD folder) and click assign, chose the view distance click OK, repeat for the other stages.

 

Wouldn't it be peachy if when you selected the model in the map and then clicked the assign lod stage button, the LOD tab ONLY showed lod models for the selected model? Using a regex or similar to filter the list to the selected model name.

[Springheel]

Wouldn't it be peachy if when you selected the model in the map and then clicked the assign lod stage button, the LOD tab ONLY showed lod models for the selected model? Using a regex or similar to filter the list to the selected model name.

 

You shouldn't need to set LOD stages manually at all. They will already be set for entities that have them.

[Lux]

Automatic?? Oooo we like that even better! Awesome!

[Springheel]

Yes, LOD entities ideally should be completely behind the curtain, something that mappers don't have to think about at all. It's only the quirky way models and entities are separate in DR that requires mappers to be aware of it.

[HMart]

You shouldn't need to set LOD stages manually at all. They will already be set for entities that have them.

 

That is nice indeed but manually setting them imo should also be a option, for custom models if desired.

[SteveL]

That is nice indeed but manually setting them imo should also be a option, for custom models if desired.

No worries, the default setup will be done through spawnargs in the entity def. Mappers will be able to override those inherited spawnargs in the usual way.

 

So for most cases you'll just place a chandelier or whatever and that's that. If you check the inherited spawnargs you'll see that it's using model chandelier_highpoly, and that it has another model chandelier_lowpoly that kicks in at 400 units distance. You'll be able to change any of that setup by using your own values for those spawnargs.

[HMart]

Oh i didn't thought about the inherited spawnargs, that does take care of the manually part.