31 réponses à ce sujet

[Talisander]

Hey all,

so a forum search for "draw distance" comes up with a couple posts from 6 months ago about people trying to use interior models like walls in big exterior areas and finding out that they disappear in-game (though not in the level editor) when you get too far away from them, unlike a lot of models from the human noble tileset (fne prefix) and other exterior tilesets.  

I'm having this problem, and I'm also finding a lot of other models like the two window props and the basic chimney, which you would think should be usable in outdoor areas, have the same limited draw distance.

So, does anyone know where in the .mmh, .msh, or .phy files the game is getting this draw distance?  (I'm assuming in the .mmh?)

I've tried comparing the files to exterior tileset files and playing with a few suspicious sounding variables, but I haven't hit on anything yet.

Alex

Modifié par Talisander, 07 juin 2010 - 01:38 .

[-Semper-]

to get this started your model needs additional lod models so it can be drawn from distance. to achieve this you should copy an instance of your original model with the suffix _1. i think you also have to edit the meta file of this model because within the lod model handling is saved.

never tried this my own first you should check the models which are drawn from distance in detail to get it right.

Modifié par -Semper-, 16 octobre 2011 - 09:35 .

[JasonNH]

-Semper- wrote...

to get this started your model needs 2 additional lod models so it can be drawn from distance. to achieve this you should copy 2 instances of your original model with the suffix _2 and _3. i think you also have to edit the meta file of this model because within the lod model handling is saved.

never tried this my own first you should check the models which are drawn from distance in detail to get it right.

I've been working on the same issue, trying some of these same tactics, and not getting anywhere. The suspicious thing is that models that have a far draw distance, such as exterior roof pieces, do not have any _2 and _3 suffix versions of the model. So why do those work just fine? I'd love to hear from someone who actually has this working, and please use small words for us modeling noobs.

[mikemike37]

its a *really* long shot but did you try setting punchthrough to 1 on the model (its in mmh)? that can cause models to show even when things like materials and cutaways tell them not to. just another avenue for you to try?

Modifié par mikemike37, 07 juin 2010 - 05:19 .

[Talisander]

Thanks for the ideas guys, I'll report back tomorrow once I've tried more stuff. Have not tried punchthrough, was suspicious but forgot about it after trying other ideas.

One interesting thing is that the Strings that have MshMain in their title in child node 5 of the .mmh files have a "_0_1" at the end on the human noble exterior tileset, but only a "_0" on the human interior tileset. Simply adding a _1 in the human interior .mmh files doesn't seem to do anything after a post to local, though.


I also need to do a write up on getting lightmapping working with retextured props, which ended up being a bit more complicated than we thought when you guys helped me out on that issue in my last post, but I think I have a pretty clear idea of what the lightmapper is looking for now.

Modifié par Talisander, 08 juin 2010 - 03:59 .

[-Semper-]

you are running in problems with lightmapper and your retextured models? could i ask you what you encounter?

[Talisander]

I'll write up more about this, but basically I was renaming .mmh files and changing the material reference but leaving the .msh and .phy references the same. I was also, of course, renaming and editing a .met file to go with the .mmh.


Here's a thread about it.

(where you and mikemike helped me immensely, I might add.)

And a follow up thread (with complications).



I found that this method doesn't really work with the lightmapper, because during the initial LM process the lightmapper looks for .msh files with exactly the same filename as the .mmh file. It then copies those .msh files to the temp directory. Then, when the actual stages of lightmapping, ambient occlusion, and shadow mapping are being done, the lightmapper actually looks for the .msh file referenced within the .mmh in the Temp directory rather than simply looking for a .msh file with exactly the same name. So it uses one method to find and copy the .msh and another method when it's actually using it.

This is why some models seemed to work with that first method and some didn't -- models which I'd used the original version of had already had their meshes copied to the temp directory and worked, while models I'd never used the original version of didn't work -- there was no identically named .msh for the lightmapper to copy over, so I got an error at every step about there being no .msh file in the temp directory.

One awkward workaround was to put the original models in every level along with the retextured ones, so the correct .msh file is copied to the temp directory during the beginning of the lightmapping process.

What I've ended up doing is actually renaming the .msh and .phy files and putting them in the data folder as well, and changing all the references within all the files, with the exception of 2 places which don't seem to matter, and actually seem to screw things up.

Another benefit of this method is, I don't think I have to include the .msh and .phy files in the package I give the user, because I can just use the renamed .mmh I wanted to in the first place when it comes to using the models in the game.

Anyway, sorry this is so rambling, I'll try to write it up more clearly soon.  (As well as the tutorial for the wiki I promised.)

Modifié par Talisander, 08 juin 2010 - 07:01 .

[JasonNH]

Talisander wrote...

Thanks for the ideas guys, I'll report back tomorrow once I've tried more stuff. Have not tried punchthrough, was suspicious but forgot about it after trying other ideas.

I tried this yesterday without success but I'm quite suspicious about my attempted workflow. Perhaps someone can tell me what I'm doing wrong.

The model I am trying to change is fhi_wall_stone_0. I extracted the MMH file, and then created the corresponding FBX files using tazpn's tools. From the FBX I created the MMH.xml file so I could edit it. I did my edit, and then converted the MMH.xml file back into an MMH file using the ResourceBuild/Processor/MMH/GraphicsProcessorMMH.exe utility from the Bioware tools directory. I then put the new MMH file in my override directory to test.

The problem is, it seems like no matter what kind of change I make to it, or even when making no change at all, as soon as I go through this set of file conversions all I get is the same old model except every instance of it is rotated by 90 degrees. Any insight into my mistakes would be appreciated.

[mikemike37]

if you dont need a modelling package to tweak your model in some geometry way, then you can change the MMH directly using the toolset. This will allow you to alter parameters like punchthrough for each object. of course, if you have other reasons to use a modelling package then your issue still stands.

[JasonNH]

mikemike37 wrote...

if you dont need a modelling package to tweak your model in some geometry way, then you can change the MMH directly using the toolset. This will allow you to alter parameters like punchthrough for each object. of course, if you have other reasons to use a modelling package then your issue still stands.

Heh, well that sure makes it a whole lot easier! Thanks MIke.

I am finally having some success. The punchthrough parameter didn't help, so I created fhi_wallstone_1 versions for the MMH, MSH, and PHY components and I now have the model appearing from infinite distances like many of the other exterior structures and props. It doesn't look exactly the same from far away but I think it's because I need to re-run the lightmapper. In any event, this is a huge step forward from where I was so thanks for the help everyone.

[Talisander]

oh my god, that's amazing. You have no idea how much work this will save me if it works. And how much nicer the final product will be.



I'm not sure I fully understand your method. Could you write up a quick walkthrough? (I understand how to get the files I need and everything, I'm just not sure if you're changing anything beyond the filenames?)

[Talisander]

Also, you may need to rename the .met file to get the new model to be lightmapped.

[JasonNH]

Well, I'll try to come up with a real walkthrough once I understand all of this better and have it working in game satisfactorily. Right now I am still groping my way through. In my specific case, I just opened the MMH, MSH, and PHY versions of fhi_wallstone_0, expanded all the nodes in there, and changed the _0 values to _1 where appropriate. I then saved the files as fhi_wallstone_1 and put them in my override directory.

The approach seems different for props that do not already have the _0 suffix. You have to create both the _0 and the _1 files and then change the prop to use the new _0 model file. This is still very tentative info though.

I am definitely having lightmapping issues right now and can't find the meta files. Where are the originals located? Thanks.

[Talisander]

Go to the first thread I linked a few posts above, there are instructions on extracting the meta files there.

Off the top of my head, it's in program files/dragon age/packages/core/datatools and then look in there for arttools.erf and open that with the toolset, then look for a .met file named the same as your model and extract it.

Modifié par Talisander, 09 juin 2010 - 02:03 .

[Talisander]

.met files are editable in notepad or other txt editors. The funny thing is, the tutorial I need to write is about getting custom props to work with the lightmapper -- hopefully the extent of the trouble you're having now (though it may end up being more complicated).

[JasonNH]

Thanks, I found those meta files just fine by looking at those posts. I totally forgot about that side discussion, oops.

Okay, so as far as I can tell, what you need is a set of _0 and _1 MMH, MSH, and PHY files for any prop that you want to appear at both High and Low LOD distances. Some props already have a _0 suffix associated with their model, some do not. If it doesn't, you have to create both the _0 and _1 suffix versions and then re-assign your prop to use the _0 model through the object inspector.

As far as creating the MMH, MSH, and PHY files, here are the elements that I've modified in order to get it working. Perhaps this can all be streamlined a bit too. Obviously, the number of elements you have to change will depend on the type of prop you are modifying. For instance, an interior wall prop I'm using has 6 MMH children under its GOB section, while other props have only 5. You basically just want to look for any places where an MMH, MSH, or PHY element name might be referenced and modify it to use the right suffix.

MMH File
========
Top Level Struct->MMH_NAME
Top Level Struct->MMH_MODEL_HIERARCHY_MODEL_DATA_NAME

Top Level Struct->MMH_CHILDREN->0->MMH_CHILDREN->5->MMH_NAME
Top Level Struct->MMH_CHILDREN->0->MMH_CHILDREN->5->MMH_MESH_GROUP_NAME

Top Level Struct->MMH_CHILDREN->0->MMH_CHILDREN->6->MMH_NAME
Top Level Struct->MMH_CHILDREN->0->MMH_CHILDREN->6->MMH_MESH_GROUP_NAME


MSH File
=========
Top Level Struct->NAME
Top Level Struct->MESH_CHUNKS->0->NAME
Top Level Struct->MESH_CHUNKS->1->NAME


PHY File
========
Top Level Struct->MMH_NAME

Please feel free to add/correct any of your own experiences to this issue. Thanks.

[mikemike37]

good to hear you got it working - thanks for sharing the solution!

[-Semper-]

haven't i said that to begin with?

[mikemike37]

aye, was a good figure. nice to see it written out for others stumbling upon the post... it cant harm

[Talisander]

Yeah you kinda did Semper, but you said _2 and _3. Any idea how the engine treats all these numbers differently?



Great job Jason!



You should post this on the wiki. Probably as its own page called "increasing the draw distance of props" and then link to it from the tutorials page.

[-Semper-]

yeah, mixed those numbers... sry^^
the hight detail base mesh is a 0.. btw you don't need separate meta files for the low lod models. that's all handled through the meta file of the base mesh.

Modifié par -Semper-, 09 juin 2010 - 06:30 .

[Talisander]

So I've actually gotten this working in a weird but much faster way. All I've done is copied the .mmh, .msh, and .phy files to my packages/core/data and then renamed the "_0" suffixes of every filename to "_1". No need to open the actual files!  Then I did the same thing with the meta files (only renaming the filename.)

The models never disappear and work fine with this one simple step. Not sure if this way has a disadvantage over actually changing all the references within the files.

I will try building lightmaps without the renamed meta files as per Semper's suggestion. That might make doing this even easier.

Alex

Modifié par Talisander, 09 juin 2010 - 10:59 .

[mikemike37]

oh, sneaky!

[ChewyGumball]

Just FYI, lower lod models should actually have fewer polygons so that the lod actually does something. The game will run faster if you do this.

[Talisander]

Right, but that would require using a modeling program I don't have. I'll just do it this way till I run into performance problems (I'm actually using fraps to see what kind of a performance hit I get in my areas this way.)