Wing Commander Prophecy: Secret Ops Model Update Pack

Thanks Defiance - guess I missed that in the previous posts.
no worries. :)

The most popular suggestion so far is to see if we can build the MUP into the OpenGL patch as an install option. I'll see about adding in a second set of ship .iff's into the installer and the program would determine which one to install based on the game you're trying to update. If not, I'll create two separate installers, one for SO and one for WCP.

It might even be easier than that if the updated guns in bullet.iff were swapped one for one. I'll have to look at that.
 
Merry Xmas early wingnuts! Panther ahoy! (it has some weird scaling issues in the game, not sure why and I'll have to do some debugging, the mesh is exactly 15m in blender but somehow comes out close to 30 in the engine.) Gigantism aside, the fighter works well - the EPOD chunk works as expected (which is nice, I thought it was going to give me some heartburn). I'll post another update later in the week when I can tackle the scaling. It's my youngest daughter's birthday tomorrow so I'll be out getting my fill of My Little Pony. :D

Pant_Ingame3.jpg Pant_Ingame2.jpg Pant_Ingame1.jpg

***Edit***

Curiouser and curiouser. So the model is actually the right size in the game (as evidenced by the shots below) It seems to be something to do with the viewer and the scaling (or positioning) of the model in the viewer render. Which still causes problems in the game because the ship appears out of place in the HUD targeting window, and the ITTS leader appears in the wrong location causing you to miss (I know there are a few of you who want to gun down Maestro, admit it!!!). It might have something to do with the collision spheres as well, since the EPOD has its own collision sphere, I wonder if that is somehow overriding the base model's collision sphere. Anyone else run into this? I'll keep playing around with it though.

On the plus side I flew a few missions with it and haven't run into any performance issues thus far. And, they do look nice :). Also - Extra bonus for me: The briefing models aren't screwed! YAY!

noscrewedBFmodels.jpg

Panthers Escorting the Cerberus:
Pant_Ingame6.jpg Pant_Ingame7.jpg

Panthers shooting bugs:
Pant_Ingame4.jpg Pant_Ingame5.jpg
 
Last edited:
Oh one more quick update. Here's the latest MUP status video. It highlights the Panther, as well as the new Manta and Excalibur models. Check 'em out below to see them in action. If you don't want to sit through 9 minutes of mission, you can skip to 5:48 to see the Excals.

 
Last edited:
Curiouser and curiouser. So the model is actually the right size in the game (as evidenced by the shots below) It seems to be something to do with the viewer and the scaling (or positioning) of the model in the viewer render. Which still causes problems in the game because the ship appears out of place in the HUD targeting window, and the ITTS leader appears in the wrong location causing you to miss (I know there are a few of you who want to gun down Maestro, admit it!!!). It might have something to do with the collision spheres as well, since the EPOD has its own collision sphere, I wonder if that is somehow overriding the base model's collision sphere. Anyone else run into this? I'll keep playing around with it though.
Parts, including EPODs, shouldn't have collision sphere or collision tree in the case of fighters. Unless you want to go all out and do collision trees for all meshes, stick to one collision sphere for the entire ship. The only fighters that should have more than that are corvettes.

lso - Extra bonus for me: The briefing models aren't screwed! YAY!
Well, gee, I could've told you that :). Most WCP ships have their own separate briefing meshes (usually named b_something). These are listed in briefing.iff. They're crucial, because each of those objects is literally just one mesh - so if you tried to use an ordinary Panther mesh, it wouldn't have an engine pod.
 
Parts, including EPODs, shouldn't have collision sphere or collision tree in the case of fighters

Interesting, since I imported the original panther's EPOD into blender and it had a collision sphere. Unless @Kevin Caccamo s blender scripts add one. I tried exporting a new EPOD without a collision sphere and got the same result. That said, the docs for blender commander state you can override the pre-calculated collision sphere by adding your own empty. I take it to mean that the script will automatically generate one if an empty named 'collsphr' isn't present. If so (and assuming that the operating theory that the conflicting collision spheres are causing the problem) then this might be the cause.
 
Yes, Wing Blender automatically calculates the collision sphere if you don't have a "collsphr" empty object in your scene. However, there is a collision sphere form/chunk in the original pant_pod.iff.

The Panther model seems to be off-center for some reason, according to the mini VDU display. @DefianceIndustries, when you exported the Panther, how were the body and pod positioned? Can you try centering the body, and exporting the pod off-center?
 
Yes, Wing Blender automatically calculates the collision sphere if you don't have a "collsphr" empty object in your scene. However, there is a collision sphere form/chunk in the original pant_pod.iff.

The Panther model seems to be off-center for some reason, according to the mini VDU display. @DefianceIndustries, when you exported the Panther, how were the body and pod positioned? Can you try centering the body, and exporting the pod off-center?

I'll try it. the original EPOD is centered and then assigned to the Pivot hardpoint. That may solve the problem of positioning the model and EPOD, but it might cause unintended issues with rotation. But, never know till you try!

As for centering the model, that was my first thought: "Defiance, ya ninny, you forgot to apply rotation and scale again", but that wasn't the issue. I tried re-centering the mesh, and still get the same results.
 
Interesting, since I imported the original panther's EPOD into blender and it had a collision sphere. Unless @Kevin Caccamo s blender scripts add one. I tried exporting a new EPOD without a collision sphere and got the same result. That said, the docs for blender commander state you can override the pre-calculated collision sphere by adding your own empty. I take it to mean that the script will automatically generate one if an empty named 'collsphr' isn't present. If so (and assuming that the operating theory that the conflicting collision spheres are causing the problem) then this might be the cause.
Well, you guys clearly must be right about the collsphr being always present. I guess I just didn't notice. I suppose that means that the collision sphere is not to blame, because the game probably ignores it. Which, I guess, means that you still have no idea what's wrong, and neither do I. Oh, well :p.
 
Fixed it! Ok so here's the issue: I initially created a separate .blend file for the EPOD, the reason I did this was because the EPOD had a separate collision sphere and I wanted to keep them distinct. However, when I exported it to IFF, it created (I assume) separate mass based on the collision sphere. So when I put the meshes together, the engine had two distinct centers of mass and so interpreted a new center of mass somewhere between the two which offset the model.

FunkyEPOD.jpg

The Fix: When building a model with EPODs, ignore their distinct collision spheres and only use a single sphere for the whole of the model. The EPODS need to be centered in blender however, because attaching them to a hardpoint at the center of the model will cause them to rotate around the HP so instead of having a mesh rotate at a pivot point, the whole EPOD slides around the center of the model. When you export the EPODs, they will assume the mass of the collision sphere that overrides the default spheres.

Correct EPOD.jpg

And because we didn't have a good shot earlier of the EPOD rotation:
EPOD Rotation.jpg
 
Anybody ever get the anti-missile systems to work? The Panther and Vampire each have one. Were they included but not implemented or added to the models but were never built into the game code?
 
No, they were not included as far as we know. I can only assume that this was going to be another iteration of the autoaim from WC3-4.
 
Quick update: Things are moving along with the MUP. @Dark Sentinel has sent me a very snazzy Wasp model so after a coat of paint, I'll be putting it up for all to see. I've also finished a Seahawk model which is likewise waiting a coat of paint.

Other big news: @gr1mre4per has given me a beta version of his engine updates for Christmas! Among the many improvements this little baby delivers are massive increases in polys-per-mesh that the engine can allow. Meaning that I no longer have to use the PART chunk to slice up the fighters. We can now make single-mesh high-poly fighter and capship models for the game (EPODS and destroyable objects not withstanding)! This will be a huge help because it ought to improve memory usage (ie. not having to re-render MATs multiple times for the same model). It also drastically increases the number of renderable objects per mission so we can kiss that 256 limit goodbye! There are a bunch of other improvements but I promised not to reveal any specifics so for now, this little teaser will have to do until he's ready to release it on his own thread. However, this is huge!

***Addendum: I have converted all the parted out models into single meshes where appropriate. No issues at all. I'm pretty giddy about this actually. :) The downside is that the new meshes break WCPedit, so you have to tweak hardpoints by either moving empties and re-exporting the .IFFs or manually editing the .IFF file in WCPascal.
 
Last edited:
I've been monkeying around with the update patch to see what I can shoehorn into the engine. Based on what I've been told, the below doesn't really stretch the limit but it's a good test. So I used my Banshee as a test subject, since in its original form it would blow up Vision (it has more polys than most of the WCP capships). I converted it to an .IFF directly with no changes and below are the results.

Banshee_Blender.jpg banshee_test3.jpg banshee_test1.jpg banshee_test2.jpg

As you can see it's pretty faithful. I'll want to throw it into a sim mission at some point to see how they perform. This is sort of a tangent to the actual progress on the MUP; and it plays well to my magpie-like ability to chase the next shiny thing; but it will be useful to know this info as we go forward. As a fringe benefit, if anyone on the UE staff wants the .IFFs when I'm done and the patch is released to do, say, an update of their own...well...:)
 
Back
Top