Jump to content
The Dark Mod Forums

Making it easier to use LOD models


Recommended Posts

Currently the components that make up a LOD-enabled model are usually stored in various different places. Taking the aphrodite statue as an example:

- The most detailed model stage is found in darkmod/decorative/statues.

- All the other stages are found in darkmod/misc/lod, probably so that the decorative statues folder is less cluttered.

- The LOD entity that makes use of all these stages is in a different menu altogether, Create Entity > LOD/decorative/statues.

 

I've seen that a lot of the times, even though a LOD entity is available for a particular model, mappers just use the most detailed stage in a simple func_static, missing out completely on the LOD optimisation.

I suppose this is because mappers mainly use the Model Chooser instead of the Entity Chooser for decorating the map and don't realise how the LOD system works/forget to check every time whether a LOD entity exists for any of the models they create.

 

Some possible ways to address this:

- Let the Model Chooser check whether there's a LOD entity that makes use of a model the mapper is about to create. If yes, it could create that entity instead of a func_static.

- Wellingtoncrab suggested an overhaul by combining the Entity Chooser and Model Chooser into an integrated asset chooser which could show flags for certain models, i.e. LOD. This would also make it easier at a glance to see what's available.

  • Like 3
Link to comment
Share on other sites

My following suggestion would need changes at the engine level and also require the team to reimport and export the models again from a 3D tool or perhaps make a special plugging for DR to mix the models into a single one, so may never happen but I think it should at lest be considered and it is the following:

Some games, include the LOD models, in the main model itself, like how the engine currently uses the collision model and the shadow model, the same could be done for the LOD's, this would have the following benefits that I currently see, it would unclutter the model folder, because you would only need to export one model, all necessary info is within the model file itself, two permit DR to continue with the current model chooser and entity chooser, no need to mix the two or change DR model handling in any big way, apart from perhaps creating a special filter, to hide the LOD surfaces/models if necessary, like is done for the shadow model, and the best benefit imo, instead of the mission maker having to bother with setting up LOD's manually that would be automatically setup by the engine at model import time and so prevent the problem that Dragofer talks about, forgetting or even not bothering with setting up LOD's.

How to setup the LOD's in the 3d tool? It could be done like the shadow model is done, using a special LOD material, or if possible they could be put in a different layer that you give a "_LOD_X" name and the engine would read that layer has a individual model, this would need the engine to support importing models with more than one layer, that I don't think it does (but I could be wrong) and I'm not even sure if, ASE and MD5 support extra layers, I know LWO does. 

My two cents on this discussion. 

Edited by HMart
Link to comment
Share on other sites

I think @Dragofer is talking about existing LOD models/entityDefs, while @HMart is talking about adding new LOD entityDefs.

Regarding the original question.

I think Entity Browser allows to choose entityDef to spawn, while Model Browser allows to choose model to add as func_static entity. I'd expect that merging browsers can lead to confusion in future, because conceptually they do very different things.

There is also more general case: when you choose entityDef different from func_static, but want to also select model for this entity. For instance, when you add func_rotate entity with some model. What is the typical workflow for it? Add model, then change its classname, or add entityDef, then select model?

As for creating new LOD models easier.
If DarkRadiant has FBX import, than it can in principle import LOD models from FBX, i.e. export several model files plus auto-generated entityDef.

Link to comment
Share on other sites

1 hour ago, stgatilov said:

There is also more general case: when you choose entityDef different from func_static, but want to also select model for this entity. For instance, when you add func_rotate entity with some model. What is the typical workflow for it? Add model, then change its classname, or add entityDef, then select model?

Entities can only be created if (A) the entityDef contains a model or (B) you have a primitive selected which will be used as the model by the entity. Otherwise (C) change the classname of an existing entity, i.e. a func_static model.

So there are these methods:

  1. Open the Model Browser, use it to create the desired model as a func_static. Then use the "classname" spawnarg in the Entity Inspector to open the Entity Browser and select the func_rotate entity.
  2. Draw a brush/patch, open the Entity Browser and select the func_rotate entity. The brush/patch will become a func_rotate.
  3. Open the Entity Browser, select an entity which inherits from func_rotate and has a model.

 

1 hour ago, stgatilov said:

I think Entity Browser allows to choose entityDef to spawn, while Model Browser allows to choose model to add as func_static entity. I'd expect that merging browsers can lead to confusion in future, because conceptually they do very different things.

Yes, this is a concern. I believe earlier proposals for an integrated asset browser were intended as a kind of clipboard where mappers could include their favourite assets (models, entities, skins, materials) for faster access. Basically the mapper would already know the purpose of each item.

 

1 hour ago, stgatilov said:

I think @Dragofer is talking about existing LOD models/entityDefs, while @HMart is talking about adding new LOD entityDefs.

