Differences from IsRyven Q3MAP2

[Baker7]

Garux, have no expectation of any actions but I wanted to make you aware of these. I am rather locked to the "IsRyven" Q3Map2 compiler ... I had considered switching because your compiler has more features and is maintained and seems to work better with stock Q3.

(I use J.A.C.K. for the map editor because I am very accustomed to where everything is -- and I don't use Q3 I use my own engine which is a DarkPlaces fork).

For comparison to what I use for stock q3map2 ... https://github.com/id-tech-3-tools/map-compiler ... which I will call "IsRyven" for clarity.

1. OBJ models. OBJ model orientation is different than stock q3map2 with seemingly no option to set for the "old way". I have thousands of models I converted to OBJ but I also converted them to md3 -- so most of the time isn't really an issue except sometimes a model cannot be .md3 due to size or some other reason.

2. I have at least one instance that it seems that Garux Q3Map2 cannot find a texture for an MD3 model. The .md3 model was written by Noesis. If I do some more tests and this is not "my fault" for some reason, I'll upload the model and the texture.

3. I have had _decal entities that Garux Q3Map2 says "texture matrix invalid" and then, I presume, ignores them. IsRyven does not print the warning or error and compiles it without a hitch -- I'm not implying that the texture matrix is right or wrong -- I try to avoid knowing too much about the internal workings of patches (for now).

4. I have had surfaces that Garux Q3Map2 seemingly does not like. I'll update with the exact warning text later. I would guess the surface is ignored? (The IsRyven compiler compiles the .map without a warning)

5. Garux Q3Map2 kicks out a scripts/your_map.shader -- which under many circumstances is probably a nice feature in many circumstances but I didn't expect a map compiler to write files to any folder except the maps folder. ( Is there a way to turn that off?)

6. During compilation, I swear it upgraded my lightmaps to size 1024 (I don't know why and I didn't specify that in the command line) which causes them to write as tga to maps/your_map/lm_0001.tga instead of being inside the .bsp.

I have been working on engine and mapping stuff for hours --- I wanted to record these now while I remember them --- and then maybe tomorrow I will provide data/screenshots/map samples to document these things.

Like I said, I'm fine with the IsRyven compiler for my use with DarkPlaces but I wanted to document these differences just so you were aware of them -- developer courtesy and all that.

[Garux]

1. This is QoL feature to load in orientation which max, blender and most of s/w use by default. Stock q3map2 and radiant required to rotate nearly every .obj
2. Using Assimp for models, it might fail on some special case.
3. Means generated shader is mandatory for the requested build settings. There is no option to intentionally create misfunctional build.
4. Build log might clarify.

[Baker7]

1. This is QoL feature to load in orientation which max, blender and most of s/w use by default. Stock q3map2 and radiant required to rotate nearly every .obj

Yeah, I know. DarkPlaces has a cvar to mess with the OBJ orientation.

However, the inability to turn it off means I cannot make a map that uses OBJ misc_model that is q3map2 compiler agnostic.

I cannot do a OBJ misc_model in a .map that works with every q3map2, I have to pick either the original q3map2 way or the Garux/Q3map way.

2. Using Assimp for models, it might fail on some special case.

I see.

[ensiform]

Does TrenchBroom's assimp implementation apply any rotation by chance? They seem to use it but more common for q1 and q2 maps.

[Garux]

Does TrenchBroom's assimp implementation apply any rotation by chance?

They do not do any exceptional rotation for obj, if this is the question. Using regular assimp orientation, as for any other format, same NRC and its q3map2 do.