zbm2obj

[kavehth]

This is a program i made to convert the depth information contained in the zbm files into a mesh. currently it can't read the zbm files directly, so you have to convert them to an image using Grimedi.

to get the image, you have to use the new version of GrimEdi updated by Cervian.

in order to create a mesh you just have to select the image and set the appropriate FOV then click "create OBJ", this creates an obj file next to the image file.

there are also a number settings that can be changed:

• near and far clipping : these are the near and far clipping planes of the camera, i found that the values in the .set files are very large so if you use those the mesh will be huge, so i use something smaller, maybe I'm wrong in my calculations.
• FOV : this needs to be set from the .set file
• Max Z : because i am connecting all the vertices together this means that all separate objects will be connected to each other for example the edges of a chair in the foreground will be connected to the wall behind it. this setting eliminated any face that has two vertices that have a depth that is more than the specified amount.

the resulting mesh is positioned at the center so it needs to be transformed based on the position and orientation of the camera, the camera data for each room can be found in the .set files.

this is what i do in blender to set up the scene:

• create a camera at the center and point it at the mesh
• make the mesh the child of the camera so it moves with the camera
• set the position and FOV of the camera from the .set file
• set a tracking constraint for the camera to track the interest point specified in the .set file

one thing that is not correct is the scale of the mesh so after setting up all the camera angles of the room, the scale of each mesh needs to be adjusted.

also the meshes are pretty big they each have around 300000 vertices, so if the room has a lot of angles the scene will get pretty large.

i spent a lot of time trying to figure out a way to rotate and transform the mesh based on the position of the camera but i couldn't figure out the math, maybe someone else can figure it out

you can download the latest version here
https://www.dropbox.com/s/zqr4gg03mg63b ... 2.zip?dl=0

and you can get the updated GrimEdi here
https://www.dropbox.com/s/gh41fcr1r5l92 ... 2.rar?dl=0

[Cervian]

kavehth, you are a genius!
Thank you so much!

[Nitrus]

I had trouble finding a download link to scummrev3, so here's a link that contains a lot of useful tools. I found it on this thread.

[kavehth]

thanks, i just noticed that scummrev3 wasn't on the site, and i was searching for it.

[Cervian]

i spent a lot of time trying to figure out a way to rotate and transform the mesh based on the position of the camera but i couldn't figure out the math, maybe someone else can figure it out

.set files contains some useful informations to acquire orientations of all scene setups.

In this simple case from DATA001.LAB/mo.set:

Code: Select all

	setup	mo_ddtws
	background	mo_0_ddtws.bm
	zbuffer		mo_0_ddtws.zbm
	position	0.571882	2.461178	0.362781
	interest	1.089404	1.127796	0.217699
	roll		0.000000
	fov		75.178040
	nclip		0.010000
	fclip		3276.800049

	setup	mo_winws
	background	mo_1_winws.bm
	zbuffer		mo_1_winws.zbm
	position	1.471700	0.051800	0.481300
	interest	0.715000	1.728400	0.221800
	roll		0.000000
	fov		75.178040
	nclip		0.010000
	fclip		3276.800049

ORIENTATION

Position gives you XYZ camera location. I will call them *_C after.
Interest gives you XYZ camera target location. I will call them *_T after.
axis_T - axis_C = axis

To evaluate ABSOLUTE rotation that affected camera position, you have to use these simple trigonometric formulas:

X rotation = arcsin[Y/sqrt(Y^2+Z^2)]
Y rotation = arcsin[Z/sqrt(x^2+Z^2)]
Z rotation = arcsin[X/sqrt(Y^2+X^2)]

Depending on your coordinate system, you should add 90 degrees to correct positioning.
As I said, these are transformations APPLIED to the camera, so if you want to restore original orientation of the object, you have to rotate in opposite direction.

NOTE: the fact all cameras in GF has roll setted to 0 does not mean you have not to rotate all axes!

NOTE: due to float numbers strongly affect angles, I advice to use all decimals

[JohnnyWalker2001]

This is great stuff, guys!

[Nitrus]

