converting code to Blender

[Kobra299]

I am wondering if it would be possible to convert the code from your addon to blender as it uses python

[Schlechtwetterfront]

Theoretically this is possible, sure. Some parts could probably be directly reused but the pieces interfacing with XSI would have to be replaced completely.

[Kobra299]

Would you mind if I try this I would need to ask you what some of your code is for and that if you do not mind me picking your brains

[Schlechtwetterfront]

Go ahead. I'm not super deep in the topic anymore but I can definitely answer questions (and maybe reactivate that knowledge). Make sure to check out the file format documentation, too.

[maximstewart]

I'll go ahead and add that I have just recently been trying this. I "have it working" with Python 3 in that I'm not getting errors when running the scripts and exporting a msh file. But, I'm not certain what the issues are with the generated msh files as i3DConverter doesn't seem to like it. (I'm using it as a kind of validation check on my work to convert the scripts to use Python 3.) I'm on Linux by the way so know of no other msh viewing tool and I'm too lazy to setup wine.

To test I just import and immediately export the msh file. I did notice it is smaller than the original so am wondering if something is falling off.

I have got the basic Blender plugin plumbing setup too but haven't gone farther until I know I ported the core scripts to Python 3 correctly.

My source code of he porting attempt:
https://code.itdominator.com/itdominator/Blender-ZeroEngine-MSH2-Plugin

[Schlechtwetterfront]

@maximstewart You could try importing it with msh2 again and see if it chokes on something. Although, I think just importing into the msh2 representation and then back to .msh is not something that usually happens. So maybe there's some assumptions in there that rely on additional data from e.g. XSI.

Feel free to ask questions here (or on Gametoast/the Gametoast discord).

[maximstewart]

"You could try importing it with msh2 again and see if it chokes on something."

I'm not sure I understand? If you mean, import, export, and re-import then I've don't that already and the scripts don't complain (Python 3 or 2 versions). So, now that I think about it, maybe mine are working as expected and I3DConvert is just unable to read the mesh file if not in some fixed state. I.E, it's expecting all parts to be present.

Also, with the Python 3 version, I renamed the "msh2" file to be "msh2_data" and changed the import rule in the "mesh2_unpack" file.

i will add, part of the difficulty I had getting the core scripts converted to Python 3 is because of the way strings were handled from Python 2 to 3. In 2, it's like a "byte object" and in 3 its more of a "string object". For Python 3, I forced everything to be byte strings and use BSON to merge the structure into the file.

Notes for me:

Should check the mesh files between Python 2 vs 3 and see if exactly same output. Both result in are smaller mesh files after import, export but I never compared byte for byte....

Edit:
"So maybe there's some assumptions in there that rely on additional data from e.g. XSI.'

I tried confirming that and so far nothing looks out of the ordinary to me or seems to suggest that. I'm not absolutely sure, though. The button events seem pretty straightforward in how it handles import/export.

Edit 2:
"Feel free to ask questions here (or on Gametoast/the Gametoast discord)."

Did not know there was a Gametoast discord! That's cool!. My Gametoast account is locked and I can't get the password reset. Still trying to get that resolved.

[Schlechtwetterfront]

... maybe mine are working as expected and I3DConvert is just unable to read the mesh file ...

The best way to actually validate a .msh is to munge it and look at it in-game. As far as I'm aware every other 3D viewer has its share of issues and is not "representative".

... part of the difficulty I had getting the core scripts converted to Python 3 is because of the way strings were handled from Python 2 to 3 ...

Yeah, I guess ZETools currently just works with default strings to build the .msh contents, which wouldn't work directly in Python 3. I don't think it should be a problem to just assume everything is ASCII/force everything into bytes. Not sure what BSON has to do with that though?

About the data assumption: What I could imagine is that importing something into XSI makes XSI generate some additional data (like normals or something) that would then be used on the export. I can't really think of anything like that though (would also depend on the concrete .msh imported).

I guess comparing the results of a Python 2 and a Python 3 import & export would be a good starting point.

[maximstewart]

When I was trying to export to JSON, I was getting the error: "Object of type bytes is not JSON serializable"
I needed BSON which can handle it. This is separate from the save method which just writes the packed data to a file. But, I found out about Python 2's weird string history from that side street I took. It convinced be to make every string a b'' string because of that.

"About the data assumption: What I could imagine is that importing something into XSI makes XSI generate some additional data (like normals or something) that would then be used on the export. I can't really think of anything like that though (would also depend on the concrete .msh imported)."

Sometimes it takes a little prompting before I figure stuff out. I would have sworn I didn't see extra stuff being done, but I actually think there are additional steps being ran during export. (When I was looking I musta ate a bowl of stupid it seems.)

I did the following
grep -R "export(" ./*
Which got me to
zetexport.py: def export(self):
Which got me to
zetexport.py: def do_export(self):

I'm seeing steps that explain some issues I saw during just import to export path. I thought it was just a weird bug but see commands that look like it would generate what was missing. I don't like the idea of "Rubber duck debugging" but am starting to think there is something to it.... I'll take a deeper look and play with it.

[maximstewart]

I'm still looking at the import/export scripts in the ZETools. The import section basically takes the file and does the unpack process. It thereafter passes the mesh object to internal processes that fill out XSI. The export process looks like it directly consumes from SI and does the whole collection, conversion, and packing there. =/

Long story short, I'm still looking into this. I just got my GPU Passthrough setup again so I can use zeroeditor and munge a test level. Zeroeditor seems to not like the edited files and crashes during "import" of the objects to the map editor/maker. All I'm doing is backing up the file I edited and replacing it with the edited version.

What I kind of want to do at this point is take the unpacked data and see if I can make use of it in Blender. Maybe get it to export to VRML 2.0 (.wrl). I'm hoping I can find how Blender 2.49 handles that and basically convert it too to use modern Blender versions. Maybe thereafter get a version that can export to msh2 format after thoroughly analyzing what the XSI exporter is doing.

[Schlechtwetterfront]

Have you tried importing and exporting a .msh with the Python 2 version to compare (like you mentioned before)? You could both compare the two result files against each other but also see if maybe the Python 2 re-exported .msh doesn't load either.

[maximstewart]

@Schlechtwetterfront
I have and the Python 2 re-exported .msh doesn't load either. Zeroeditor fails (actually crashes) when reading either exported mesh file. I will add a detail that I didn't think to add that might help you think of something.

During export and if left unmodified the Face class's pack fails complaining of the following:

This is the code that fails and you can see the commented out fix I use to get past it:

By the way, the way that the code works right after it suggests that it is okay if index_map is None. But, as you can see, the collection object is None instead. I will add that using the fix I mentioned/created fixes all errors shown. So, I'm not sure if collection is actually needed somewhere during the pack phase and it's just not throwing an error:

Note that this error shows up with Python 2 and 3. I will add, I haven't taken time to discern what fills the collection other than direct pass into the class. Frankly, I didn't give it much thought until I tried, again, import and immediate export with Python 2. As stated, Zeroeditor fails (actually crashes) when reading either exported mesh file.

[maximstewart]

While I can't seem to get a working export, the import side is looking good.... =D I decided to mostly follow what zero edit is doing for XSI and gutting the parts not needed/workable for Blender. Basically, I'm taking the skeleton and cleaning it up.

Here's the Republic Barcspeeder mesh in Blender. I don't have materials working and this import is using temporary logic to just test that my Python 2 to 3 conversion is good.

Here's the Republic combat speeder with smooth shading applied:

[Schlechtwetterfront]

Looks great!

Regarding the last comment, I looked at the code and I think the index map is not required (logically). It is a bit weird though that the segment is not wired up properly.

One thing to note about materials is that apart from the standard properties like texture and colors they also have zero engine specific properties (like render type). In XSI these get stored in a custom collection of parameters on the material. I'd guess blender had similar mechanism

On that matter, most geometry/animation is mostly standard stuff, except XSI's concept of primitives (sphere, cylinder, cube/rectangle) can be found in how .msh files store many collisions. I'm not sure if blender has a similar concept but being able to represent those would be pretty important to be able to re export correctly.

[maximstewart]

Please don't get too excited just yet! My repository is a sh*t show right now because I really wanted to see meshes in Blender for a motivation bump. I took the most direct route and it shows. Anyway, I've decided to try and convert the XSI logic for Blender than try writing my own around the core mesh code. I'm not smart or patient enough to get that familiar with the msh2 format. So, I'm rethinking the structure of the project anyway.

To your other points:
Correct, index map is not needed and can be None. And agreed, I'm concerned that the segment isn't wiring up because of something not converted from py2 to 3 and that that error is the only hint. The only caveat is is that that should mean py2 import and immediate export should work and yet it too gets the same error. It too, if bypassed, creates meshes that crash zeroeditor. Maybe all around it is requiring something from the XSI export flow; or, it's a bug. That's an additional reason why I started playing with getting the mesh data into Blender.

I'm not sure if blender has a similar mechanism for tracking the parameter but I'm betting I can wrangle something up. I'm pretty new to trying to write something for Blender. Also, I'm guessing you mean these?

"XSI's concept of primitives (sphere, cylinder, cube/rectangle) can be found in how .msh files store many collisions."
Ahhh, good to know. I was getting a lot of collision shapes that I had to hide in the preview images I attached. I'll keep this in mind.

[maximstewart]

No major updates. I've been a bit busy to work on this.

[maximstewart]

I wish I could say I've made progress; but, I haven't. I've been busy with work and a bit too tired to touch this. I'm also just not smart and am having difficulty thinking of a proper way to wire this into Blender that wouldn't look like a sh*t show. I'm convinced wrapping around the original calls would be better but piping that out hasn't been easy for me. Plus, I kinda wish I could debug the script both the py2 and py3 using Softimage. But, I don't have an installer of it.

[VanFanelMX]

I wish I could say I've made progress; but, I haven't. I've been busy with work and a bit too tired to touch this. I'm also just not smart and am having difficulty thinking of a proper way to wire this into Blender that wouldn't look like a sh*t show. I'm convinced wrapping around the original calls would be better but piping that out hasn't been easy for me. Plus, I kinda wish I could debug the script both the py2 and py3 using XSI. But, I don't have an installer of it.

An XSI installer? I have mod tool from years ago.

[maximstewart]

@VanFanelMX I'm sorry, I meant to say the Softimage software. The application this plugin was written initially for. (I updated my comment to correct that.)

[Schlechtwetterfront]

Softimage XSI ModTool 7.5 is free (I think I downloaded it from here last time), but I don't think you can use Python 3 with it (although I've never tried). The later Softimages don't ship with it but do at least partially support Python 3. So if you could get a Softimage 2015 (trial?) you might be able to test both versions. Not sure where/if you could get that nowadays though...

[maximstewart]

@Schlechtwetterfront Thanks for the link!! I'll have to play around with it. I might be taking some time off from work in September and can play around with it in depth then. Hopefully sooner but no promises. =)

[maximstewart]

I'm starting to wish I could pay someone to convert this. Maybe they could run with what I got already setup and take it the rest of the way. 🙄🙄🙄 Anyone wanna make an extra buck?

[maximstewart]

It's been a while since I tried continuing my effort and after talking to some folks, there has been a great port/re-implementation of the XSIZETools to Blender. While I'm pretty proud of what progress I had made, I see no real reason to continue it. The tool that works really well is here:

https://github.com/PrismaticFlower/SWBF-msh-Blender-IO

Edit:
@Schlechtwetterfront Would you consider adding the above link to your README for those who can't use your tools due to the system not being Windows based?