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 4
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

-=  IRIS  =-    ♦    = SLL =

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!

-=  IRIS  =-    ♦    = SLL =

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

  • 11 months later...

Coming back to this discussion from issue #5739: I'm not so sure about putting the entity classes in the tree as children to the object, but what about this mockup below? Is having a tab with the "Related Entity Classes" too well hidden to be useful or would this be ok?

image.png

  • Like 1
Link to comment
Share on other sites

I think that would be great, especially if those entities can be created from that tab. Would make it much easier to find and use entities for a given model.

Link to comment
Share on other sites

I second that.

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

  • 2 months later...

I agree with your observation in the main post, and admit it's a sin even I understandably commit: The DarkRadiant GUI didn't make it clear which models have a LOD, you'd have to check and find out for yourself... even then you aren't encouraged to do so right away as it requires going through the trouble of setting LOD spawnargs manually.

My suggestion: Maybe don't combine the models and entities menus, they seem better as separate things and mixing them might clutter everything and make it harder to browse. But the model screen could hide LOD models from the browser, and instead automatically set LOD spawnargs to models that have them when inserted on the map.

We could leave it func_static but add the "model_lod_*" and "lod_*_distance" arguments... I'd even consider a default "hide_distance" for all models based on their bounding box size. Those should be settings you can disable like "Surround with monsterclip brush" which is currently the only option in the model chooser, we could maybe offer a multiplier offsetting how aggressive the LOD settings are based on the model scale.

If not the simple and perhaps ideal solution is having a default entity for every model that has a LOD: Some trees for instance have them, a few other items too... not everything does though. I checked out the new "Related entity classes" menu and that seems good enough to me; I'd add a checkbox to automatically insert the first entry if one is detected, the menu might be lost on some mappers in all the GUI detail. But to be useful I think more models should be given entities.

Edited by MirceaKitsune
Link to comment
Share on other sites

On 9/6/2021 at 10:33 PM, Dragofer said:

The question is, would it be possible to store these LOD distances within the model file? 

Sorry for the extremely late reply to this.

First not that any of this matters, as I don't think LOD's will ever be done in this way, but for academic reasons, you don't need to save LOD distances in the model, just hardcode in the engine c++, reasonable default distances for each layer and give the ability to change them later if necessary, like always editor entity spawnargs, but if the defaults are well thought out, you the mission maker, probably wouldn't even need to mess with the distances most of the time, everything would be automatic for the mission maker, like the shadow and collision model.

And please to everyone reading, even thou this may sound cool, don't think any of this is easy to code, because is not. Many times making life easy to the end user, requires a ton of work and knowhow from the coder.

But the answer to the question is yes, how to do it, does depend on the format you are exporting.

Spoiler

I personally only use lwo for static models and I know by reading the c++ code handling the lwo, that how it is used by the engine, is very underutilized, many of its information capabilities are ignored by the model parser, only caring about the required info for the static models, but the parser, as is written, is still capable of reading more from the file, than is used in the end.

For example, it detects all extra layers in a lwo file and goes to the trouble of saving them into a list for later use, but the following code reading the list, only cares about and handles the geometry info in the first layer and skips the rest, but even so, there's some Doom 3 lwo models, with extra layers, but they were obviously only used, as save/store slots for extra geometry, for the modeling software, info that the idSoftware artist may wanted to use or not later. 

The lwo parser, also detects and saves into a list, extra polygon tags but ignores most of them, only caring about the smoothing group info and is this polygon tags, at lest as used/done in Luxology Modo, that imo could be used to encode the LOD distances.  Polygon tags is a lwo powerful feature, for example there's a modo plugin/tool to create user GUI's for custom tools, a tool made by Seneca a idSoftware artist and it uses polygon tags (strings) to create GUI cards from geometry from within Modo itself, imo the guy is not only a excellent artist, is also a good programmer!

Another way would be name each LOD layer, with the distances range in it and parse the name string, for example that is how Frictional Games made Penumbra, using only Maya to make the levels, all their models used special layer/mesh names and sufixes/prefixes. 

 

Edited by HMart
Link to comment
Share on other sites

  • 1 month later...

The main problem with LWO is that engine always "fixes" them, which often breaks them 😥
And engine cannot be changed due to backwards compatibility.

On the other hand, now we have OBJ support, which does not mess with geometry.
I already suggested to provide a way to load single group/object from OBJ by its name, by writing model name like "mymodelfile.obj$group=lod0". This way we can store all LODs in one OBJ file.
Maybe we can extend this group selection to other formats, although that would be harder.

Speaking of default distance.
The formula should be something like distance ~= A * sqrt(TriangleCount) with some constant A. I suppose constant A can be deduced by setting approximate average size of a triangle on screen with some default resolution (e.g. FullHD).

  • Like 1
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.

  • Recent Status Updates

    • Xolvix

      Took a break from TDM until I got my backlog under control. It's been months and it's still not "under control". Damnit.
      · 0 replies
    • Ansome

      I sleep well at night knowing the player will never see the absolute nightmare that is my sealing brushwork outside the playable area. Only the pointfile can judge me now.
      · 4 replies
    • JackFarmer

      Somehow I admire the fact that the material from Dune has now been filmed for the third time. Personally, I could never do much with the material, but as a child of the 80s, I of course know the David Lynch movie...and that movie was at least funny!
      · 2 replies
    • Baal

      Episode 3 of the second best Doom 3 mod, Phobos,  was just released.
      · 6 replies
    • snatcher

      TDM Modpack v4.2 released!
      · 1 reply
×
×
  • Create New...