Jump to content


Photo

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


  • Please log in to reply
25 replies to this topic

#1 Bikerdude

Bikerdude

    Mod hero

  • Member
  • PipPipPipPipPip
  • 19912 posts

Posted 13 March 2018 - 08:42 AM

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 -

 

Attached File  woohoo.JPG   35.04KB   0 downloads

 

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 -

 


Edited by Bikerdude, 27 April 2018 - 02:27 PM.

  • Epifire likes this

#2 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1296 posts

Posted 13 March 2018 - 08:51 AM

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, 13 March 2018 - 09:00 AM.


#3 Springheel

Springheel

    Creative Director (retired)

  • Admin
  • 37188 posts

Posted 13 March 2018 - 09:31 AM

Does it work with skins?



#4 Bikerdude

Bikerdude

    Mod hero

  • Member
  • PipPipPipPipPip
  • 19912 posts

Posted 13 March 2018 - 09:32 AM

All the models your exporting would have to use the same skin, and the model would have to be added to the existing or new skin def.


Edited by Bikerdude, 13 March 2018 - 09:35 AM.


#5 grayman

grayman

    Master Builder, Coder

  • Active Developer
  • PipPipPipPipPip
  • 12553 posts

Posted 13 March 2018 - 10:03 AM

As you say, brilliant discovery!



#6 greebo

greebo

    Heroic Coder

  • Root
  • 16053 posts

Posted 13 March 2018 - 10:24 AM

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.

#7 Bikerdude

Bikerdude

    Mod hero

  • Member
  • PipPipPipPipPip
  • 19912 posts

Posted 13 March 2018 - 10:31 AM

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.



#8 Goldwell

Goldwell

    Team Member

  • Active Developer
  • PipPipPipPip
  • 2403 posts

Posted 14 March 2018 - 02:01 AM

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.


The Accountant
Part 1: Thieves and Heirs | Part 2: New In town

 

Shadows of Northdale Campaign

ACT I
 
Stand Alone Missions
Lord Edgar's Bathhouse | Spring Cleaning


#9 Bikerdude

Bikerdude

    Mod hero

  • Member
  • PipPipPipPipPip
  • 19912 posts

Posted 14 March 2018 - 02:24 AM

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



#10 Obsttorte

Obsttorte

    Scripting guru, Mapper

  • Active Developer
  • PipPipPipPipPip
  • 5592 posts

Posted 14 March 2018 - 03:04 AM

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
WIP's: Several. Although after playing Thief 4 I really wanna make a city mission.
Mapping and Scripting: Apples and Peaches
Sculptris Models and Tutorials: Obsttortes Models
My wiki articles: Obstipedia
Let's Map TDM YouTube playlist: ObstlerTube
Texture Blending in DR: DR ASE Blend Exporter

End of shameless self promotion.

#11 Bikerdude

Bikerdude

    Mod hero

  • Member
  • PipPipPipPipPip
  • 19912 posts

Posted 14 March 2018 - 05:24 AM

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

 

Attached File  Capture.JPG   99.26KB   0 downloads



#12 Goldwell

Goldwell

    Team Member

  • Active Developer
  • PipPipPipPip
  • 2403 posts

Posted 14 March 2018 - 09:00 AM

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.gif Capture.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.


  • Bikerdude likes this

The Accountant
Part 1: Thieves and Heirs | Part 2: New In town

 

Shadows of Northdale Campaign

ACT I
 
Stand Alone Missions
Lord Edgar's Bathhouse | Spring Cleaning


#13 Bikerdude

Bikerdude

    Mod hero

  • Member
  • PipPipPipPipPip
  • 19912 posts

Posted 16 March 2018 - 04:25 AM

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, 16 March 2018 - 11:57 AM.


#14 Epifire

Epifire

    Advanced Member

  • Active Developer
  • PipPipPip
  • 526 posts

Posted 16 March 2018 - 11:05 PM

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.


You need a model? Epi does you a model.

 

Toss me a PM I promise I don't bite.

 

 


#15 Obsttorte

