Jump to content
The Dark Mod Forums

Cool new feature of DR 2.5.0: Export multiple FS + models as single model


Recommended Posts

So I have been going through my city WIP converting FuncStatics into .LWO models using the new export menu Greebo added -

 

Main Menu>File>Export Selected as Model -

 

post-496-0-26339700-1520947745_thumb.jpg

 

But then I discovered I could select normal FS and .LWO models and export them all as a single model :blink: So it them occurred to me I should be able to do the same thing with existing core mod models -

 

https://www.youtube.com/watch?v=Ar5jP3XqOwM&

Edited by Bikerdude
  • Like 1
Link to comment
Share on other sites

Obj is a common intermediate format, so you can import your model from DR and work on it in basically any modeling software. It might be useful when you need to block out your structure first, test it in first person mode, and then export to modeling software as a base.

Edited by Judith
Link to comment
Share on other sites

Nice to hear that this feature sounds useful to you folks, I had this specific use case in mind when I wrote the code.

 

Does it work with skins?

I actually haven't tested it using any models with skins applied, but it sounds like this should be supported. If it doesn't respect the currently applied skin, feel free to open an issue report.
Link to comment
Share on other sites

If it doesn't respect the currently applied skin, feel free to open an issue report.

Will do, and thank again for creating this feature.

 

Its has allowed me to work around the malloc error I kept getting with my city WIP, and upside is I believe I have found the brush limit of TDM 2.06 which is 30k.

Link to comment
Share on other sites

Nice to hear that this feature sounds useful to you folks, I had this specific use case in mind when I wrote the code.

 

I actually haven't tested it using any models with skins applied, but it sounds like this should be supported. If it doesn't respect the currently applied skin, feel free to open an issue report.

 

 

Does it work with skins?

 

Yes it does, some of the screenshots i've posted recently even have combined models using skins. However because they are all one model the skin is applied to all of them, so you can't have different model skins within that one model, they all have to be the same skin. This is mainly only a problem with say windows where you want some on or off, so I got around that by exporting all of the off windows separately and all of the on windows as one combined model, then applied the relevant skin.

Link to comment
Share on other sites

This is mainly only a problem with say windows where you want some on or off.

You can give the different windows different placeholder materials, which than allows you to exchange them seperately via your skin. This is done on some of the stock windows (for example models/darkmod/architecture/windows/windowframe_wood_40x36_glass.ase), where the glass side facing inside looks different then the one facing outside (for example one shows a brightly lit surface, while the other one is moonlit).

 

You only have to make sure that the placeholder material is aligned properly. The easiest way of doing this is to use normal window materials first, which you align as needed, and than exchange them with your placeholders. The placeholder material can either be a copy of the original material just named differently, or something like this:

 

textures/common/placeholder_X // the name of the material, whereas X are ongoing numbers to allow for several different materials applied
{
    qer_editorimage path_to_image // the image shown in the editor, not mandatory, but useful
    nonsolid
    noshadows
}

Create as much of them as you need (so placeholder_1, placeholder_2, ...) and you are happy to go.

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

@GW, how did the skins work though - did you just force enable a skin that worked on the non-combined model..?

Ah I see, if you your making a single model of all the same model you can force the old skin. It also works fine if your combining a bunch of different models, but the ones you want to apply the skin to (see below) only uses that skin -

 

post-496-0-05166600-1521023062_thumb.jpg

Link to comment
Share on other sites

Ah I see, if you your making a single model of all the same model you can force the old skin. It also works fine if your combining a bunch of different models, but the ones you want to apply the skin to (see below) only uses that skin -

 

attachicon.gifCapture.JPG

 

Yep that's exactly how I did it, just applied the spawnarg as you've done there.

 

I haven't run into any problems with it either yet so it seems to be working well.

Link to comment
Share on other sites

Nice to hear that this feature sounds useful to you folks, I had this specific use case in mind when I wrote the code.

The only 2x issue's that I have found with the exporter,

  1. is it removes the smooth shading from round or cylindrical objects, all my FS pipes now are sharp angled sides/edges to them.
  2. a lot of the models are now noclipmodels.
Edited by Bikerdude
Link to comment
Share on other sites

Fantastic work Greebo and thanks for pointing this out Biker! I really only map with models these days and I was having to eyeball module placement (in my modeling app vs DR coordinates) to turn a 30+ mesh building into a single model. LWO is my naitive file format for working on TDM, so this is gonna save me so much time! Rare is the case of an old gen level editor, where optimization is ever fun and easy.

Modeler galore & co-authors literally everything

 

 

Link to comment
Share on other sites

 


to turn a 30+ mesh building into a single model ... optimization

In regards to optimization turning several smaller models into one is not adviseable. It may be easier to handle and help avoid hitting entity limitations, but performance will suffer when doing so.

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

It may be easier to handle and help avoid hitting entity limitations, but performance will suffer when doing so.

I had to do it to avoiding hitting a brush limit, my only regret is the removable of smoothing shading on all the pipes I converted and discovering a bunch of models are randomly non-solid.

Edited by Bikerdude
Link to comment
Share on other sites

In regards to optimization turning several smaller models into one is not adviseable. It may be easier to handle and help avoid hitting entity limitations, but performance will suffer when doing so.

 

