SS2 list of broken and lowpoly objects that need fixing

[67394123be02cZylonBane]

So the polys for the energy beams are double-sided, but both sides are facing the same direction?

When I was fixing those things I just added the DBL flag to the texture in the E file and let BSP take care of it.

[67394123be7faOlfred]

So the polys for the energy beams are double-sided, but both sides are facing the same direction?

That's what happened on importing.

When I was fixing those things I just added the DBL flag to the texture in the E file and let BSP take care of it.

I know about that flag, but I do it manually.
Besides, I don't use BSP anymore anyway.

[67394123bea76voodoo47]

https://www.systemshock.org/index.php?topic=3099.0

flora resources are attached, not sure whether the latest version, but worth a shot.

[67394123bebd3Olfred]

They are also just bin files. It's more like the models he based it on, or something like that. Not really resources in sense of files from the editor.

[67394123bed08voodoo47]

guess we'll have to wait 'till vurt drops by then.

[67394123beeeenemyax]

About the z-fighting championship. It must be my fault. When the importer encounters a face that uses the same vertex coordinates as a previously processed face, it adds duplicate vertices and safely builds the new face from those. It should be better at tracking which way the face needs to be turned, and reverse the vertex order appropriately.
Note: If you go ahead and tell Blender to make the same face a second time, you will get an error. There are ways to trick Blender into creating that kind of geometry, but it won't let you do it directly.

[67394123beff5Olfred]

Can you even read the vertex order out of the model?
Hmm... probably... the game needs to know it.
It's not really that much of a problem, but getting it exported in the right manner would be a nice addition.

[67394123bf328nemyax]

Can you even read the vertex order out of the model?

What's more, it's very important. By convention, the order of the verts in a face indicates the direction of the normal. In OpenGL, counterclockwise means "outside". Apparently, in D3D it's the other way around.

[67394123bf44fOlfred]

Yeah I know what the vert order is for. I started modelling on a programm where you had to pay attention in which order you selected the verts for creating a face

The OpenGL people seem to like it to do things differently compared to D3D. It's the same for matrices.

[67394123bfa08Olfred]

Hey everyone, I got some big news.

nemyax did some really awesome updates on the model importer/exporter for Blender. Some which open up new possibilites we likely never had before!

