What's wrong with this mesh?

[Cornflake]

Hi all,

I was testing some mesh tools today, as I like to mess around in 3DS Max with some Orbiter models. And I was interested what Mesh Wizard could do because I'm trying to learn the ropes of making models for Orbiter. At any rate, I opened up some of the AMSO meshes, and most of them (like 90%) end up looking like this:



Or in 3DS Max:


Crazy, eh? Obviously it's imported as a giant cube pile of scrap metal. The even crazier thing is, I tried every program to import and / or open the MSH files. I tried 3D Object Converter, the 3DS Max .MSH importer and exporter script, Mesh Wizard 1.9, importing using the Blender .MSH script, saving from mesh wizard to an anim8r file -- but it all yielded the same results.

Have you guys seen anything like this before, and is there a way to solve the problem? Is there some kind of .MSH opening prevention embedded in this files some how? (I couldn't imagine Orbiter addon developers delving that low). I don't they're corrupted as they work fine in Orbiter. I'm disappointed, since AMSO had the most detailed CM virtual cockpit, i wanted to check it out and see how it was done.

- Thanks, Cornflake

 

[unussapiens]

I would guess it is either a corrupt mesh or a bad importer.

If you can load the mesh in Orbiter and it looks fine, then it's the importer.

 

[Donamy]

The meshes for AMSO are scrambled intetionally, so they can't be used in other addons.

 

[MJR]

He probably did not want anyone to use off of it.

 

[Chode]

So, how do I scramble the meshes in my add-ons so nobody else can use them?

Regards

 

[Donamy]

You need a scrambler to save them scrambled, then they are unscrambled when they are called in the code. I'm not a coder, so that's as far as I can help with it.:sorry:

 

[Cornflake]

The meshes for AMSO are scrambled intetionally, so they can't be used in other addons.

That's what I figured. What's this coming to, now even Orbiter addon creators are stooping to the levels of making their addon content unusable? Not everyone has the intentions of ripping work off. Haha. Who would've guessed; DRM for the .MSH file format.

I didn't even know a method to do that exists; is there documentation on the subject anywhere? I could of sworn I saw PDFs about the .MSH file format. By looking at the .MSH in a text viewer it looks fine, does it switch around the orders of the vertices or something? How does Orbiter know how to correctly draw the model as to not be scrambled in-game?

So, how do I scramble the meshes in my add-ons so nobody else can use them?

Please start a new thread if you'd like to know, don't hijack mine :dry:

*EDIT*, nvm I found the PDF breif about .MSH here: http://www.orbiterwiki.org/wiki/Converting_to_msh

 

[NukeET]

So, how do I scramble the meshes in my add-ons so nobody else can use them?

Regards

:threadjacked:

Chode:

If you ever find out how to scramble meshes, please let me know.

 

[Cornflake]

Hmmm, just took a quick read through of the 3DModel.pdf and it doesn't seem to mention anything direct about scrambling... this is indeed a mystery!

And you can post anything you find out about scrambling, Chode, I don't mean to hamper sharing of information

 

[Chode]

Sorry to hijack the thread, I started a new thread here:

http://orbiter-forum.com/showthread.php?t=894

Regards

 

[Cornflake]

Sorry to hijack the thread, I started a new thread here:

http://orbiter-forum.com/showthread.php?t=894

Regards

No, it's ok... I said I didn't mean to hamper being able to share info with each other. But oh well.

 

[Chode]

No worries, i just thought the discussion properly belongs in the Add-on Developers forum. And if the AMSO encryption method is not made public, I think I can come up with a method of my own, which I intend to share.

Regards

 

[NukeET]

I didn't mean to ruffle any feathers...:sorry:

I just couldn't let that pass without a request for more info.

 

[Cornflake]

No worries, i just thought the discussion properly belongs in the Add-on Developers forum. And if the AMSO encryption method is not made public, I think I can come up with a method of my own, which I intend to share.

Regards

Yeah, it's very peculiar because this kind of thing would be useful (albeit inconvenient if you're like me and you like to take a closer look at people's work) but I've never heard anything about it -- in any Orbiter documentation or the forums.

If Orbiter was to render the model correctly, but it's rendered incorrectly in a 3D program - than I'm guessing somehow it's implemented in either the base MSH code or Orbiter code to recognize the changes otherwise it would be scrambled in Orbiter too. So there's got to be a way to take advantage of the scrambling technique. Maybe the meshc.exe compiler in the Source SDK supports a command line parameter that enables scrambling?

P.S. That brings up another issue, why hasn't any other major addon developers or Martin himself used this method for encrypting the meshes they've made? (Or i should say, when Martin added the models into the game even if he didn't create them himself).

 

[Chode]

I'm thinking in another direction. I don't think you would need for the Orbiter base code to even be aware that the mesh was encrypted. I've done some coding using the Orbiter API, and basically, what you do is tell the Orbiter API the filename of your mesh, and it handles everything from there. To then directly alter it, you would need to figure out how to gain direct access to the mesh data from the Orbiter mesh handle after it is loaded (in order to decrypt the mesh), which seems to be a difficult proposition (but maybe not).

However, there is a method for directly modifying meshes in the Orbiter API, and that is through an animation. So, I can envision creating a decryption method that would be defined as a very bizarre animation that would be applied to the mesh before it was used that would "unfold" it from its "folded" encrypted state. This would be hidden in the source code of the dll.

These ideas are very preliminary, and I am putting them out there now to possibly spur further ideas.

Regards

 

[Cornflake]

So, you're thinking the meshes are only correct after a certain animation is applied to them? That makes sense. It would indeed be helpful to "grab" the mesh from memory after it's been unfolded to see about decrypting. So then I'm guessing whatever 3D application that is used to access the .msh files does not know the animation, and shows it in it's "folded" state.

That seems to be a pretty complex procedure to keep your meshes from being used. I also started thinking in another direction: Maybe some how it's an un-intended side effect compiling the meshes in the way they did? Maybe they needed the mesh to be modified in a certain way to be compatible with other AMSO components, and made the .msh non-backwards compatible.

 

[Chode]

That seems to be a pretty complex procedure to keep your meshes from being used. I also started thinking in another direction: Maybe some how it's an un-intended side effect compiling the meshes in the way they did? Maybe they needed the mesh to be modified in a certain way to be compatible with other AMSO components, and made the .msh non-backwards compatible.

This is completely intentional, as far as I can tell. One possibility is that these meshes are part of a commercial ($) Apollo simulator development effort (otherwise, why spend any time protecting them?). I hope I'm wrong, but it all seems so strange. I had never thought of encrypting meshes in my add-ons, knowing that someone would ask permission for it's use in another add-on before using it.

Regards

 

[unussapiens]

I think the way they would encrypt it is by applying a standard (or non-standard if they want) encryption algorithm. When they want to use the mesh they just decrypt it in the dll for that craft and then tell Orbiter to use the decrypted file, which is deleted (from RAM, and ROM if it is there) after use.

 

[Chode]

So then I'm guessing whatever 3D application that is used to access the .msh files does not know the animation, and shows it in it's "folded" state.

Yes, that's it.

Regards

 

[Chode]

I think the way they would encrypt it is by applying a standard (or non-standard if they want) encryption algorithm. When they want to use the mesh they just decrypt it in the dll for that craft and then tell Orbiter to use the decrypted file, which is deleted (from RAM, and ROM if it is there) after use.

Yes, this is a valid method, decrypt the file into a temporary file, then load it, then delete it.

The funny thing is that the encrypted .msh file looks like a valid .msh file (you can open it with notepad, looks fine, etc.)

Regards

P.S. sorry, Cornflake to keep hijacking your thread, further questions might best be posted on the add-on developer forum.

Regards