Daedalus' Forums

Troika compresses the low polygon models to reduce the disk and memory footprint.

These models use a table of shared normals. The models are flat because Gardeb's decompiler does not implement the decompression algorithm correctly.

There are so many different model formats. Reverse engineering all of these model formats is a nightmare.

I see what you mean. They changed many thing in the engine, like TTZ instead of VTF, to compress the file to have a smaller space. I think this was their strategy, make the game use less free space and memory footprint. But then how can we decompile the models right?
Compiling with powershell is really what I needed. Thanks. I also use the >> log.txt to print out the screen messages to log, but I don't know if it's quite fast when printing screen to file. It's very useful to print out to a file, so that later we can see what file gave errors.

There are many props that can't be decompiled by any method. I tried gardeb's decompiler (it's decompiled as flat, cannonfodder's decompiler, Packfile explorer, but still couldn't decompiled them. If there would be a decompiler separately only props (primary function of the decompiler). That is crucial to have for the mapping.

Here you go:
The scenery folder: scenery.rar - 65.69MB
The items folder: items.rar - 2.30MB
The gibs folder: gibs.rar - 0.29MB

Jeez codename, thanks for going through the trouble of uploading!

Thanks for the upload CodenameV. Now I can focus more on the mapping.

I'll stick those up on the "proper" ftp soon Thank you!

CodanameV, mal32, you may want to look at this... viewtopic.php?p=1963#p1963

CodenameV, it seems that the models I've converted from your archive have this "disappearing" issue, mentioned some time ago.
I tried to compile mal32's models, and they are fine. Doesn't has that issue.
Could you upload the model sources again? Want to make sure that it's not from your model sources.

Please provide me with the name of one of these "disappearing" models and the source for the same model from mal32. The problem may be due to the algorithm used for the mesh normals. Some of Troika's low polygon models use a table of "shared normals". Additionally, Troika used a compression algorithm that compressed the floating point representation of the mesh. Perhaps, my decompiler is not decompressing the normals correctly and/or not picking up the correct normals from the table.

The easiest way to prove that it is a problem with the normals is to redo the normals in a modeling program and then to export the model, recompile it and view it in the map to verify that the model no longer "disappears".

Sorry for the late response.
One of the "disappearing" model is scenery/structural/diner/wndwb.mdl.
I tried both yours and mal32's. With mal32's model, it doesn't disappears anymore.
But today I recompiled the models from mal32's models source, the models caused an odd glitch. When looking at the models at different angles, they created some black rectangles on the screen (sm_diner_1 in this example).
If you said you didn't had this issue before, could you please upload your model sources again? I would like to see if they get compiled properly. Thanks.

I do not believe it is a problem with the models. The models render without artifacts in hlmv.

It may be due to the differences and/or bugs found with the versions of the material subsystems used by Troika and Valve. Troika modified and wrote their own pixel and vertex shaders to coincide with their nightime lightmapping system.

I noticed that Troika used $nocull with $translucent with these models. Valve states that this is a bug.

See the following:
http://developer.valvesoftware.com/wiki/$nocull
http://developer.valvesoftware.com/wiki/$alphatest#.24alphatest

If you have the time, you may want to edit the material files to see if following Valve's suggestion cures the problem.

I tried setting the materials to not use any transparency, but the result is the same, minus the transparency.
Those are only affected on the LightmappedGeneric shader (brushes, lightmapped surfaces) in the new engine, so that should be the source of this. Else, I would have the same issues with mal32's models.
I forgot to mention, the models render fine for me in HLMV and Hammer too. But not in-game.

Here are some screenshots of this issue:

This screenshot was taken place from a single position, but only the viewing direction was changed.

Here is the model viewing it from a regular position:
http://cid-75af2dc0e9756efb.skydrive.live.com/self.aspx/Misc/sm%5E_diner%5E_10000.jpg

Here is the model viewing from the same position, only moved the viewpoint a bit to right.
http://cid-75af2dc0e9756efb.skydrive.live.com/self.aspx/Misc/sm%5E_diner%5E_10001.jpg

Here is the model from the above viewpoint, again moved the viewpoint a bit to right.
http://cid-75af2dc0e9756efb.skydrive.live.com/self.aspx/Misc/sm%5E_diner%5E_10002.jpg

Because the models are layered and the materials are translucent, the painters rendering algorithm must be used.
The models and materials should be rendered from back to front.

The $nocull flag is used so none of the geometry is culled. The materials are translucent to allow the material to be applied to the rear of the geometry of the model when layered.

For a window with curtains, the curtains should be rendered last. The window frame should be slightly obscurred by the curtains because the curtains are translucent.

There has to be a bug in the engine as the translucent materials are not layered correctly in Valve's engine but layered correctly in Troika's.

Troika wrote their own shaders. There is no way to use Troika's shaders with Valves engine without reverse engineering them.

I solved the problem with the disappearing models. My decompiled meshes for the curtains.mdl and wndwa.mdl were 90 degrees out of phase with the hitbox coordinates specified in the decompiled .qc files. As a result, the engine culled the model out of the camera's view when the camera approached the windows.

I added the following line to the .qc files and recompiled the models and the map and the problem went away:
$origin 0 0 0 -90

Special thanks to atrblizzard for inspiring me to solve this annoying problem.