FS2004 Increase polygons in FS9 trick not working

[Alexis]

I read that by exporting your VC model in parts, and then naming the _interior.x files as interior_100.x, _200.x e.t.c. you can trick makemdl into merging them into a single object. I did try to do it and it doesn't work at all. I also tried doing it using only some parts of the interior with a vertex count still over the FS9 limit -just in case some parts were corrupt.

Any ideas on how to do it?

And another question. I saw an ambient_snow part in the parts.xml file of Gmax, that should work similar to ambient_rain. Logically that means that I could have VC snow effects just like there are in the 2D panel. There is a snow drop material in the FS texture folder, as well as a series of SnowA,B,C e.t.c. Does anyone have an idea if this could be used?

 

[Alexis]

Here's the error log.

 

[PropTrash]

I read that by exporting your VC model in parts, and then naming the _interior.x files as interior_100.x, _200.x e.t.c. you can trick makemdl into merging them into a single object. I did try to do it and it doesn't work at all.

Makemdl doesn’t “merge” them, it outputs an .asm file for each (with "keep files" checked), and with some simple edits to the main .asm file to remove the LOD tags (IFSIZEV, IFIN1, BGL_JUMP_32), you can then compile with BGLC_9, rename the .bgl file extension it outputs to .mdl, and be free of Makemdl’s limitations.

Looking at your error log, it looks like the trouble is with "B717_200.x" and possibly “B717_200_shadow.x” being too big. I'm no expert on Makemdl error messages, but those probably relate to the "B717_200_full" and "B717_200_2" the log references. If I recall correctly, the message: “error A2071: initializer magnitude too large for specified size” means that part of the model is over the limit, and you’ll need to shuffle some parts around or split that LOD model and create another LOD model that’s under the 65K ceiling (sometimes easier said than done – I know). I’ve only had one of those errors, and it’s been 2 years ago or more, but I think that’s what it’s squawking about.

Has your exterior model ever compiled successfully through Makemdl before you tried it as an LOD model?

For the other errors - “error A2006” is the compiler choking on discreet LOD’s for the VC, since they aren’t supported for the interior model. You can ignore those - when you compile with BGLC_9 it won’t care about that.

I also tried doing it using only some parts of the interior with a vertex count still over the FS9 limit -just in case some parts were corrupt.

I don’t understand what you’re saying here - especially the bit about interior parts with a vertex count over the FS9 limit. Did you mean "parts" or "model(s)"? And if you're talking about the LOD model you made, if you know it’s over the limit, then why try to compile? Makemdl will still choke on a big model, it doesn't matter what it's named. The goal here is to feed it small chunks that won't upset it, then assemble them from .asm files and compile a final model with BGLC_9.

Before you go further, I think the best way to get started with this is to create some simple test .x files - a box or cylinder will do – then name them as LOD, and run them through Makemdl. Edit the resulting main .asm file to remove the LOD commands, then compile with BGLC_9. Once you’re familiar with the process, then you can try it on a complex project.

 

[Alexis]

Well, the exterior on its own, and the exterior+cockpit compiles perfectly.
The problem is when I add the full interior to the compilation. The Cabin+Cockpit+Wings are ~100k polygons, around 270k vertices IIRC. What I did is export the VC+cabin model in parts of 30-40k vertices as .x files, and try to compile. That's when the errors show up.

 

[Flusirainer]

LODs for VC?

What is the meaning?

 

[PropTrash]

Well, the exterior on its own, and the exterior+cockpit compiles perfectly. The problem is when I add the full interior to the compilation. The Cabin+Cockpit+Wings are ~100k polygons, around 270k vertices IIRC. What I did is export the VC+cabin model in parts of 30-40k vertices as .x files, and try to compile. That's when the errors show up.

You only have one file for the exterior model right? You could try renaming the exterior .x file to something simple (exterior.x or B717.x), and avoid using numerals preceded by the underscore character such as “B717_200”, or even rename it to “B717_100”. Makemdl is pretty weird about names, and I'm wondering if it expects to see a "_100" .x file if there's a "_200" file loaded - but I’m just guessing here. Another thing you could try is to split the exterior model into two LOD models, name them “exterior_100” and “exterior_200” and recompile.

I got into this from the other way around - my exterior model was too big, and so I split it into three LOD models and started out that way. Then due to the panel and other considerations in the VC that I won’t go into here, I wound up with 9 interior LOD models.

LODs for VC?

What is the meaning?

Trying to compile a larger, more complex model with BGLC_9 than Makemdl will allow.

 

[Alexis]

No luck even after splitting the model...

 

[PropTrash]

No luck even after splitting the model...

Well, this doesn’t seem to be your first time at the rodeo, so Makemdl being cranky probably ain’t a new thing for you.