First of all, models now get imported with correctly facing polygons. This will save me alot of time on working with double sided faces as they always tend to get messed up.
This means I can now import complex double sided models without hours of rearranging everything. The best current example would be vurts flora overhaul. (Although he already answered me that he will be looking for his old blend files, so I'll wait for that).

Second big updated is the importing of the bounding box information stored inside the bin file.
Now there shouldn't be any problems anymore with new models replacing old ones which had some awkward non-fitting bounding box on them. I can see and keep the old bounding box now. This makes everything a whole lot easier.

But now comes the part where the real fun begins. It's possible to write custom bounding box information into the bin file. What does this mean?
The bracets ingame are created with reading the bounding box information out of the model. The actual size of the model doesn't matter for this.
Here is a small illustration of how a model could be build now.

Here you can see the SuperCrate (highsec.bin). The dimension box is the old boundingbox of the original model. This will be the actual size of the model as it is handeled by the engine and ShockEd.
The new bounding box you see on there will be custom written into the bin file and won't affect the positioning of the model ingame.

Now if you look into ShockEd you will get some strange display on there.

My guess is that ShockEd reads the bbox information out of the model and just puts it into the middle of the model (the dimension box).
But still, the coordinates you get in ShockEd are based on the dimension box, so it won't bug out on the positioning or anything.

Even though the bbox gets displayed incorrectly(?) in ShockEd, ingame it will nicely put the bracets at the right place. With this we won't need to be bothered with oversized bracets anymore.
This picture compares the original model with the new one.

But this is not all!
We have far more possibilites now as I have discovered something else.
The dimension box only consist of vertices (or an edge to be exactly). But the game does not take single vertices into account when it comes to collision detection.
What good can we get out of this now? Simply said, we can make models bigger than they originally were, but with keeping the original position (no retouching, yay!) and still get a properly displayed bounding box.

As an example I took plant1.bin (-69).
Now as the game stores the positioning of the model based on the middle of it. When I want to make a model taller, I simply have to scale the dimension box according on how much I increased the model. Now I can wrap around a custom bounding box around the actual model and it gets nice bracets ingame.

On this screenshot you can see what I did there.

The orange box is the size of the bounding box, and the black box (which is partly overlaying with the orange one) is the dimension box.

Here you can see what it looks like in ShockEd and ingame (and yes, the model is really properly standing on the ground, even if you pick it up and throw it around).

This could get useful when working on vurts flora overhaul to iron out the current problems.

As another example I thought something up, but couldn't test it properly as I am a complete noob when it comes to editing with ShockEd.
I wanted to test out what happens when you create a completely new object with a custom bounding box. But unfortunately I couldn't find out what I need to do to get it working properly ingame (it was always floating off the ground, even when I tried it with a proper model).

So this next step is just speculation and ideas and I would be grateful if someone with more ShockEd knowledge could test it out.
What I wanted to achieve was to get a custom center point for arrangement and a nice little effect on the noodle bowl.
Basic idea was to make the bowl the center and make the chopsticks kind of "stick out" of the actual (important) part.

Something like this (left normal bounding box, right the custom one).

For testing I created two models.

One with just the bounding box (left) and one with an additional dimension box (right).

Now the one with the dimension box should work without any problems. But I wonder what ShockEd and the game will base the dimensions on. The actual model or does it just fetch the bounding box and assumes everything is alright with that?

I have put all the models into "bbox testing.zip" so you can download them and test for yourself.

That's it so far with the awesome additions of the latest version from nemyax blender script.
Oh, and before I forget it. It also had some changes in it with exporting models, so old models where I simply put a vertice in there, to make the model bigger for placement issues, don't work anymore if you would export them again.

I'm looking forward to what you guys think about all this.

[67394123bfc32voodoo47]

sounds (and looks) great, but I have to say that I will have to re-read everything a couple of times to cram all the info into my model-unfriendly brain.

anyway, before I forget again, soda can, vodka and champagne could use a fix - as all of those models should be round, their low poly count really stands out (unlike juice and liquor, which look ok as the bottles are supposed to be square). also, there is a weird thing going on with the sticker on vodka, it's sort of wrapped around the bottom of the bottle in a bad way. should look more like the sticker on champagne.

zapcan.bin - Soda Can (-91)
botlevo.bin - Vodka bottle (-964)
botlech.bin - Champagne bottle (-965)

[67394123c0563nemyax]

Excellent writeup, Olfred.

old models where I simply put a vertice in there, to make the model bigger for placement issues, don't work anymore if you would export them again

Strange. It should work in 0.1.20140603. I made specific changes and ran some quick tests. If it doesn't work, that's a bug.

[67394123c08d8Olfred]

Strange. It should work in 0.1.20140603. I made specific changes and ran some quick tests. If it doesn't work, that's a bug.

The problem is that I made these vertices single objects, which consist only of the vertex.

[67394123c0b7bZylonBane]

zapcan.bin - Soda Can (-91)
botlevo.bin - Vodka bottle (-964)
botlech.bin - Champagne bottle (-965)

I already have upgraded versions of some of these that RocketMan made a while back, patiently waiting for the next SHTUP release.

[67394123c0fd8Olfred]

I already have upgraded versions of some of these that RocketMan made a while back, patiently waiting for the next SHTUP release.

Ah, I should really wait some time for you to make a reply. I already started on it. Well, since I had a little problem with them, might as well upload what I did.
While testing the models I made an "inside", but I can't see it on these ones I made.
But when I fixed the original models I could see the inside... There was something about alpha 1 setting, right?

sounds (and looks) great, but I have to say that I will have to re-read everything a couple of times to cram all the info into my model-unfriendly brain.

Feel free to ask any questions you might have.
(You can also ask me through PM, or I'll hop on IRC if you don't want to floop the thread.)

[67394123c1199voodoo47]

yes, alpha 1 (renderer/transparency alpha) needs to be set on the object (or the archetype). the full package of fixed objects does this via dml, so if you have that the objects should look fine when you run the game exe (dmls are not applied in the editor, but can be loaded manually by typing dbmod_load into the command window and loading the dml file).

[67394123c138cOlfred]

To be honest, I never even bothered to download the package. But I just did and saw that there is only one texture inside the txt16 folder. IIRC there were some occasions where the original texture was bugged with some transparency issues, like on the fusion cannon. I usually provided a png in that cases. IMHO they should be added to the pack.

Back to the original topic.
Somehow the models get really buggy when I enable transparency alpha 1. Now you see the insides with a bit of outside. But I think nemyax once mentioned something about translucency not being perfect yet and it has something to do with vertex sorting... or something like that.

Strangeley enough, when I pick one of the old models (from my previous fixing), they work fine without even setting transparency alpha to 1 (though it doesn't break anything if you enable it).
I converted those with bsp.exe.
As there are already new models in SHTUP it's up to you which ones you want to pick. If you want I could further investigate it to get them working properly.

EDIT: Just had a talk with nemyax and found an easy way to fix it.

[67394123c1504voodoo47]

they need to work with alpha 1 as that is required to sort them properly when viewed in front of other transparent objects.

I was not aware that you have provided some fixed textures as well (apart from the boxed protocol droid), will go trough the topic again - must have skipped them somehow.


//champagne bottle is now vodka bottle as well? maybe you've thrown in the same model twice?

[67394123c1ac8Olfred]

they need to work with alpha 1 as that is required to sort them properly when viewed in front of other transparent objects.

Ah, I see.
Like what happened with the railings where you see through the window but don't see the other models.

I was not aware that you have provided some fixed textures as well (apart from the boxed protocol droid), will go trough the topic again - must have skipped them somehow.

I don't think there is a need to go through the whole topic again.
I just checked my txt16 folder for unusual files and zipped them up
except the PROTO03.png I have:
FUSION4.png - Here I remember that the PCX files creates some transparency issue.
MONITOF7.png - I used this file on the new conduit parts ZylonBane requested. I think it had some issues with being transparent at some pixels as well.
rick001b.png - This one is from SHTUP and was only in my folder for testing the models I made for SHTUP.
podscrn.png - same as rick001b.png

//champagne bottle is now vodka bottle as well? maybe you've thrown in the same model twice?

Updated the zip file in my previous post.
Seems I picked some wrong files.

EDIT: Just remembered two of the texture files.

[67394123c1bf8ZylonBane]

This is all getting rather difficult to keep track of.

[67394123c1d45Olfred]

So we need a project managament software now?

[67394123c1f98voodoo47]

a bit, but I can do it, will go through the topic anyway and make sure everything is where it belongs.

the latest bottles look good, but I have noticed that the models are slightly too big for the physdims that are being used ingame, so they sink into the ground slightly when dropped (the orig models probably do this as well, but as they are lowpoly, it's not that apparent). shrinking the model to 85% of the orig size fixes the problem - so shrink them please, this would be way more practical than fixing all the physdims in the entire game. also, one small detail - they represent full bottles, so the top should be sealed/not transparent.


also, another bloody ugly object is Cup with Liquid (-3143 cupt.bin). also, maybe it should be split into two parts, the coffee and the cup, to allow easier manipulation (and, for example, independent transparency).


//crunched through the entire topic, FUSION4.png has never been made available, so no wonder it was not included, MONITOF7.png - conduit_parts are not part of the public release just yet (need a test) so the texture cannot be there yet, and the SHTUP textures should be left for SHTUP (the less potential conflicts the better). so the v06 release is good so far - I'll probably make a new release once the last set of bottles is ready.


//MONITOF7 is supposed to be part of what exactly? slightly confused here.

//highsec.bin almost good, but floats a bit when compared to the orig model. hackcrat.bin still extremely floaty even with the latest version, also the opening animation is broken - will not do anything after being hacked.

[67394123c29fbOlfred]

a bit, but I can do it, will go through the topic anyway and make sure everything is where it belongs.

the latest bottles look good, but I have noticed that the models are slightly too big for the physdims that are being used ingame, so they sink into the ground slightly when dropped (the orig models probably do this as well, but as they are lowpoly, it's not that apparent). shrinking the model to 85% of the orig size fixes the problem - so shrink them please, this would be way more practical than fixing all the physdims in the entire game. also, one small detail - they represent full bottles, so the top should be sealed/not transparent.


also, another bloody ugly object is Cup with Liquid (-3143 cupt.bin). also, maybe it should be split into two parts, the coffee and the cup, to allow easier manipulation (and, for example, independent transparency).

It's the same for the original bottles, it's even pretty apparent on them. The juice is doing the same.
I know about the top but didn't had any good idea to come up with, without doing a new texture or something like that. Or I just could make the top be like the original models, just having it go straight up and let the texture go till the end.

The problem with the texture also appears on the zapcan. Putting the files as png helps.
There is also cans.bin and cans1.bin

The coffe cup is a horrible horrible model. The texture used on the cup is BOTLECH.* which is just straightforward ugly, and making a better model would also make it worse instead of better. IMHO a new texture would be needed here.
Maybe ZylonBane already stumbled over this ugly thing and has a proper model with proper texture already?

But in my opionion something like these models shouldn't go into a "bugfixing patch". I would say updated models in terms of improved visual quality and not just minor tweaks to the original ones should go into a seperate mod, or maybe be included with SHTUP.

//crunched through the entire topic, FUSION4.png has never been made available, so no wonder it was not included, MONITOF7.png - conduit_parts are not part of the public release just yet (need a test) so the texture cannot be there yet, and the SHTUP textures should be left for SHTUP (the less potential conflicts the better). so the v06 release is good so far - I'll probably make a new release once the last set of bottles is ready.


//MONITOF7 is supposed to be part of what exactly? slightly confused here.

//highsec.bin almost good, but floats a bit when compared to the orig model. hackcrat.bin still extremely floaty even with the latest version, also the opening animation is broken - will not do anything after being hacked.

Strange, I thought I mentioned the bug with the fusion cannon texture at least once.

About the conduit parts, ZylonBane requested them and I think they need some tweaking inside ShockEd to get them working properly. I just know that they don't work correctly as of now, but can only try to fix it when I really know what is wrong with them. Or if I need to fix it, or if it's something it needs to be fixed by you guys.
I used MONITOF7 for the conduit parts and then saw that it has this bug.

highsec.bin was still from a time when I didn't know which size the old model was.
I consider the highsecb.bin from my bounding box testmodels to be a proper replacement. If you tested it and everything is working fine I will do the same treatment on hackcrat.bin.

[67394123c2baavoodoo47]

the textures having small holes is not a problem unless it happens with the game exe as well. if it's just in Shocked, it can be safely ignored.

good point about the enhanced bottles, and agreed, they should be either separate or part of SHTUP. that means for the fixed objects pack, only the bottom of the vodka bottle should be fixed. as for the tops of the enhanced models, yes, the original covered top would do.


highsecb.bin looks good to go, so try the same trick with hackcrat.bin.