oh and one new feature request: Collision Trees for capships and components. :) I think that would require some kind of toggle in the script; is this mesh a capship Y/N? If Yes then it could look for a collision mesh (or use the base mesh) to build out the tree. I ask because I'm dealing with that right now...:)
 
I have no idea how the BSP trees for WCP/SO capships and corvettes work, or how they are built.

Sorry. :(

However, BSP tree construction is on the roadmap for future Wing Blender versions. And if there's anyone willing/able to help me with that, then great!
 
In case anyone missed it, here's an overview of what I'm working on for Wing Blender 1.7.

The new naming covention for the main model, if the user decides not to use the active object as LOD 0, will be:

Code:
detail-<lodn>
where <lodn> is the LOD number.

The new naming convention for child models, and the main model if the user decides to use the active object as LOD 0, will be:

Code:
<name>-lod<lodn>
where <name> is a name that consists of only letters, numbers, and/or underscores, and <lodn> is the LOD number.

In response to this issue, I've decided that the next version of Wing Blender will no longer support global hardpoints and collsphrs. This just means that hardpoint objects and collsphr (Collision sphere override) objects will have to be parented to a LOD object instead of being in the "global" scene. Hardpoint and collsphr objects parented to LOD 0 will override hardpoint/collsphr objects parented to other LOD objects of a mesh. I will also allow users to override the CNTR and RADI chunks of each LOD mesh individually.
 
Last edited by a moderator:
Another thing which I just recently thought of was allowing users to customize the RANG chunk because I think it specifies the distances for which each LOD is "activated".

You would parent an empty object named as follows to any LOD object greater than 0:
Code:
drang=<dist>

Where dist is a whole or decimal number, with a comma instead of a decimal point (feel free to suggest another character) if the number is a decimal number. The reason for this is because Blender likes to rename duplicate objects by sticking '.0000' or '.0001' at the end.

Also, if you try to parent this kind of object to LOD 0, Wing Blender will ignore it.
 
Last edited:
I'm happy to report that I'm making good progress on the next version of Wing Blender (which is now 2.0.0 instead of 1.7, due to significant changes in the code), and it is getting closer to being ready for testing.

I need some help, though. I don't know what I should do for exported mesh filenames. When the user goes to export their finished product, they can choose one filename to export a model or scene to in Blender, but the next version of Wing Blender could potentially export multiple mesh files. For example, the body, turret(s), and gun barrel(s) of a fighter with turrets, like the Thunderbolt, would all be exported as separate mesh files.
 
Last edited by a moderator:
How about allowing the user to name the base mesh and then it would append that name in front of other components. so if I had a ship named 'Foo' and another object named 'engine' then it would export the objects as Foo and Fooengine? of course lazy modelers would get a bunch of things like Foocube.001 or Foocircle; but that would be a not so subtle reminder to name yer darn objects.
 
Good idea. I'll use an underscore to separate the base model name from the child model name.

But the thing is, there could be multiple base meshes if you decide to uncheck the "Export only active object" option in the export view. If you do so, it will export every valid object in the scene root, as well as any valid objects parented to those objects and/or their hardpoints.
 
Last edited:
I have no idea how the BSP trees for WCP/SO capships and corvettes work, or how they are built.

You might touch base with @gr1mre4per, he was working on a BSP tree fix for the MUP, since the original Vesuvius BSP tree didn't have a "gap" for the hangar.

As for the multiple base meshes. Hmmmm, that's a good point. I assumed that the modeler would simply parent their objects to the base mesh, so you could read the parent tree and do it that way, but if not - hmmm. maybe you force the export only active object option to true?
 
hmmm. maybe you force the export only active object option to true?
It's possible, but I guess I'd like to keep my options open. The "export only active object" option is true by default.

I guess I could ignore the filename the user enters if they choose to export every valid thing in the scene root, and instead just get the output directory and name the exported mesh files like their base names. (As an example, duhiky-lod0, duhiky-lod1, etc. would be exported as duhiky.iff regardless of whether the user typed in "foobar" in the export view.)
 
Heya. I recently moved the Wing Blender documentation/website stuff out of the feature/website branch of my Wing Blender repo, and into its own repo. Check it out here. If you have any questions, comments, suggestions, etc. please open an issue on my GitHub repo, or reply to this thread.
 
I did a heck of a lot of work on Wing Blender 2.0 today, and I've finally got some results! Here I am, flying the F-265 "Suzanne":
SOSuzanne1.png


However, I still need to do some more work, specifically on the orientation of the models and d-plane calculation. Also, the flat colours came out darker than I expected them to.
 
Wing Blender 2.0 open beta 2 has been released. The importer should now work as specified in the documentation, and the exporter should now export hardpoints properly.

As a bonus, I made another attempt at converting the Vampire from Scooby Doo's (very) old FS2 model pack, and here's a few screenshots I took while trying to get the hardpoints working properly:
vampire1.png

I thought I had it working correctly by now, until I added the hardpoint for the middle section. I then realized the EPODs were upside down.
vampire2.png

That's much better!
vampire3.png
 
Back
Top