The problem is more that using LOD requires an entity from the Entity Browser, while mappers mainly use the Model Browser for decorating and are therefore prone to creating single LOD stages as func_statics. For me it's currently an interface and accessibility issue with how LOD models are organised and added to the map.

As per HMarts' suggestion, it'd be nice if models could contain LOD stages within themselves, but considering the need to individually finetune LOD distances for each stage of each model to minimise the obviousness of LOD popping, I don't really see a way around having an entityDef for LOD entities. It'd reduce clutter in the Model Browser, but many LOD stages are already quarantined in the models/darkmod/misc/lod folder.

Link to comment
Share on other sites

21 hours ago, Dragofer said:

...

As per HMarts' suggestion, it'd be nice if models could contain LOD stages within themselves, but considering the need to individually finetune LOD distances for each stage of each model to minimise the obviousness of LOD popping, I don't really see a way around having an entityDef for LOD entities. It'd reduce clutter in the Model Browser, but many LOD stages are already quarantined in the models/darkmod/misc/lod folder.

Afaik there's nothing preventing you from being able to tweak each LOD distances individually using the method I suggested, at import time you set a reasonable default distance for each LOD, then after that you just expose entity spawnargs to the mission makers like always. 

Like I said this can work just like the shadow mesh and the collision mesh, the lods would just be extra surfaces for the code to manage, even thou the former are imbedded in the model file itself and even on top of the main mesh and each other, you can still access them individually.

Link to comment
Share on other sites

I actually like the idea of a combined Model/Entity browser. They may be doing different things at the map level, but from a user perspective their purpose, appearance and functionality is very similar: choose an object in a tree, look at the preview, add it to the map if you like it. The fact that some of those objects are just "static models" while others are "entities which do things" aren't necessarily important for a mapper, especially if some entities are literally just a few models with LOD swapping.

It does raise the question of how to populate the trees though. Entities exist in a completely different virtual tree from models, which are just shown in filesystem layout. Presumably the two different trees would need two different root notes, at which point the distinction between models and entities is effectively re-introduced within the single dialog.

  • Like 1
Link to comment
Share on other sites

As for the LOD confusion, it kinda seems like you created the problem yourself, moving stuff to very different folders. Typically, you don't have time for making more than one good (LOD1) version of your model, so the clutter in the model folder is usually minimal. What I've seen in TDM stock assets though, is that models can have unnecessary LOD stages, where e.g. LOD1 is 1500 tris and LOD2 is 1200 tris, for example. That makes little sense. The rule of thumb is to have around 50% vertex difference between each stage, so changing between models gives tangible performance boost.

Edited by peter_spy
Link to comment
Share on other sites

Sorry for the arm chair UI programming as I understand everything is ultimately easier said then done. I definitely understand the mechanical reasons for different browsers, but I do think it limits to perception of content which is actually available to user and is ultimately more confusing not less. To place in an object in a map it will either be in the model browser, entity browser, or prefab browser and even after using darkradiant for years now I am often stumbling onto new things and have probably forgotten more content then I end up using. I would like a system where if I want a chair - I search the object/asset browser for "chair" and you then pick from the relevant moveable entities/lod entities/static entities/prefabs etc. This would then appear in a "frequently used assets window" like frequently used textures do in the textures window. A tagging system would also prevent the need to have every descriptor in the object name and can visibly delineate between say a static entity and a moveable or LOD entity which share the same mesh and would otherwise appear identical in the browser, but there may be a better way to achieve the same effect. 

But hey - even if that doesn't happen I will still be using darkradiant - and thanks for reading!

  • Like 2
Link to comment
Share on other sites

On 9/5/2021 at 3:50 PM, HMart said:

Afaik there's nothing preventing you from being able to tweak each LOD distances individually using the method I suggested, at import time you set a reasonable default distance for each LOD, then after that you just expose entity spawnargs to the mission makers like always. 

The question is, would it be possible to store these LOD distances within the model file? Currently the entityDefs store this information and are therefore a necessity. It should not be necessary for mappers to tweak the LOD distances themselves when they use core assets.

18 hours ago, OrbWeaver said:

Presumably the two different trees would need two different root notes, at which point the distinction between models and entities is effectively re-introduced within the single dialog.

Yes, the trees aren't designed to be combined, so they'd need to be kept separate anyway. Personally I'm somewhat wary of merging models and entities into a single giant browser since for me their purpose is overall quite distinct (map decoration vs. implementing functionality) and searches could return many results that aren't relevant to what one wants to do,  but I could imagine it happening if done well. There are quite a few entities that fit into the "map decoration" category, so it'd be good if those were visible together with the other decorative items.

 

For me the biggest gain would be if there were better integration between models and entities, so models in the model browser would link to entities that use such models. It would mean the mapper can decide whether he wants to create a model as a LOD entity, a moveable item, a func_static etc. Maybe it wouldn't be necessary to merge the 2 different browsers to achieve such linking.

  • Like 1
Link to comment
Share on other sites