Obsttorte

    Scripting guru, Mapper

  • Active Developer
  • PipPipPipPipPip
  • 5592 posts

Posted 17 March 2018 - 03:39 AM


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
WIP's: Several. Although after playing Thief 4 I really wanna make a city mission.
Mapping and Scripting: Apples and Peaches
Sculptris Models and Tutorials: Obsttortes Models
My wiki articles: Obstipedia
Let's Map TDM YouTube playlist: ObstlerTube
Texture Blending in DR: DR ASE Blend Exporter

End of shameless self promotion.

#16 Bikerdude

Bikerdude

    Mod hero

  • Member
  • PipPipPipPipPip
  • 19912 posts

Posted 17 March 2018 - 04:45 AM

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, 17 March 2018 - 04:45 AM.


#17 Springheel

Springheel

    Creative Director (retired)

  • Admin
  • 37188 posts

Posted 17 March 2018 - 12:57 PM

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?



#18 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1296 posts

Posted 17 March 2018 - 01:05 PM

If those models use the same material, DCs should go down. In Biker's example there are many different skins and materials, so merging those models into a bigger one won't make much difference.



#19 Bikerdude

Bikerdude

    Mod hero

  • Member
  • PipPipPipPipPip
  • 19912 posts

Posted 17 March 2018 - 01:58 PM

In Biker's example there are many different skins and materials, so merging those models into a bigger one won't make much difference.

Correct, in my case it was done to reduce the brush and entity count.



#20 Obsttorte

Obsttorte

    Scripting guru, Mapper

  • Active Developer
  • PipPipPipPipPip
  • 5592 posts

Posted 17 March 2018 - 06:10 PM

 

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.thedar.../?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.


  • Judith likes this
FM's: Builder Roads, Old Habits, Old Habits Rebuild
WIP's: Several. Although after playing Thief 4 I really wanna make a city mission.
Mapping and Scripting: Apples and Peaches
Sculptris Models and Tutorials: Obsttortes Models
My wiki articles: Obstipedia
Let's Map TDM YouTube playlist: ObstlerTube
Texture Blending in DR: DR ASE Blend Exporter

End of shameless self promotion.

#21 Epifire

Epifire

    Advanced Member

  • Active Developer
  • PipPipPip
  • 526 posts

Posted 17 March 2018 - 11:38 PM

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.


You need a model? Epi does you a model.

 

Toss me a PM I promise I don't bite.

 

 


#22 Obsttorte

Obsttorte

    Scripting guru, Mapper

  • Active Developer
  • PipPipPipPipPip
  • 5592 posts

Posted 18 March 2018 - 04:53 AM


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
WIP's: Several. Although after playing Thief 4 I really wanna make a city mission.
Mapping and Scripting: Apples and Peaches
Sculptris Models and Tutorials: Obsttortes Models
My wiki articles: Obstipedia
Let's Map TDM YouTube playlist: ObstlerTube
Texture Blending in DR: DR ASE Blend Exporter

End of shameless self promotion.

#23 Bikerdude

Bikerdude

    Mod hero

  • Member
  • PipPipPipPipPip
  • 19912 posts

Posted 18 March 2018 - 04:55 AM

Obsttorte normally I'd agree but I'm combining things on a per-visleaf/view basis.

Same here, mostly.



#24 Epifire

Epifire

    Advanced Member

  • Active Developer
  • PipPipPip
  • 526 posts

Posted 18 March 2018 - 05:56 AM

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.


You need a model? Epi does you a model.

 

Toss me a PM I promise I don't bite.

 

 


#25 Obsttorte

Obsttorte

    Scripting guru, Mapper

  • Active Developer
  • PipPipPipPipPip
  • 5592 posts

Posted 18 March 2018 - 06:28 AM

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
WIP's: Several. Although after playing Thief 4 I really wanna make a city mission.
Mapping and Scripting: Apples and Peaches
Sculptris Models and Tutorials: Obsttortes Models
My wiki articles: Obstipedia
Let's Map TDM YouTube playlist: ObstlerTube
Texture Blending in DR: DR ASE Blend Exporter

End of shameless self promotion.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users