Xycaleth

Firstly it doesn't really matter what the OpenJK project can/can't do in this situation. You're making something standalone and separate from it so it doesn't make sense to restrict yourselves unnecessarily. For the tangents, I don't know. AlmightyGir is more likely to know more about that than me as that's his area of work.

The IBL in rend2 is pretty poor. The different mipmaps of the cube maps are just downscaled versions of the original. There's no importance sampling being done.

Ah nice Good find!

Can you post a diff of your changes?

If you look closely, the normals still don't match (in the upper image). It's especially noticeable just above the upper leg guard. On the bottom image, they differ along the bottom edge of the belt. Is this outputting the normal map? Or the vertex normals?

Try outputting the normals as the colour from the fragment shader. It'll be something like color.rgb = normal * 0.5 + vec3(0.5);That will give you a better look at the normals on a per pixel basis.

The result of converting the spherical coordinates to a 3-vector will be in the Q3 coordinate space, and will be the same space as the normals stored in the GLM files. That shouldn't be the issue. The bitangent and tangent vectors aren't stored in memory for GLM models because the CPU never needs to do calculations on them. They're stored entirely on the GPU. I think the same thing can happen for the MD3 models too but it just hasn't been done. Do the normals look correct if you turn off normal mapping? That would rule out the normals being the problem since the bitangents and tangents are only used when normal mapping is enabled. If the problem is still there, it could be an issue with the exporter?

I'm not sure why the normals would be different. The bitangent and tangent are calculated at load time (when the models are loaded). Neither have them stored in the file itself. Here's the bitangent/tangent code for MD3s: https://github.com/DT85/OpenDF2/blob/rend2-sp/code/rd-gl2/tr_model.cpp#L714 GLM here: https://github.com/DT85/OpenDF2/blob/rend2-sp/code/rd-gl2/tr_ghoul2.cpp#L3607 They look pretty much the same to me at a quick glance. The code is split up a bit more than the GLM version. Maybe there's something I'm missing. EDIT: It's more likely the tangent/bitangent calculations are a bit wacky.

What do you mean transparency? That's just controlled by the alpha channel like it always has been. Or do you mean something different?

Just to point out, you can't slow down time in a multiplayer game at least, not for just a single player.

I haven't had a look to see how ghoul2 marks would work yet or how they even work in the vanilla renderer :/ so I'm not sure what needs doing.

They're not implemented yet in rend2 so there's nothing to fix it's still on my todo

Since it looks like this is ramping up a bit, I'll ask some questions which I've asked myself and didn't really like the answer. Making maps is already a long process. Adding more advanced tech on top of that like cube maps, pbr, realtime lighting adds an extra complexity to the process and requires more attention by the mapper. How can you make this easier? The main example I have in my head is how big is the area influenced by the cube map? Like SomaZ already mentioned, you could add a radius to the misc_cubemap to restrict the area that is affected, but there's no easy way to are this area in Radiant. You can support dynamic lights but there's no good way to preview and adjust these without a long compilation time every single time you want to change it a bit. For PBR materials, its not so much of an issue because you generally need the right tools to make them in the first place. The only answer I can come up with that integrates well with the engine, is to build them into the engine. Make it possible for dynamic lights to be positioned when you're running around in the map. Draw where the cube maps are and show their radii and allow them to be moved around and resized. Maybe I'm wrong, but I think people will get frustrated with not having at least some realtime feedback. The alternative is to change radiant but that I think is a much bigger task.

The entity limit is somewhat difficult to change unless you change the mod you're running as well. It's not just the engine enforcing it. For your mod it would be fine since you guys don't need to keep compatibility

I've diverged from the ioq3 code base slightly so not all their changes are applicable. The PBR cvar could be ported but it's mainly a simplification of what was already available. Instead of having multiple cvars to enable pbr, they've been consolidated into one.

I don't have any plans to port it to SP for now. I'm already struggling enough just finishing it for MP

The difference between jpg compression and png compression is lossy vs lossless compression. In the former you'll lose some image quality whereas in the latter you will not lose any quality from the source image.

Progressive jpegs aren't supported afaik.

What's the exact error you're getting? Word for word, letter for letter

Wait, are you running the Enhanced mod in JK2? I was under the impression that you were running regular JK2 and you never mentioned it until now If so, does it still happen when running the enhanced mod?

So if all you have in your base/ folder are the assets0, 1, 2, 3 and 5 files then it's an issue with the retail game and there's not really anything that can be done to fix the issue. You'll just have to ignore it.

For mac, what @@Circa has in his screenshot should be correct. I'm not sure why it's not finding the assets tbh :/ Can you try with a fresh config? I haven't had much time recently to look at anything unfortunately.

I don't have a windows pc available for the foreseeable future so I won't be able to debug. I can say though you should never comment out error messages just to avoid them. They're there to report something bad happened and to avoid worse things from happening afterwards. For the COM_BeginParseSession problems, the error message is saying it was called too many times without Com_EndParseSession being called. Every time you call the begin session function, there needs to be an end session otherwise you'll get this error. In rend2 I think there's a few cases where the begin function is used, and might not have the matching end session to go with it. I don't think MP was so strict with this which is why It doesn't have the problem.

Is there a shader called datapad_n? I think rend2 tries to automatically look for a texture which has the _n suffix to treat it as a normal map. Not sure why it would be crashing though - you might get a better idea if you build with debug configuration.

Assets99 isn't an original asset