• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

Attention Capt-X; quick question

Messages
10,163
Country
us-arizona
Hey Felix,


I have a quick question.

Are you capable of making a FS2004 model compiler? One that would could compile models without limits on numbers of polygons and without Vertice distance proximity limits?




Bill
 
A replacement for makemdl.exe? No, Sir. Sorry. I haven't really dug in that 4mm-issue yet, but I guess there are workarounds that wouldn't require a new compiler?
 
Roger that Felix.

Well, I was hoping... :D


A small historic bit of background on the compiler. It uses SCASM technology based on when the Pentium 386 came out. It has a load limit set on it (poly limit) so that it doesnt crash the computer, as the compiler is fed the entire process in one single dump which can cause the crash.

Thus the structure of the compiler itself, (SCASM) is ancient.

The 4MM limit was intended for the exterior but assigned the interior by mistake. The interior is where you would see micro parts in detail, and wouldnt be needed outside as they wouldnt be visible.

There are 2 work arounds now for the 4MM issue, though both require reworking mid-compile files.


I tried hiring a gentleman to create a better compiler. He was going to do a basic compiler that could do the job. He said he could create a full on compiler that could do all these things, no limits, for a certain price; $6K USD, which was fine by me. His base compiler would have been $2K USD. But, he disappeared. I never heard from him again. No money was transferred.


How difficult can it be to get a compiler made, lol... crazy... In a world filled with computers and computer programmers and software writers, you would think I could find a quick 40 people that could do it... nope.... lol..

arrgh



Bill
 
A replacement for makemdl.exe? No, Sir. Sorry. I haven't really dug in that 4mm-issue yet, but I guess there are workarounds that wouldn't require a new compiler?

While the 4mm weld problem does have a workaround solution, the triangle limit of 65k is a real problem...

Right now, the exterior model of the DA42 is bumping up against that limit. I've had to very carefully trim polys that weren't absolutely essential, as well as remodel some parts to reduce the poly count.

As it is now, there are 66,440 triangles. Just another 256 triangles added will cause the compiler to complete, but...

...the entire exterior model is invisible! :yikes:

I was trying today to add the 3d side vents for the canopy glass to the exterior model, and had to remove everything except the "frames" because the compiler would crash out because it overflowed...

Thankfully, there's no problem with the interior model (it's trim and slim!), so the full set of parts for the side vents may be included.

The export module for GMax produces a DirectX file irregardless of triangle count. It's the ancient and creaky MakeMDL.exe that converts the X file(s) to assembler and then invokes the SCASM compiler that's the bottleneck... <sigh>
 
Last edited:
Bill,

If only we could find someone that could make a compiler for us. Do you realise what that could mean???? FSX model mesh that could run in FS9, and with switches with extreme mesh detail and resolution. Exterior parts with amazing mesh accuracy...



If only...



Bill
 
Bill (Leaming),

While the 4mm weld problem does have a workaround solution, the triangle limit of 65k is a real problem...

Luka posted the complete solution to makemdl.exe woes in several posts at FFDS long ago.

As far as the “triangle limit of 65k is a real problem” thing goes, well, in my current project I have 47,930 compiled polygons in the engine alone! That’s the engine (P&W Hornet S1E-G), engine mount, exhaust and accessories, and it isn’t finished yet! It still needs the starter and generator – they’re installed but not completed - fuel pump, tach drive, vacuum pump and associated plumbing and wiring. At last count (not done too often since there are 14 .asm files involved), the entire model came in at 207,869 polys, and should be well over 220,000 now that the VC panels and 3D gauges are nearly finished. This compiles painlessly and performs extremely well in FS9, with every slider maxed out.

I compile each .x file as an LOD, and then edit the main .asm file to return it to normal as far as model types and scale are concerned. The VC consists of 10 separate models; total poly count a couple of months ago was 84,424. Each model is exported as an .x file named as an LOD (interior_100 through interior_190). Then I run them through makemdl to generate the .asm files.

Since makemdl doesn’t support LOD’s in the VC, it will complete with an error for the VC:

Assembling: C:\Users\x files\model75.azm
C:\Users\x files\model75.asm(576) : error A2006: undefined symbol : dict_cockpit_detail
IFIN1(5): Macro Called From
C:\Users\x files\model75.asm(576): Include File
C:\Users\x files\model75.asm(577) : error A2006: undefined symbol : dict_cockpit_detail
IFIN1(5): Macro Called From
C:\Users\x files\model75.asm(577): Include File
C:\Users\x files\model75.asm(578) : error A2006: undefined symbol : dict_cockpit_detail
IFIN1(5): Macro Called From
C:\Users\x files\model75.asm(578): Include File
C:\Users\x files\model75.asm(579) : error A2006: undefined symbol : dict_cockpit_detail
IFIN1(5): Macro Called From
C:\Users\x files\model75.asm(579): Include File
C:\Users\x files\model75.asm(580) : error A2006: undefined symbol : dict_cockpit_detail
IFIN1(5): Macro Called From
C:\Users\x files\model75.asm(580): Include File
C:\Users\x files\model75.asm(581) : error A2006: undefined symbol : dict_cockpit_detail
IFIN1(5): Macro Called From
C:\Users\x files\model75.asm(581): Include File
C:\Users\x files\model75.asm(582) : error A2006: undefined symbol : dict_cockpit_detail
IFIN1(5): Macro Called From
C:\Users\x files\model75.asm(582): Include File
C:\Users\x files\model75.asm(583) : error A2006: undefined symbol : dict_cockpit_detail
IFIN1(5): Macro Called From
C:\Users\x files\model75.asm(583): Include File
C:\Users\x files\model75.asm(584) : error A2006: undefined symbol : dict_cockpit_detail
IFIN1(5): Macro Called From
C:\Users\x files\model75.asm(584): Include File
Error!

And you can completely ignore this error! The .asm files are generated regardless of the error state.

Once the .asm file edits are complete, BGLC9 will happily compile the huge model, without any squawks at all.

I realize that some guys won’t need to go over the 65000 limit in the VC, but it can be done if necessary, and in my case it’s necessary, since I’ve got a lot of detail and lighting effects going on there. It’s nice to be able to model without bumping against the limit; no more time wasted trying to optimize the model and deleting detail to stay under it.

If only we could find someone that could make a compiler for us. Do you realise what that could mean???? FSX model mesh that could run in FS9, and with switches with extreme mesh detail and resolution.

Bill (Lionheart),

It seems to me that a “new” compiler isn’t needed, as BGLC9 does everything with a lot less fuss than makemdl ever did.

After you’ve done a few, it takes 5 minutes at most to complete the .asm edits, and I change a lot more than model type and scale. Most of it can be handled with copy/paste operations from reference files; the rest consists of changing a few numbers in 7 places in the main .asm file. I use Visual Studio 2008, it allows multiple files open in tabs and keeps a record of my searches in “Quick Find”, and that speeds up the process considerably and cuts down the typing, but Notepad will do just fine for this purpose.

All the switches and knobs in my VC are detailed and without distortion. You should give this method a try - just make sure “Keep Files” is checked in Middleman, then follow Luka’s directions. If you hit an error from BGLC9, then you made a mistake in your editing, so save original copies of the .asm files, go back and try again. I assure you it works.
 
Last edited by a moderator:
OH my GOODNESS!!!!!

This is what I have wanted to hear for many years now....

Thanks Prop. Very much appreciated. I will search for Lukas posts at FFDS this morning and see if I can get an export working.

Awesome work on your Radial. I am building an old Warner Scarab presently. The tops of those cylinders are not easy to make. A very sophisticated shape. Nice work on the ribbing on the center crank case. How on earth did you get all the detail for the back mechanicals? You even have the engine mount frame, lol... Nice attention to detail.

EDIT: Prop, could you post the location of where Luka's tutorial is on this subject? I looked through FFDS for it and didnt find a tutorial by Luka on models. Only Panel window popups. (Perhaps it was started by another member and Luka added his input on this concept?).


Bill
LHC
 
Last edited:
I vaguely recall Luka's posts from ages ago, but since at the time it wasn't really a problem for me, I didn't study/archive them...

But, that's not really the point. It shouldn't be necessary at all. Any repetitive process a human can do, is programmable.

Although I frequently export partial models while working so I can verify the results in-situ, I should not have to export the entire project with "some-assembly-required" as the final step... :coffee:
 

Thanks George! Believe it or not I tried to limit the complexity by using 6 or 8-sided cylinders for much of the engine, and using textures for detail, but it grew to enormous proportions anyway. Not a problem with modern hardware and FS9 though.

If you really want to see intricate 3D modeling, with no constraints by game performance, look here:

http://www.military-meshes.com/forums/index.php

Go into the “Aviation Hangar” forum. You’ll have to register (free) to see attached images, but it’s worth it. The Gloster Gladiator is amazing.


“EDIT: Prop, could you post the location of where Luka's tutorial is on this subject? I looked through FFDS for it and didnt find a tutorial by Luka on models. Only Panel window popups. (Perhaps it was started by another member and Luka added his input on this concept?).”

Bill,