Try compiling with a one part exterior model. Create a box, export, and load that .x file into Makemdl with your interior files. It should complete (but not compile) with an “Error!”, which should be: “error A2006: undefined symbol : dict_cockpit_detail”. There should be a number of those. If “error A2071” comes up again, then something else is going on.

If that’s successful, try exporting just the fuselage from your exterior model, and see how that goes. From there you’ll need to add parts in small manageable groups, until the error returns. This cause could be something as simple as a name, or animation or whatever that Makemdl doesn’t like in these circumstances.

Something else that occurs to me: try compiling without the interior parts, just the single exterior .x file that compiled successfully as a normal model. If that works, try again but add a single interior model.

You might also want to rename your interior LOD models to use _100, _110, _120, _130 , _140 - instead of _100, _200, _300, _400, _500. I’m using _90 , _100 etc, using higher numbers may be a problem.

That’s all I can think of at the moment; hopefully you’ll find a cure.

 

[lionheart]

Man.. This is interesting stuff guys.

I'm amazed no one has done a super well done tutorial on how to do this. (or have they and I missed it.. ).



Bill

 

[Alexis]

Unfortunately it didn't work out. Even when exporting only parts of the interior, I got the same errors. I'll keep trying it and see what happens.

 

[Deleted member 1281]

Just a thought, you are sure you are using the right part naming convention to begin with, ie

partname_LOD_### (where ### is 100 etc)

 

[PropTrash]

I'm amazed no one has done a super well done tutorial on how to do this. (or have they and I missed it.. ).

There’s no tutorial that I’m aware of Bill, just bits and pieces floating around at FFDS. I think I posted some links to those in another topic.

Unfortunately it didn't work out. Even when exporting only parts of the interior, I got the same errors. I'll keep trying it and see what happens.

Sorry to hear that Alexis. Good luck with it.

Just a thought, you are sure you are using the right part naming convention to begin with, ie partname_LOD_### (where ### is 100 etc)

That’s a good question, but we’re concerned with the .x file name, not part names. It did get me thinking though, and I looked into the Makemdl SDK.

The SDK is somewhat confusing (to me anyway) about LOD’s, with the info for the Main Tab input file box and LOD tab advising you that:

“ [_LOD] is the model LOD. LOD (level of detail) is a three-digit number from 000-400.”

“_###: the ### is used as the LOD value. The LOD value ranges from 000 – 400 and is the pixel size on screen that determines when this model should be used.”

And then, for discreet and per part LOD:

“For discreet LOD, you must specify a different model for each LOD. Store each LOD in a different .x file and name each file <Base Name>_LOD_###.x (where ### is 0–200 ).”

“For PerPart LOD, you must name the frames/parts in the .x file. If a part name ends in “_LOD_###” (where ### is 0–100),”

I get the per part bit, but the other two, 0-200, 000-400, okay whatever...I've seen worse in MSFS documentation....

I’ve never bothered with LOD models, so all of the above is useless information to me. What I did for this exercise in defeating Makemdl was to name my .x files by appending _100 to _300 and interior _90 to _100 and so on. As per Luka’s advice at FFDS.

After the model compiles, or rather, completes with VC errors, this file name convention does generate the LOD commands in the main .asm file for the models (model_outside, model_inside etc.) so that indicates to me that "_LOD" doesn’t need to be part of the filename for this purpose, as least where my efforts are concerned.

However, if I were having trouble with it, you can bet that _LOD_100 in the filename would be something I’d try!

 

[lionheart]

Just out of curiosity, how do you guys go about doing the actual 'compile' ?

For instance, do you make your Edits in Notepad? and then do you then take a cluster of say 5 files and drop those 'onto' the BGLC-9 program icon?

Or do you combine the raw files via a copy/paste method into one single, gigantic file and compile that?

 

[Alexis]

Well, it does work, finally!

I was getting the dict_cockpit_detail error in BGLC. That happened because I forgot to remove the test lines from the main .asm file. I also didn't add the BGL_RETURN command.

@Lionheart: We're just doing our edits in the .asm file that needs them (i.e. B717_200_VC.asm in this case, or B717_200_VC_0.asm if I wanted to avoid the 4mm weld). Then click & drag the main .asm to BGLC9.

 

[PropTrash]

For instance, do you make your Edits in Notepad?

Notepad works just fine for the edits, but Visual Studio is a much better choice for me, since I edit more than the just the main .asm. It remembers my previous searches, so I can Ctrl+F through the file, selecting what I want from the drop down menu, then making the edit and going on to the next. Notepad is a little awkward in comparison.

and then do you then take a cluster of say 5 files and drop those 'onto' the BGLC-9 program icon?

On my current project, I have 15 .asm files that result from compiling 14 .x files. Once I’ve edited the .asm files, I drop them on BGLC_9, and go do something else for 5 or 6 minutes. Once it spits out the .bgl file, I paste it into the model folder, rename to .mdl, and I’m good to go.