10 hours ago, Dragofer said:

For me the biggest gain would be if there were better integration between models and entities, so models in the model browser would link to entities that use such models. It would mean the mapper can decide whether he wants to create a model as a LOD entity, a moveable item, a func_static etc. Maybe it wouldn't be necessary to merge the 2 different browsers to achieve such linking.

That would be an option too, and I think it could be achieved with the existing interface. We already show available skins as children of model nodes, so we could show entities using the model as children too.

  • Like 1
Link to comment
Share on other sites

18 hours ago, Dragofer said:

For me the biggest gain would be if there were better integration between models and entities, so models in the model browser would link to entities that use such models. It would mean the mapper can decide whether he wants to create a model as a LOD entity, a moveable item, a func_static etc. Maybe it wouldn't be necessary to merge the 2 different browsers to achieve such linking.

Yeah I think that would be a pretty big improvement!

Link to comment
Share on other sites

In other engines, static mesh class itself already has attributes like material path, skins, LOD settings, etc., but the model has to be imported first. So instead of having a separate "LOD entity", it would be better to have these attributes either moved to func_static class already, or, requiring models to be assigned to an entity with all the proper spawnargs.

Edited by peter_spy
Link to comment
Share on other sites

1 hour ago, peter_spy said:

So instead of having a separate "LOD entity", it would be better to have these attributes either moved to func_static class already,

LOD entities are basically just func_statics with pre-applied LOD spawnargs unique to that model - so the LOD attributes can already be applied to func_statics. The LOD entities are just needed to store these spawnargs.

What could work is to introduce a new type of file, .lod, which would assign default LOD properties to models. This way any (func_static) entities with these models would automatically exhibit LOD behaviour. LOD entities would become redundant.

 

10 hours ago, OrbWeaver said:

That would be an option too, and I think it could be achieved with the existing interface. We already show available skins as children of model nodes, so we could show entities using the model as children too.

Yes, this sounds very good. Some more brainstorming to refine the concept:

- would be good if deprecated entities (mostly light sources) were excluded. Without seeing the entity tree view or folder path, you have no way of knowing that an entity has been deprecated.

- it'd be helpful if entity descriptions were shown in the model browser when an entity is highlighted. Maybe they can take the place of the material or model stats, if they're available.

- the old search method (type in a string, then press arrow keys to jump from result to result) might need some refinement to stop it from expanding so many nodes in the process. There will be more and larger expandable nodes if entities are added.

Link to comment
Share on other sites

1 hour ago, Dragofer said:

- would be good if deprecated entities (mostly light sources) were excluded. Without seeing the entity tree view or folder path, you have no way of knowing that an entity has been deprecated.

There is already a better way of deprecating assets such that they do not appear at all in DarkRadiant browsers. So far I don't think this feature has been used at all by the mod assets.

Link to comment
Share on other sites

On 9/7/2021 at 9:41 PM, OrbWeaver said:

There is already a better way of deprecating assets such that they do not appear at all in DarkRadiant browsers. So far I don't think this feature has been used at all by the mod assets.

This is very good. At this point I think TDM's assets have accumulated quite a few things that should be deprecated, but unfortunately this is limited to models and materials at the moment. I've confirmed this to still be the case in DR 2.13.

I definitely have some "deprecated" or outdated entities and duplicated soundshaders on my hit list, so I opened a ticket to extend this feature's coverage.

Link to comment
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.

 Share

  • Recent Status Updates

    • jaxa

      RTX 3090 Super, RTX 3070 Ti 16 GB, RTX 2060 12 GB
      https://wccftech.com/nvidia-launching-rtx-3090-super-rtx-3070-ti-16gb-and-rtx-2060-12gb-by-january-2022/
      · 0 replies
    • duzenko

      CPU benchmark time - compiling DarkRadiant (2nd run)
      i5 8600K 6C/6T@4.4GHz DDR4 2x2133MHz 9MB cache
      Parallel builds: 1. 3:57 Parallel builds: 6 (default). 2:28 r5 1600AF 6C/12T@3.3GHz DDR4 1x2666MHz 16 MB cache, temp folder on HDD
      Parallel builds: 1. 5:05 Parallel builds: 4. 2:47 Parallel builds: 6. 2:55 Parallel builds: 12 (default). 2:57
      · 6 replies
    • nbohr1more

      Status updates are back so it is also a good time to return to contests!
      https://forums.thedarkmod.com/index.php?/topic/21095-christmas-connections-contest-2021
       
      · 0 replies
    • freyk

      Having seen the new scifi stuff from bladeghost/scythwraith, want to continue the cyberpunk project. Only one problem, can't map.
      · 1 reply
    • jaxa

      Behold, the brand new RTX 2060!
      NVIDIA ponders GeForce RTX 2060 re-release with 12 GB VRAM to paper over RTX 30 scarcity
      · 1 reply
×
×
  • Create New...