There isn’t a tutorial as such, the posts are all over the place, spanning 3 years or more from 2006-2009, from the 4mm weld cure to the LOD fix for the 65K limit. I believe the first one for the weld thing is here:

http://www.aerodynamika.com/cgi-bin...neral;action=display;num=1134887975;start=8#8

and a search for “4 mm” or “4 mm weld” might turn up others.

For the 65K limit:

http://www.aerodynamika.com/cgi-bin/yabb/YaBB.cgi?num=1238961638/0

will get you started on LOD’s.


I’m reminded that two concerns when using the scaled method are: “What happened to my aircraft radius and VC eyepoint?”

The answer is if you edit the scaled up main .asm file properly, you’ll never see any difference between the model file compiled by BGLC9, and a normal sized model file spewed out by makemdl – except the file from BGLC9 won’t have mangled small parts, and if you bust the 65K limit, an invisible model.

I worked out the following by trial and error with a little common sense thrown in for good measure. I was using AFCAD to edit the model radius, but that left the VC eyepoint awry, so I began to look at the differences between a normal main .asm file, and a scaled file. If I recall correctly (it’s been awhile), I saw that the number “102”, which was showing up in AFCAD as the radius, was right there at the top, so I changed it to “7”, and that restored the model radius to normal. I went through the rest of the file looking for “102” and found some further differences which I mention below. My current procedure is to return the scaled main .asm file to the values found in a normal file.

There are eight numbers (not seven as I stated in my first post) that need to be edited (lines in bold):

; compile with BGLC /MDL C:\x files panel - instrument panel.asm
db 'R','I','F','F'
dd aircraft_model_end - $ - 4
db 'M','D','L','8'

db 'M','D','L','H'
visual_model_header label dword
dd visual_model_header_end - $ - 4
dd 0
dd 0
dd 102 (This needs to be changed)
dd 0
dd 0
dd 152
db 'F','S','8','0'
dd 2304
visual_model_header_end label dword

db 'D','I','C','T'
param_extension_dictionary label dword

I CUT THE ANIMATION CODE FROM HERE FOR BREVITY.

param_extension_dictionary_end label dword


db 'B','B','O','X'
dd bbox_end - $ - 4
df -11.603, -11.496, -3.048
df 11.825, 11.382, 31.936
bbox_end label word

db 'I','S','F','T'
dd ver_end - $ - 4
db "MakeMDL - FS90 (9.00.030612.02)",0
ver_end label word

db 'B','G','L',' '
dd aircraft_model_end - $ - 4
aircraft_model label BGLCODE
VPOSITION no_model,0,102,AIRCRAFT_PARAMS.llapbh.lla(So does this.)
VFILE_MARKER AIRCRAFT_PARAMS.texture_dir

IFMSK inside,AIRCRAFT_PARAMS.gen_model,GEN_MODEL_OUTSIDE+GEN_MODEL_DISPLAY
BGL_CALL shadow
VPOSITION no_model,0,102,AIRCRAFT_PARAMS.llapbh.lla(Here too)
SUPER_SCALE no_model,0,0,6 (and here)
VINSTANCE_CALL model_outside,AIRCRAFT_PARAMS.llapbh.pbh
no_model label BGLCODE
BGL_RETURN
shadow label BGLCODE
BGL_IF AIRCRAFT_PARAMS.gen_model,GEN_MODEL_NOSHADOW
BGL_RETURN
BGL_ENDIF
SHADOW_VPOSITION AIRCRAFT_PARAMS.llapbh.lla
SUPER_SCALE shadow_out,0,102,6 (this one too)
SHADOW_VICALL model_shadow,AIRCRAFT_PARAMS.llapbh.pbh
shadow_out label BGLCODE
BGL_RETURN

inside label BGLCODE
IFMSK inside2,AIRCRAFT_PARAMS.gen_model,GEN_MODEL_FRONT
inside1 label BGLCODE
BGL_RETURN
inside2 label BGLCODE
IFMSK inside3,AIRCRAFT_PARAMS.gen_model,GEN_MODEL_DOWNWARD
BGL_CALL shadow
BGL_RETURN
inside3 label BGLCODE
VPOSITION no_model,0,102,AIRCRAFT_PARAMS.llapbh.lla(one more)
SUPER_SCALE no_model,0,0,6 (last one)
VINSTANCE_CALL model_inside,AIRCRAFT_PARAMS.llapbh.pbh
BGL_RETURN

Using an .asm file from a normal, properly scaled model, get the numbers from the places shown above to use as a baseline. For my project, the numbers were “7” and “2”. In the scaled x 16 .asm file, they’re “102” and “6”.

After editing, it should look like this:

; compile with BGLC /MDL C:\x files panel - instrument panel.asm
db 'R','I','F','F'
dd aircraft_model_end - $ - 4
db 'M','D','L','8'

db 'M','D','L','H'
visual_model_header label dword
dd visual_model_header_end - $ - 4
dd 0
dd 0
dd 7 (Changed to “7”)
dd 0
dd 0
dd 152
db 'F','S','8','0'
dd 2304
visual_model_header_end label dword

db 'D','I','C','T'
param_extension_dictionary label dword

I CUT THE ANIMATION CODE FROM HERE FOR BREVITY.

param_extension_dictionary_end label dword


db 'B','B','O','X'
dd bbox_end - $ - 4
df -93.472, -28.206, -98.866
df 93.472, 28.157, 36.136
bbox_end label word

db 'I','S','F','T'
dd ver_end - $ - 4
db "MakeMDL - FS90 (9.00.030612.02)",0
ver_end label word

db 'B','G','L',' '
dd aircraft_model_end - $ - 4
aircraft_model label BGLCODE
VPOSITION no_model,0,7,AIRCRAFT_PARAMS.llapbh.lla (Changed to 7)
VFILE_MARKER AIRCRAFT_PARAMS.texture_dir

IFMSK inside,AIRCRAFT_PARAMS.gen_model,GEN_MODEL_OUTSIDE+GEN_MODEL_DISPLAY
BGL_CALL shadow
VPOSITION no_model,0,7,AIRCRAFT_PARAMS.llapbh.lla (Changed to 7)
SUPER_SCALE no_model,0,0,2 (Changed to 2)
VINSTANCE_CALL model_outside,AIRCRAFT_PARAMS.llapbh.pbh
no_model label BGLCODE
BGL_RETURN
shadow label BGLCODE
BGL_IF AIRCRAFT_PARAMS.gen_model,GEN_MODEL_NOSHADOW
BGL_RETURN
BGL_ENDIF
SHADOW_VPOSITION AIRCRAFT_PARAMS.llapbh.lla
SUPER_SCALE shadow_out,0,7,2 (Changed to 7 & 2)
SHADOW_VICALL model_shadow,AIRCRAFT_PARAMS.llapbh.pbh
shadow_out label BGLCODE
BGL_RETURN

inside label BGLCODE
IFMSK inside2,AIRCRAFT_PARAMS.gen_model,GEN_MODEL_FRONT
inside1 label BGLCODE
BGL_RETURN
inside2 label BGLCODE
IFMSK inside3,AIRCRAFT_PARAMS.gen_model,GEN_MODEL_DOWNWARD
BGL_CALL shadow
BGL_RETURN
inside3 label BGLCODE
VPOSITION no_model,0,7,AIRCRAFT_PARAMS.llapbh.lla (Changed to 7)
SUPER_SCALE no_model,0,0,2 (Changed to 2)
VINSTANCE_CALL model_inside,AIRCRAFT_PARAMS.llapbh.pbh
BGL_RETURN

Now BGLC9 will compile a properly scaled model with a normal aircraft radius and VC eyepoint.

It can be a little confusing when you first start out with editing .asm files. Absent the animation stuff, the main file is actually pretty simple, the model files are far more complex, but well worth the effort involved to get into them, since you can massage materials and work around even more of makemdl’s limitations.

You can’t make any mistakes though, if you drop a comma from a material property line, or mis-number a model line or include then BGLC9 will choke on it. So go slow and be methodical, and remember, if it doesn’t compile, don’t be discouraged, you made a mistake (or several) somewhere, and once corrected it will work okay.

Once mastered, it puts the fun back into modeling for FS9, and removes several frustrations all at once.

“Awesome work on your Radial. I am building an old Warner Scarab presently. The tops of those cylinders are not easy to make. A very sophisticated shape. Nice work on the ribbing on the center crank case. How on earth did you get all the detail for the back mechanicals? You even have the engine mount frame, lol... Nice attention to detail.”

Thanks. Yeah the rocker boxes on the single row P&W engines are a complex shape, compounded by the fact that the exhaust side is built up with extra fins for cooling so the whole jug from the head upwards is asymmetrical. The ribs on the nose case was easy compared to the cylinders.

I modeled the accessories from photos of them, and from illustrations in manuals.
 
“But, that's not really the point. It shouldn't be necessary at all. Any repetitive process a human can do, is programmable.

Although I frequently export partial models while working so I can verify the results in-situ, I should not have to export the entire project with "some-assembly-required" as the final step...”

Couldn’t agree more. However, this is the only viable alternative I’m aware of, and as awkward and labor intensive as it is, I’m grateful that Luka worked it out.
 
Back
Top