MDL Model File Formats
Results 1 to 8 of 8

Thread: MDL Model File Formats

  1. #1

    MDL Model File Formats

    Quote Originally Posted by Aleatorylamp
    Update:
    It worked!
    Now gun barrels and muzzles are all rounder, including the sideguns, and it definitely looks better on the model, as can be seen in the screenshots. The .mdl file is now 72462 bytes.
    Hello Aleatorylamp,

    Your note about the MDL file size had me wondering.
    I understand there is probably no direct correlation between the MDL file size and the Data Size of the SCASM code, but I would imagine they are probably somewhat related.

    I was very surprised that the file size was so small.
    Attached is a screenshot of a directory listing of the MODEL directory of the A6M2 I had been working on recently.
    This is just after the Center of Gravity shift and before the latest additions which were only on my Development Machine.
    For some reason, I had an old copy of the Aeroplane on my Laptop.

    It only went through Aircraft Animator once, thus the NMP file is the original file size as generated by Aircraft Factory 99.
    The actual file size is 71680 Bytes.
    The output from Aircraft Animator presumably was Aircraft Animator 133K format because I do not believe it would have fit in a 64K format.
    I never had to switch model formats after that.

    The MDL file size in the directory is 136192 Bytes. The size of the Backup file is meaningless because it is really just an intermediate save as I was making edits to the SCX file and thought there might be a possibility of screwing things up with the changes.

    For the Virtual Cockpit View, additional CALL or CALL32 do increase the Data Length, but not by much (just a few bytes).
    In the case of all the Japanese A6M, the Canopy Frame is very heavy in terms of Polygon Count and it is just as large when it is flipped inside out and added to the end of the SCX file to be called by the VC view.
    There were no problems adding the internal Canopy Frame.

    If you are still following the set of instructions for relocating the V-Cockpit that I sent to you, we are both probably using the same versions of tools for SCASM:

    MdlDisAs version 2.01
    SCASM version 2.96

    The only real difference that I can see is that we were running on different Operating Systems: I was using Windows 98 SR2.

    - Ivan.
    Attached Thumbnails Attached Thumbnails DirectoryListing.jpg  

  2. #2
    Hello Ivan,

    Interesting! I suppose it is a matter of how much the file grows with the addition of
    extras. Changing Calls to Call32īs is a requirement on the way along. The ones I did
    these days went from about 65K to 72K. Probably 65K is just about as far as AF99
    can build, and the rest is the additions.

    So it seems that other programs, like the ones the stock CFS1 aircraft are built with,
    build larger .mdl files, which can then also fit into SCASMīs capacity for 133K.

    Yes, Iīm still using the original instructions for SCASM-repairing the VCockpit that
    came from Hubbabubba.

    I didnīt really need the ones you sent two days ago, so I must admit that I
    havenīt used them. Thanks anyway, because they may come in handy anyway.

    I noticed that after a .mdl file could no longer be updated and a new .mdl file
    needed to be written, the Aircraft Animator 133K format was no longer recognized
    by the sim, but I tried the FSDS small format 133K option and it worked on the sim!

    Flipping things inside-out is not something I can do, but I have a substitute process,
    tagging components with "Collection". The advantage of this is that it automatically
    shows both sides of the panel, it can also be textured.

    In the SCASM listing it appears as a sequence of numerous individually labelled panels
    of 4 points, with a "return" instruction at the end of the sequence, very much unlike a
    normal smooth component, which is contained within a block of text after a label.

    Well, anyway, itīs very satisfying and rewarding that one can enhance models with
    SCASM.

    Cheers,
    Aleatorylamp
    "Why make it simple if you can also make it complicated?"

  3. #3
    Hello Aleatorylamp,

    I just spent most of the late afternoon and early evening removing and replacing the battery for one of our minivans.
    I had to come inside about every 15 to 20 minutes to warm up because I could not feel my fingers any more.
    I had to quit just before fastening down the bracket to the battery because at that point, I could not tell whether I was holding pieces I needed to install either by feel or by sight because there wasn't enough light to see down into where the pieces needed to go. There were too many opportunities to lose something in the engine bay and never find it again.
    I had to collect tools by flashlight.

    In warm weather with good lighting, this would have been a fairly easy job. It makes one think how the Soviets and Germans maintained equipment in the Winter. It probably wasn't THAT cold but it was enough that the grease in my ratchet must have congealed because the tool would not work reliably any more.

    ----------

    The requirement for a CALL32 as versus a CALL isn't necessarily because of an increase in code size; It is simply relative distance from where the subroutine call is made.
    Please observe that when pieces are added to an Interior Cockpit View, there is often only a single new subroutine call, but it often needs to be a CALL32 because the COCKPIT view is at the front of the code and the piece (aft bulkhead perhaps?) that is being re displayed is too far away for a CALL to work.

    I am certain AF99 can built MDL files larger than 64K. Some of my models have gotten on the complicated side as have yours.
    The problem comes when Aircraft Animator gets the MDL and does its additions. If the result at that stage is under 64K, then it uses AA 64K format and life gets ugly. If the additions push it over 64K which it usually does, it uses AA 133K format and we go merrily along without a problem.
    I haven't yet hit the data limit for a 133K MDL, so I don't know what happens in that case, but I HAVE hit the 64K limit.
    I have also had MDL that stayed under 64K even with animations such as the Eindecker.

    The Cockpit viewpoint shift for Chase view and Quick Combat came from Hubbabubba's email. The additions for an actual Virtual Cockpit with extra pieces to cover bleeds and Canopy Frames and other such is actually my additions when I figured out that the idea could be expanded. The document I sent you is actually a copy of the text of the email with a lot of additional notes over several years for more specifics as I was figuring things out. Ever couple years, I take the hand-written notes I make to my hard copy I keep by the Development Machine and add them to the electronic copy.
    At one point, I was working on something I call "Group Glue", but the problem was that it needed so much modification of the SCASM code before any testing that I tended to make errors that were very hard to find. That is why there are just parts of that in the notes. It also wasn't something that could be done consistently across every MDL.

    The instructions from a couple days ago was for something like the Eindecker if it needed a lot of pieces added via SCASM and hit the 64K data limit. I believe I hit that issue with the Ki 61 Hien a few years back.
    I am still quite convinced that I could take your SCX code and drop it into a AA 133K container and retain future ability to edit with SCASM. This is hard to prove at the moment with no model tools loaded on any running machines though.

    The problem with using a "Collection" type Component to replace a "Smooth" or "Sharp" Component is that unless you plan the ordering of the Parts very well, you will get polygons of the Collection bleeding through other polygons of the Collection. You don't get that problem with a Smooth or Sharp Component, but the down side is that for something like a Canopy Frame, all the interior facing polygons of the opposite side will be missing.
    I believe that is less of a problem which is why I build that way.

    SCASM does offer a lot more possibilities than we are using now. That is one of the reasons I was experimenting with the Me 109E and FW 190D. They offered the ability to experiment on a project with pretty minimal preparation and no demand for completion if I had been unsuccessful.

  4. #4
    Hello Ivan,

    Here it is cold, humid and rainy, although 12šC is only cold compared to the summer here,
    but feels colder because of the humidity. However, it would definitely not qualify as cold
    in other places on the planet!

    Regarding SCASM, it is probably more complicated for me than it is for you, and I can only
    do as much as I can understand.

    Of course, the concept of increased "distance" in the code is what defines when a Call
    command must be substituted for a Call32 command, although I referred to it as a result
    of the increased code size.

    Normally, I find that fixing the VCockpit view does not add much more to the code than
    the lines used to call the different elements to correct their display order.

    What increases it, is the substitution of the simple 2D elements I use in AF99 to reduce
    the code-size to below the 1200-part compilation limit, for the more code-rich 3D elements
    required to complete the model.

    In recent cases it was the 5 machine-guns and 2 radiators, which required quite a number
    of Call commands changing to Call32īs - probably more than 10.

    Then, observing how "collection" tagged components work, I have not had any problems
    (yet) to call them correctly. The problem is, that it is the only way I know of, to show
    components from the inside.

    Your "group glue" concept sounds interesting, and quite complicated. One good example are
    the animated propellers 1 and 2. It was a bit complicated to trace the origins the calls for themn, lthough the good thing was that the propblurs were automatically included!

    A fine example of a "group glue" - easier to trace than to reproduce, I must say!

    Anyway, it is fascinating to see how SCASM works!

    Good luck with your minivan-fixing in the cold!

    Cheers,
    Aleatorylamp
    "Why make it simple if you can also make it complicated?"

  5. #5
    Hello Aleatorylamp,

    12 Degrees C would have been about perfect. I figure it was about 3 Degrees C when I started in the afternoon and the sun was still out and got progressively colder and much more windy. I had a space heater but it didn't help much. The wind was strong enough to close the lid to my tool box and gusts didn't have any trouble going through my jackets.

    The problem with "Collection" Components isn't that it is hard to call them correctly. It is more that it is hard to create a Collection Component that doesn't bleed through ITSELF at some point.
    As for flipping a Smooth or Sharp Component inside out, you will observe that each polygon is a (X.Y,Z) direction with a Length. This describes a vector. All I am TRYING to do is to reverse the direction of each vector of the Component.
    It works MOST of the time. I am pretty sure there is a bug somewhere in my programming so I just look at the result to confirm that it is looking like it should before using the flipped Component.
    I am sure you can program the same thing and maybe yours won't have the bug that mine seems to have. I believe the concept is pretty sound though the fact that the vectors are not in ideal alignment may be part of the problem with my program.

    We never have worked by exactly the same processes and you seem to get things done much quicker than I do, so if what you are doing now with SCASM works, Keep doing it! I am also a beginner with SCASM and learn something new with just about every project.

    - Ivan

  6. #6
    Hello Ivan,

    Thanks for explaining.
    I see. Then as an excersize, for example, I could put in duplicated normal smooth canopy frame components, run it through SCASM and investigate what you are saying about the direction vector, and see if I can flip one of them to call it from the VCockpit.

    Actually, it would also be good to call it for an outside view as well, so that cockpit spars are visible
    on the opposite side. The problem here would be where to place it in the listing, so that the glue sequence makes the opposite inside cockpit spars visible from outside, avoiding the typical bleeds
    of a Collection-type component placed in one place to be visible from both sides.
    That will require a bit more thought...

    Cheers,
    Aleatorylamp
    "Why make it simple if you can also make it complicated?"

  7. #7
    Hello Aleatorylamp,

    Battery installation is complete. Needed a bit of help from my Wife to get one of the hooks in place. Her eyesight is a better than mine and even in daylight it wasn't easy to put enough light where it needed to go.
    I also found out today that the nuts and hooks don't really interchange well. They are supposed to be identical, but are not really. It probably explains why the hook in back did not stay in place last night. Every time the nut is tightened, the hook twists out of its hole in the battery tray. In the front position, it can be held in place. In back there is no room to get a hand on the bottom of the hook.

    By the way, the temperature will get down to -3.9 Degrees C tonight.....

    Quote Originally Posted by aleatorylamp View Post
    Thanks for explaining.
    I see. Then as an excersize, for example, I could put in duplicated normal smooth canopy frame components, run it through SCASM and investigate what you are saying about the direction vector, and see if I can flip one of them to call it from the VCockpit.
    What you just described is basically all I am doing.

    Quote Originally Posted by aleatorylamp View Post
    Actually, it would also be good to call it for an outside view as well, so that cockpit spars are visible
    on the opposite side. The problem here would be where to place it in the listing, so that the glue sequence makes the opposite inside cockpit spars visible from outside, avoiding the typical bleeds
    of a Collection-type component placed in one place to be visible from both sides.
    That will require a bit more thought...
    I have thought about doing this, but the payoff never seemed to be quite worth the effort. Also, I like the idea that the exterior model is entirely created by Aircraft Factory 99 without additions. That is why even though I could have improved the Mitchell or Lightning in detail by replacing pieces via SCASM, I chose not to. There is a certain elegance to having a project entirely done in AF99. Keep in mind that I originally started building for CFS just to prove that a nice looking and mostly bleed free model could be built with AF99.

    - Ivan.

  8. #8
    Hello Ivan,

    I hope your Sunday is going nicely, and you are surviving the cold well.
    My wife is also better than me at a number of things!

    I agree that it is always nice to be able to do a model completely in AF99,
    and only use SCASM for the VCockpit. I agree with you that there is a
    certain elegance about it!

    Occasionally, however, one is confronted with a model that just doesnīt seem
    to be awarded with enough components and structures, or even parts, by AF99,
    to finish it off properly.

    Thus, the cumbersome task of adding things comes in handy, although I donīt
    like it very much. Every time it needs a Call changed to a Call32, and even worse,
    when it canīt update the model file and wants to write a new one, it gives me
    the willies.

    Surprisingly enough though, at the end of the day, the models function correctly
    in the sim! What a splendid reward for all those nerves...

    Cheers,
    Aleatorylamp
    "Why make it simple if you can also make it complicated?"

Members who have read this thread: 0

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •