[Bobboau]

you, know if the sheild it's self is high poly you might have over run the limits on it, I think it's a max of 900 polys or maybe verts...

[Sandwich]

Originally posted by Styxx
And I need more specifics on the Shield problem.

From what I understand, there's a... vulnerability-enhancement feature that nobody seems to like.

[StratComm]

No, no, and no on the shield problem.  I just converted a tetrahedron and looked at the shield chunk output.  The vertices are fine.  The faces get their normals converted correctly, I think, (I'm not computing those by hand today) but the game treats that ok and even if it were wrong you wouldn't get a crash.  Furthermore, because this defines the shield geometry, it shows up fine in editing programs.  However, the last little detail, the three neighboring shield faces, is seriously wrong.  For my sample tetrahedron, I got the following for the four faces (in decimal, for the sake of clarity):

Face 0: Neighboring faces [5280,5520,0]
Face 1: Neighboring faces [0,0,0]
Face 2: Neighboring faces [0,0,0]
Face 3: Neighboring faces [0,0,0]

Now, obviously 1, 2, and 3 should be something other than all zero, but at least here we're looking at a valid index.  Unfortunately, index 5280 from face 0 is not only out of the range of the shield face index, and out of the shield chunk, it is out of the file.  Now I could be misinterpreting this, but I think that's the problem.

EDIT: Omni, your "shields always render on the opposite side" is probably one of two things.  It could be that your shield mesh is getting inverted.  I assume that you are reseting X-form on the shield as well, and that you check it after the fact to make sure it's not inward-facing rather than outward-facing.  Alternatively, you could be seeing this neighboring faces bug in a non-crash situation; in the case above, a shield shot on face 1 would cause the edges (all three edges) of the shield-hit animation to render on face 0.  Since we've got impact effects and the shield is generally hard to see under the laser anyway, this may make it look like the animation is playing in the wrong place.  At least, that's how I think it works.

[Styxx]

See, that's the kind of stuff I need. Will look into it in a few.

[Styxx]

Ok, I think I found the bug with the shield face neighbour generation code. Should be fixed, so I'm posting a new version of the plugin - can anyone confirm if it's ok? This new version also has the new way of generating turrets: it no longer uses the object name. Any object can be a turret, as long as the word "gunturret" or "missileturret" is added to its properties field (right-click -> properties, it should be a large text box). This should help with the destroyed subobjects problem too, at least to an extent.

Test it away and let me know if the changes work.

http://www.3dap.com/hlp/staff/sticks/pofexp/pofexp.rar

The RAR has the plugin for MAX r4, r5 and r6.

[Styxx]

By the way, current MAX files will need to have the word "gunturret" or "missileturret" added to the properties field on the turrets to work. Simply having it on the name won't work anymore.

[StratComm]

Awesome.  I'll probably get around to testing the full shields tomorrow, but I'll put it through my tetrahedron test now

EDIT: Looks ok on the stupidly simple test case.  I'll try exporting a fighter shield and game-testing it tomorrow after work.

[Styxx]

Cool. The more feedback I get, the better the exporter will be.

[Goober5000]

Okeydokey, I've gotten the MathMeister's professional opinion on it.

Originally PMmed by CP5670
Here is a quick rundown of this thing. A tensor in general is an n-dimensional array of scalars, basically a generalization of vectors and matrices. The moment of inertia tensor though is just a matrix for the purposes here. It essentially describes the angular momentum of an object. If the object is made up of n point masses, with the kth one located at (x_k, y_k, z_k) and having mass m_k, then the moment of inertia tensor is defined by this symmetric 3x3 matrix:

åk=1,n mk(yk2 + zk2)	- åk=1,n mkxkyk	- åk=1,n mkxkzk
- åk=1,n mkxkyk	åk=1,n mk(xk2 + zk2)	- åk=1,n mkykzk
- åk=1,n mkxkzk	- åk=1,n mkykzk	åk=1,n mk(xk2 + yk2)

This is really just a volume integral of a cross product of the density and position functions, but with discrete point masses and the whole thing fully written out.

This is about the moment of inertia values in the FS2 pofs, right? I think Volition made these by taking all the points to be either just the vertices of the model (not totally accurate since it will only give the MoI tensor of the model, i.e. the outer shell of the ship, but it may work well enough anyway) or some sort of rectangular 3D lattice of points tabulated at regular intervals inside the model. They most likely just made the ships have uniform density and set all the mass values to 1.

(Sorry, I have no idea how to get rid of that big blank space. )

[Sandwich]

That post had far too much effort put into it.

[Hippo]

That post had far too much maths put into it.

[StratComm]

Shields look ok.  Good catch with your fix, Styxx.  

Other lingering issues: as Omni pointed out, reset X-Form is annoying at best, but since after using it I almost always have to make some tweaks I don't think there's much that can be done about it.  Also, the plugin crashes reliably if I try to export from a file that I just opened and haven't yet done anything to.  It crashes at other times to, but there is no real consistancy to the rest of the times.

[CP5670]

That post had far too much effort put into it.

Well, he asked me what a tensor was and how to obtain the MoI tensor. It only took about five minutes to write a reply and I was waiting for a download to complete so I needed to kill a bit of time anyway.

I guess this exporter is supposed to generate this thing for you?

[I_E_Maverick]

i have another problem: paths

i created a line primitive with 4 points in it and connected it to the subsystem/turret. in max it looked ok, but when i converted it the line was in a plane above the object.

[StratComm]

Reset X-form on the line before you group it to the turret.  You defined the path in the front or side view, so it thinks it's rotated by 90 degrees.

[Bobboau]

now didn't I say basicly the same exact thing?
(I did assume uniform dencity)

[I_E_Maverick]

ok, with reset x-form it works, again. but this is getting very annoying if i have to do everything everytime with reset xform. is there a special reason this has to be?

[StratComm]

Well, yes and no.  Things don't like being rotated or scaled with this particular exporter, and defining things in certain views is essentially defining them from the top and rotating.  It is annoying to say the least, but sadly there's not much way around it.  I'd say before you group anything, select all and reset X-form on everything then use the collapse tool to collapse to modifier stack result.  If you do it to everything, you can't miss anything.

[I_E_Maverick]

thats annoying too, because many parts are then flipped or scaled or rotated, very frustrating!

[StratComm]

Make sure everything is unlinked before you reset anything.  It's a lot easier to re-establish the links than to rotate and scale everything back to where it needs to be.