Or do you combine the raw files via a copy/paste method into one single, gigantic file and compile that?

Naw, its all individual files that represent each model. Those are referenced in the main asm file:

model_outside label BGLCODE

LOD_0 label BGLCODE
BGL_CALL_32 LOD_0L
LOD_1 label BGLCODE
BGL_CALL_32 LOD_1L
LOD_2 label BGLCODE
BGL_CALL_32 LOD_2L
LOD_3 label BGLCODE
BGL_CALL_32 LOD_3L
BGL_RETURN

model_inside label BGLCODE

INSIDE_0 label BGLCODE
BGL_CALL_32 INSIDE_0L
INSIDE_1 label BGLCODE
BGL_CALL_32 INSIDE_1L
INSIDE_2 label BGLCODE
BGL_CALL_32 INSIDE_2L
INSIDE_3 label BGLCODE
BGL_CALL_32 INSIDE_3L
INSIDE_4 label BGLCODE
BGL_CALL_32 INSIDE_4L
INSIDE_5 label BGLCODE
BGL_CALL_32 INSIDE_5L
INSIDE_6 label BGLCODE
BGL_CALL_32 INSIDE_6L
INSIDE_7 label BGLCODE
BGL_CALL_32 INSIDE_7L
INSIDE_8 label BGLCODE
BGL_CALL_32 INSIDE_8L
INSIDE_9 label BGLCODE
BGL_CALL_32 INSIDE_9L
BGL_RETURN

So even if you did put everything into one file (and I have no idea if that would work), you’d just be making unnecessary work for yourself - removing all the models, editing out the bgl_riff_end stuff etc. Not worth it.

 

[PropTrash]

Well, it does work, finally!

Just saw this after my reply to Bill. Good to hear! As I said in reply to your PM, most of the problems with this are mistakes editing the .asm files. I've made more than a few...

I was getting the dict_cockpit_detail error in BGLC. That happened because I forgot to remove the test lines from the main .asm file. I also didn't add the BGL_RETURN command.

Yeah, I've been doing this for two years now, and last month BGLC_9 wouldn't cough up a bgl file for me, because I used "BGL_CALL" instead of "BGL_CALL_32" when I changed from "BGL_JUMP_32"....

 

[Alexis]

By the way, here's the link to the method, in the FFDS forum -unlike me, please read carefully!
http://www.aerodynamika.com/cgi-bin/yabb/YaBB.cgi?num=1238961638/0

 

[lionheart]

Many thanks guys.

This is enginious... I cant believe its not common practice now for everyone that creates complex FSX models that want them in FS9...

We definately need one single, good tutorial on how this is done. I am going to see if I can do this (after my next project) and then do a tutorial on it. Sounds danged awesome....



Bill

 

[PropTrash]

We definately need one single, good tutorial on how this is done. I am going to see if I can do this (after my next project) and then do a tutorial on it. Sounds danged awesome....

Just to be clear, in his posts at FFDS, it was Luka who figured out how to do an end around Makemdl and avoid the 4mm weld problem in the VC. That goes back to 2006, and was invaluable to me when I started my current project a couple of years ago. Last year, he came up with a solution for the 65K limit, and since editing .asm files was already familiar territory, I jumped right on that one too (pushed back the project completion date by far, since I immediately started piling on detail and features). Anyway, you might want to consult with him when you do your tutorial, since it’s his genius that’s driving this bus, and he might have something new to add.

I was tired of juggling things to stay under the 65K limit, and of having small parts mangled, so his methods breathed new life into modeling for FS2004. FS2004 rocks on an I7, and using Luka’s techniques you can pile on the polygons and detail to produce a complex model – without any worries about slowing the game down, as long as your computer hardware isn't lame.

Once you get into it, there are other advantages to tweaking the .asm files. Since Makemdl doesn’t support emissive materials that are textured, by editing the material properties post Makemdl, and compiling with BGLC_9, textured emissive materials are then possible, and I use them for instrument lighting on 3d and 2d gauges, VC warning lights, digital displays etc.

On my current project, I have 6 levels of lighting available: when the panel lights are off, you see the dim glow of radiolite paint on the pointers and numbers on the dials of vintage instruments, with lights on, a rheostat controls the backlighting that goes from dim to bright in 5 stages as the knob is turned. The lights work day and night, with the radiolite paint visible at dawn/dusk/night lights off only. Misho worked out the tweaks for material properties and posted them at Avsim a few years ago, in another example of thinking outside the box.

 

[lionheart]

My goodness man, that is outstanding!

That greenish radio paint is just brilliant!

You have brought FSX modelling to FS9 and added more abilities, lololol...

And the props will animate properly, lol...

Thanks so much for the heads up. I'll contact Luka.



Bill