Had a couple of mildly successful camera projection tests with this (I couldn't bother to make the correct lighting though):

   

[kavehth]

@Cervian thanks for the information I'll try to implement it later

i just updated the links with a new version, i was not reading the image the right way so the results were pretty messy now the models look a lot better and they have a lot more detail, i think we could use many of the models without a lot of modifications.







as you can see there is a lot of detail, but it still isn't perfect, i think the problem is with the way i read the images, i have to find a way to open the zbm files directly.

[Nitrus]

I haven't really looked at the *.zbm structure, but if the *.zbms are just pixeldata (e.g. RGB values for each pixel), then there's only so much we can do with the for example 640x480 images. If however, it is actually differently stored, then possibly we could upscale that data to avoid jagged edges. (I find it unlikely that the *.zbms are stored otherwise though)

There are some source files for scummrev in the archive I linked earlier, so you could possibly look at that, or the way ResidualVM handles it.
*.zbms can also contain multiple images for animated scenes, you can take a look at DATA001.LAB/mo_can_exit.zbm for this.

I'm using maya, and if I want to render just a single segment of a scene, I just create a camera at (0,0,0) with the aim pointed at the object (0,0,1), and I don't have to adjust anything else, the object is properly positioned.
Also, I noticed that I get best results when I don't touch any of the default settings in ZBM2OBJ, e.g. nclip: 0.01, fclip: 10.0, FOV: 75, MAX: 1. If I try to adjust them to match the scene from the *.SET file, I get badly formed OBJs. Is this the intended behaviour?

[kavehth]

I'm using maya, and if I want to render just a single segment of a scene, I just create a camera at (0,0,0) with the aim pointed at the object (0,0,1), and I don't have to adjust anything else, the object is properly positioned.
Also, I noticed that I get best results when I don't touch any of the default settings in ZBM2OBJ, e.g. nclip: 0.01, fclip: 10.0, FOV: 75, MAX: 1. If I try to adjust them to match the scene from the *.SET file, I get badly formed OBJs. Is this the intended behaviour?

so the nclip and fclip currently don't work properly, they just basically scale the mesh but the values are not correct, i usually use the default values. max z is also dependent on the nclip and fclip values so if you increase them you should increase max z as well.

the fov on the other hand is very important you should use the exact number from the .set files, if you don't the model will appear stretched. you can verify that the fov is correct if you look at the mesh from the camera. if you set the same fov and aspect ratio on the camera the frame should be filled completely.

when you import the mesh the orientation isn't correct and it assumes that the camera is positioned and (0,0,0) and pointing at the object. to correct that you should move and rotate the camera and mesh together, in blender you can make the mesh the child of the camera so they transform together, i assume you can do the same in maya. so if you move the camera to the position from the .set file and point it at the interest point they should be set correctly.

here you can see that the walls and floor line up correctly


also the values in the .set files are very small so i multiply them by 10 so i don't have to scale the models too much.

I haven't really looked at the *.zbm structure, but if the *.zbms are just pixeldata (e.g. RGB values for each pixel), then there's only so much we can do with the for example 640x480 images. If however, it is actually differently stored, then possibly we could upscale that data to avoid jagged edges. (I find it unlikely that the *.zbms are stored otherwise though)

i haven't tried to open the *.zbms myself but the way different software read them is different, here you can see the rgb channels of the images i got from scummrev and grimedi.

scummrev


grimedi

[Cervian]

I remembered something about audio commentary of Remastered version, then I searched it in localization files:

Kevin: So yeah, one of the things that I think people don't realize is it's not just pre-rendered art, but there's pre-rendered z-buffers--
Bret: That's right.
Kevin: -- through the whole thing. And we thought that the pre-rendered z-buffers would just do all the work for us, and it turned out that--if you look through the game data--the pre-rendered z-buffers, there's a lot of hand=painted pre-rendered z-buffers. We made a z-buffer editing tool which was funky because you-- It's 16-bit data, and you can't edit 16-bit data in a 8-bit monitor, so...
Bret: It was grayscale. It looks like a ghost scene. It's like you look into like a foggy version of the world.
Kevin: Yeah, so we did like a quantized 8-bit version of it and you could paint into it. People would just use like big boxes and find places where he was clipping, or we didn't want him to clip. A lot of it was we wanted-- He was slightly behind something and he shouldn't have been, so he would like go into the edge of the sofa or something and you just black it out.

I am pretty sure that in 16 bit you can avoid to consider last channel...
From a pure descriptional point of view, it seems that last channel defines error percentage.

Secondly, about near and far clip: here it is very well explained why whe have to take a far clip near to 3500 (and Im totally sure by memory that the common value given in .set files is 3567.something else).

so the nclip and fclip currently don't work properly, they just basically scale the mesh but the values are not correct, i usually use the default values. max z is also dependent on the nclip and fclip values so if you increase them you should increase max z as well.

That's inaccurate: nclip and fclip gives informations about perspective references...changing them from .set configuration means an exponential error in in depth detail.

About some scattering in your output: maybe you saved in jpg format?

[Nitrus]

About some scattering in your output: maybe you saved in jpg format?

If this was directed at me, then no, I only used 16bit uncompressed BMPs, made the most sense to me in terms of raw pixeldata. Although I guess other formats like DDS, TGA or PNG could be used, not sure what ZBM2OBJ supports, never tried anything else.

Also, from a modeller's point of view, the leftmost image from the "scummrev" set of images is what I'm most familiar with when considering depth maps, like this example, although I'm not sure about the programmatical implementation.

[kavehth]

About some scattering in your output: maybe you saved in jpg format?

i saved all my images as pngs. some scenes have those scatterings in the images and some scenes don't i don't know why.

I am pretty sure that in 16 bit you can avoid to consider last channel...
From a pure descriptional point of view, it seems that last channel defines error percentage.

in the first version i only used the red and green channels, but in the new version i use all three and the results have a lot more detail, so does that mean it is 24 bit?

That's inaccurate: nclip and fclip gives informations about perspective references...changing them from .set configuration means an exponential error in in depth detail.

that's why the scales are wrong because the way i use the nclip and fclip is wrong, i couldn't figure out how to calculate the z values properly.

so this could be completely wrong but it was the only way i got any good results, here is how i calculate the z values

for each pixel i get the z value like this

z = (((red/255) + (green/255/32) + (blue/255/32/64))) / 1.228271484375

this gives me a value between 0 and 1, at first i thought that 0 meant that the z was at the nclip and 1 meant it was at the fclip so this is the way i calculated it

z = ((1 - z) * (fclip - nclip) + nclip)

but this gave some weird results and the mesh was warped

finally this is what i did before calculating with the nclip and fclip

z = (1 - z) / z

i don't know why it works or what I'm doing but it seems to work. but this way the nclip and fclip are not being set properly.

maybe you can figure out what i should be doing and why this works.

[Cervian]

I need some time, tomorrow I have an exam at university
However I want to thank you for your incredible effort!

[kavehth]

I need some time, tomorrow I have an exam at university
However I want to thank you for your incredible effort!

no worries, good luck.