I've been wondering about this...I can see a large model getting hit by mutliple lights being worse than many small models being hit by single lights, but is there any other reason why performance would suffer? Couldn't it potentially reduce the number of drawcalls?

Link to comment
Share on other sites

 

I've been wondering about this...I can see a large model getting hit by mutliple lights being worse than many small models being hit by single lights, but is there any other reason why performance would suffer? Couldn't it potentially reduce the number of drawcalls?

This is more in regards to the renderer frontend. After the frontend has found out which visleafs will potentially contribute to the current rendering, it will go through the entities to see whether they are visible or not. To speed up this process, each entity has an axis-aligned bounding box it references. This is a simple cuboid containing the entity. As it only consist out of eight vertices, it is pretty easy (and fast) to determine whether the box is in the players view frustrum or not. If not, the entity isn't either, as it is contained inside the cuboid. If you want to take a look at those boxes type r_showViewEntities 1 into the console.

 

If you have several smaller models, of which some are not inside the players view frustrum, and therefore don't need rendering, the engine will be able to discard them pretty easely, as most of them will have bounding boxes not inside the view frustrum. If those smaller models are merged into one model however, the engine cannot exclude it and has to go through all the tris the model consists of to find out which of them needs rendering and which not. This is bad.

 

It is true, though, that you may get a lower amount of drawcalls in return. However. Drawcalls aren't the only thing that can cause performance issues. People are focusing way too much on the renderers backend, but the frontend is important, too. Remember the visportal discussion we had a while back (http://forums.thedarkmod.com/topic/18948-have-we-been-selling-visportals-short/?hl=visportal)

 

Also, when helping Biker with the performance for 'The Elixir', a lot of the performance issues were frontend related. So this isn't an academical problem.

  • Like 1

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

Obsttorte normally I'd agree but I'm combining things on a per-visleaf/view basis. Meaning the things combined were already going to be rendered regardless of where the player was standing in reference to said building. Some things still remain broken up a tad, or at least enough to not completely undermine the PVS culling. I've got some fairly complex module material stages that have redundant duplicates abounding for just one building, so it's a needed step. That said I've been able to shed close to 1,500 drawcalls and manually cut out another 5k shadows just from combing three bigger structures.

 

I'd also been working off of a, "visleaf bucket" standard where interior details of a keep, garden or compound are being created like a bucket with a visportal cap on top. This means that any time the player is outside (or more importantly below) the walls, it'll separate other expensive detail bits of the adjacent leaf all while remaining entirely open to climb over. I've also been considering methods for controlling region lights in a similar manner. Only thing is, OnTouching trigger values seem to be rather expensive for id4, so it's a bit more manual to setup the trigger gates. Noshadow or texture lights are an absolute must in this build strategy but it currently performs really good for having so many things in constant view.

Modeler galore & co-authors literally everything

 

 

Link to comment
Share on other sites

normally I'd agree but I'm combining things on a per-visleaf/view basis. Meaning the things combined were already going to be rendered regardless of where the player was standing in reference to said building.

Just because several models are in the same visleaf it doesn't mean they'll all get rendered. The visleafs serve only for a rough first approximation of what might need rendering (and sound propagation, but that's another topic).

 

In addition, I'm not saying that you can't combine stuff at all, it is just a matter of finding the right balance.

 

region lights

What do you mean by 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

Just because several models are in the same visleaf it doesn't mean they'll all get rendered. The visleafs serve only for a rough first approximation of what might need rendering (and sound propagation, but that's another topic).

 

In addition, I'm not saying that you can't combine stuff at all, it is just a matter of finding the right balance.

 

Oh man I totally get that. Here's a great way I think I can explain how I'd go about combining things. Because yeah, some stuff really shouldn't get tossed together because too much of the same building will be rendering (at more times than it would have been) and possibly overlap into other visleafs. I think one really good method is to see what's being rendered in wireframe and seeing what continuously renders the most at any given time. That gives a clear basis as to what can then be combined with little to no hampering of frontend rendering as you describe it.

 

Region lights are a stupid silly kinda trick I'm playing with. So the elevator pitch to describe region lights is to split the super large (moonlight for the whole map) into smaller regions. The goal then would be to run a script that checks the players region and toggle the appropriate light tied to his zone (while turning off the others). Zones would have to be approximated by PVS so that far areas aren't noticeably dark. But this would allow creation and smooth play of very big maps while keeping that pesky dynamic moonshadow count in check. That being said a script would keep things in DR cleaner, and would allow regions to operate independently. Say if you nocliped and started tripping zones out of sequence, the script could just check states (like the elevator script checks platform stops) and would prevent the moonlight from breaking. This would also eliminate the usage of on/off triggers or the expensive, "always checking" trigger volume.

Modeler galore & co-authors literally everything

 

 

Link to comment
Share on other sites

Just for clarification. What cannot be seen doesn't get rendered. The whole visleaf / small model approach only serves the purpose of speeding up the engine in finding out what to render.

 

Turning of lights that don't contribute to the currently rendered image will not help performance (at least not as much as you might expect), as at least all lights that cannot contribute (due to beeing in the wrong visleaf for example) will get discarded anyway.

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

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

    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
    • nbohr1more

      Please vote in the 15th Anniversary Contest Theme Poll
       
      · 0 replies
×
×
  • Create New...