SS2 list of broken and lowpoly objects that need fixing

[663f454976577Olfred]

Added shotgun to first post list. For reference on how weapon vhots should be placed, see ar15_h, the assault rifle model.

Strangely enough, the original shotgun already had two vhots somewhere at the handle.
So I added a new one at the muzzle, which should be the third one.

[663f454976710OneofTheMany]

Nice work Olfred! I will however wait for a new "fixed obj" version.
Do this however work with Cage's PistolShotgun skins?

[663f454976873voodoo47]

if the mod just replaces the textures, then it should be compatible. do note that without a proper gamesys setup, the extra vhot will do nothing.

[663f454976940OneofTheMany]

I see

[663f454976a6bZylonBane]

We'll also need a shotgun-specific muzzle flash sprite. The one for the assault rifle would look ridiculous.

[663f454976c0bZylonBane]

Olfred, when you get a chance, could you please re-export the upside-down egg pod models with the latest and greatest fixed version of nemyax's converter (assuming he's released it)? The current models don't light correctly in-game.

I suppose it would be best if all the models you've done so far were re-exported with correct lighting information, but I don't know how much work that is for you.

[663f454976d9aOlfred]

It's not that much work to do it.
I was just putting that on hold till a newer version of the exporter will be released.
As of now there are still problems when objects are parented. Which you kind of need when you want animated objects.

I'll take a look for the egg pod later today.

[663f454976eacOlfred]

These are exported with the newest version.
Please tell me if there are still problems.

[663f454976fcdZylonBane]

Got it, thanks. Looks better than before, but still lit noticeably different compared to the original egg model flipped upside down. I guess we'd better wait for the next revision of the tool before you start re-exporting things.

[663f4549770cfOlfred]

Well, I could make some of the models with bsp.exe, if you guys are close to a SCP release and there are still issues.

Just don't get me started with squeezing any jointed models through bsp.exe.
Even if everything is set up correctly it's still bitching around.

[663f454977214Nameless Voice]

You can usually get jointed models to go through by naming the axle 0001 instead of the 0025 that is the usual suggested name in the tutorials.

[663f4549775b4Kolya]

Nemyax, this was generated by your tool, wasn't it? Any idea why the BIN would crash BINTOE?

Shadowspawn created a beta version of BinToE in 2010. Her released it in this thread on TTLG. No source unfortunately. Still it might be worth a try compared to the 2003 version.

[663f4549778c2Olfred]

You can usually get jointed models to go through by naming the axle 0001 instead of the 0025 that is the usual suggested name in the tutorials.

I didn't have problems with that. I just get an error message which tells me that xxx cuts yyy.
I know that you are supposed to not let things get cut and such. But they aren't cutting. Even when I use the original model and don't change anything (except some tweaks to make it work again) I get the error message that it is cutting.

My wild guess is that the model (the hackable crate where I have troubles with currently) was created with opened "doors" and with some tweak you can manipulate something like a base position for the model which isn't necessarily the way you shoved it into BSP.exe.
I came to this conclusion because the outer box of the model is way bigger than the model itself, and it would match up with opened doors.
But I don't know of any tweaky thing to do this. If it is accessible to us I would be glad to know more about it.

[663f454977a15Nameless Voice]

Jointed models fail because of the "atomic cuts" warnings ending in "we found no solution".
It's because the jointed parts aren't supposed to travel through the other parts of the object for some reason.
BSP will calculate the path of the jointed submodel as far as specified in the axle.  So, if you specify 0025, then it will calculate to make sure it can open to a 90 degree angle without clipping through any other part of the model.
If you set it to 0001, then it will only try ~4 degrees, which has a much lower chance of clipping something.

[663f454977b44Olfred]

Well, even though I get some errors that it is cutting. I still get a bin. Which at first glance looks like a proper model.
But, there are the buts. Now there are some different lighting errors you can see at the lower part of the crate.
(haven't cared about the illumination yet)

[663f4549780eanemyax]

Shadowspawn created a beta version of BinToE in 2010. Her released it in this thread on TTLG. No source unfortunately. Still it might be worth a try compared to the 2003 version.

Probably not. When I wrote to him about this, he said it was due to an unnecessary 256 polygon limit he'd hardcoded. He lifted the limit (which apparently means it was still there in 2014), and everything worked fine. I was under the impression he would publish the corrected version shortly, but he probably hasn't got round to it.

the latest and greatest fixed version of nemyax's converter (assuming he's released it)

I was referring to Shadowspawn's updated tool in that post. I'm still looking into the lighting issues, but I'm not getting any closer to a fix =(

[663f4549783ebOlfred]

I'm still looking into the lighting issues, but I'm not getting any closer to a fix =(

If there is some way I could help out I would be more than willing to do so.
Unfortunately I don't have any expirience when it comes to reading bit sequences.
It's not like I won't be able to. I just don't know how to get into it.
And I'm still lacking some skills in python and the blender API to understand your code.

[663f454978530nemyax]

Olfred
The problem is not so much in reading and writing the data, because at this point the script's output is more or less compliant with the structures in the model file header. The devil is in the way the engine interprets the data. Why it would illuminate backwards-facing polygons beats me—all the data is written as intended, and in identical combined meshes the lighting even works the way you expect it to.

[663f454978619ZylonBane]

So even with a test model consisting of a single tri, there are still lighting differences?

[663f45497873fOlfred]

Ah, ok.
My idea was that maybe something which tells the engine to do proper lighting on the model isn't passed on to submodels. Or maybe there needs to be some kind of extra flag/information passed on the moment you have submodels.

So my idea would have been to create some really simple model like one face with a submodel which is also only one face, and put one through your exporter and one through BSP.exe.
But you probably already did that.

[663f454978a5anemyax]

some really simple model like one face with a submodel which is also only one face

Here's a .blend and a .bin. The child tri has non-identity transforms, but it's lit as if it weren't rotated. Rotate the upright tri to face towards and away from the light to see what I mean. However, doctoring the vertex and face normals to give them world orientation doesn't do any good.
Do you guys think this should be a separate topic?

[simple.zip expired]

[663f454978b70ZylonBane]

At the risk of suggesting the obvious, it seems like doing a byte-by-byte comparison of your tool's output vs BSP's output would be a viable troubleshooting approach for such a tiny file.

[663f454978d0bnemyax]

Could someone please cook up a conventional .bin from the blender file? =)
I can't even hope to begin to understand the @x00aabbbcccfuckthis2739 business.

[663f454978df2Olfred]

I'm already on it to create 2 models with joints out of yours.