Generate vertices, normals and uv coordinates directly from the map file.
astrochili opened this issue · comments
Now the script analyses an .obj file that contains ready-to-use vertices, normals and uv coordinates. This requires exporting the .obj from TrenchBroom every time the geometry is changed. It would be great to analyse the map itself to skip the export step.
This is an example of the brush:
// brush 104
{
( -144 -64 80 ) ( -144 -63 80 ) ( -144 -64 81 ) retro/TECH_4B 0 16 0 1 1
( -144 -64 80 ) ( -144 -64 81 ) ( -143 -64 80 ) retro/TECH_4B 0 16 0 1 1
( -144 -64 80 ) ( -143 -64 80 ) ( -144 -63 80 ) retro/TECH_4B 0 16 0 1 1
( -128 64 144 ) ( -128 65 144 ) ( -127 64 144 ) flags/unused 0 16 0 1 1
( -128 64 96 ) ( -127 64 96 ) ( -128 64 97 ) flags/unused 0 16 0 1 1
( -128 64 96 ) ( -128 64 97 ) ( -128 65 96 ) retro/TECH_4B 0 16 0 1 1
}
What does it mean:
(point_1) (point_2) (point_3) texture offset_x offset_y angle scale_x scale_y
The points generate a plane, not a face, we need to calculate the intersections of all the planes to produce vertices.
So we need to do three things:
- Generate vertices based on the planes.
- Generate normal vectors based on the planes.
- Generate uv coordinates based on
offset_x,offset_y,angle,scale_xandscale_yvalues.
At the moment, I don't understand how to do any of these tasks.
According to the issue, we could use the developments made in Qodot.
They also parse a .map file to generate meshes in Godot. For this purpose, there is a lib written in C - libmap.
Particularly, we're interested in this implementation: generate_brush_vertices
We can attempt to write Lua bindings for this lib or choose a more straitghforward approach and adopt the algorithm to Lua.
Looks like a solution. Thanks for the discovery!
We don't need a super perfomence here I think, so lua implementation is a good way. At any rate, I would go that way to be more independent from C libs.
Here I made a rough draft for testing. Looks like it does the job: Lua Vertices Generator
but...
It shows some different results from the .obj file got. Here are some difference in the signs and in the vertices order.
The brush I used for the test:
( -64 64 80 ) ( -64 -64 80 ) ( -64 -64 -16 ) retro/CRATE_1I 0 0 0 1 1
( -64 -64 80 ) ( 64 -64 80 ) ( 64 -64 -16 ) retro/CRATE_1I 0 0 0 1 1
( -64 -32 80 ) ( 64 -32 80 ) ( 64 -64 48 ) retro/CRATE_1I 0 0 0 1 1
( 64 -64 -16 ) ( 64 64 -16 ) ( -64 64 -16 ) retro/CRATE_1I 0 0 0 1 1
( -64 64 80 ) ( 64 64 80 ) ( 64 -64 80 ) retro/CRATE_1I 0 0 0 1 1
( 64 64 -16 ) ( 64 64 80 ) ( -64 64 80 ) retro/CRATE_1I 0 0 0 1 1
( 64 -64 80 ) ( 64 64 80 ) ( 64 64 -16 ) retro/CRATE_1I 0 0 0 1 1
Here is a result of the generator. I swaped Y and Z coords due to the same happens in .OBJ file:
01: -64 48 -64
02: -64 -16 -64
03: -64 80 -32
04: -64 -16 64
05: -64 80 64
06: 64 48 -64
07: 64 -16 -64
08: 64 80 -32
09: 64 -16 64
10: 64 80 64
And the vertices from the .OBJ file:
v -64 -16 -64
v -64 -16 64
v -64 48 64
v -64 80 32
v -64 80 -64
v 64 48 64
v 64 -16 64
v 64 80 32
v 64 -16 -64
v 64 80 -64
Look at the line 3 of my results and compare it with the line 4 in the OBJ. There is a difference in the sign of '32'. There are one more (or maybe two) another sign differences.
I don't know how it is crucial, probably just need to build a mesh and see the result.
I see only three matching vertices here — 04, 09 and 07. And then it is also important how correctly they are used to build polygons, it's more important than the verticles order. But it's a good start 👍
Added a PR here for your perusal.
#17
Originally very slow on < 1.8.0... on >= 1.8.0... extremely fast. Its also separate to the current obj method in case that needed to be used by others (wanted to add a non destructive solution).
Added a PR here for your perusal. #17 Originally very slow on < 1.8.0... on >= 1.8.0... extremely fast. Its also separate to the current obj method in case that needed to be used by others (wanted to add a non destructive solution).
Awesome! I will definitely check it out and do the test. This is a huge leap forward!
Posting this here for future reference, for parsing the JPEG texture size:
For info: I made a proof of concept for parsing JPG image size. Parsing was successful, map conversion works. But requires optimisation and cleaning, in progress. After that I will prepare a branch for merge and remove the old conversion method, as it is probably not needed anymore.
Note to me:
- Add a cache for image files already parsed, don't need to read the texture size fro the file for each face.
Commited a proof of concept for JPG textures – 1b60470