Xycaleth

That's pretty cool. I always thought it looked like an office

I think it's the lack of lighting variation that's the problem. If you set r_cubeMapping 1, you'll get a wider ranger of lighting/reflections which will make the normal map more pronounced: P.S. your specular map is completely wrong

Maybe you want to look into having a gla per animation. Then have some sort of mapping in a config file from animation name to file per model. I think something like that would be much more flexible than having everything in a monolithic file? Or, to keep the existing gla file, let each model define some overrides per animation and then each new animation could be in its own file. So, say you add a new sit animation for Jedi model, you would have a new gla file with just the new sit animation and a config file saying what you're overriding. I think it's pretty much what eez mentioned now I read his post again...

You need a developer license to get it in the App Store

Oh, run /condump console.txt

Can you post the contents of the console when you're on the main menu? Run '/condump console.log' in the console, and it will create a file in your Documents\My Games\OpenJK\base folder.

Never do this as a permanent solution... @@ladiszlai have you tried a brush cleanup?

You have a map leak. Make sure your map is completely sealed and that you don't have any entities outside of your map area.

I can't say for sure why it's looking flat, but my guess would be because there's not many "real" lights in JKA so you don't get the lights shining across the surface. Try turning your saber on and see if that makes any difference. Also what does your normal map look like? You said you're using a bump map when I hope you mean a normal map

Did you create a replacement shader which makes use of the normal map?

There's also fs_basegame which acts as a secondary base folder. You can load an additional mod folder in addition to base and basegame.

Put it in the /shared folder! And work in a branch.

It's been fixed in the past week. Just waiting for the next build to be released now

It's not that simple. Anything that is attached will contribute to the problem. That includes jetpacks, that includes (in JKG's case) armour, etc. If anything the code needs to be redesigned to avoid the problem altogether. But this still doesn't solve anything for models in JASP

I'd never considered the same normal map would be used for multiple models I'll look into it. It don't think it would be too much work to do. I imagine it would just be a keyword in the shader to say this is an object space map instead of tangent space.

Okay, think I've found the problem (again?)! Any Ghoul2 model attached to the model also counts towards the limit. For example, if your model is holding a saber, you would add another numSurfaces*4 + numVertes*20 for that extra model. Does that bring the numbers over the limit?

Ok, that makes sense. Blaster fire/saber collision detection is done against the G2 model. I'll look at why you're still getting errors even when you should be within the transform space limit.

That's strange :/ I can't see anything in the code that would cause this to happen. Do you ever get the transform space error when you only have one player on screen? My only explanation is that the collision detection isn't happening unless there's more than one player. I don't believe this is a problem caused by rendering models. Instead, it's when collision detection needs to be done.

Great, thanks for the input everyone I think I'm going to go for metallic workflow since @@AshuraDX says the artifacts on material transitions can be avoided. I think rend2 already has code for metallic workflow - I just need to enable it and make sure it's working properly.

Okay, just looked at the code. In OpenJK, SP and MP both have the same amount of 'transform space', which is 262144 bytes. JASP seems to have roughly half the amount of transform space compared to JAMP; JASP has 132096 bytes of transform space, JAMP has 262144 bytes. The equation you're trying to satisfy is: number of surfaces * 4 + total number of vertices in an LOD * 20 <= transform spaceIn other words, both the number of surfaces and the total number of vertices can trigger the error, but total number of vertices more-so. I don't know which LOD gets used, but assuming you're hitting the error, I'm guessing it's using LOD0. For JASP, you can have around 6600 verts maximum before you hit the error. In JAMP and OpenJK, you can have around 13100 verts before hitting the error. Both cases assuming you have 32 surfaces. EDIT: The 'transform space', in case anyone is curious, is used for transforming the model vertices for collision detection.

There's a setting called "detailed shaders" which mrwonko is referring to. It'll be under advanced settings. Make sure this is enabled.

I can't remember exactly when the vert transform error comes up. I'll take a look when I'm back from work.

The meaning of the albedo/specular maps in a specular workflow isn't the same as the albedo/specular maps in the traditional workflow though. You can't use one set in the other, so I don't think that's really a good reason for using specular workflow in this case. With regard to metallic workflow, the edge artifacts along material transitions is kind of a deal breaker for me though

Been doing some research on PBR workflows. As far as I can tell there is a metallic and a specular workflow. Those of you who have experience with both, which do you prefer or think is better? From my point of view, the metallic seems to be better since it's more difficult to get wrong and uses less texture memory. Thoughts anyone?

I've added the extra key to OpenJK: https://github.com/JACoders/OpenJK/commit/6f805a17 https://github.com/JACoders/OpenJK/commit/ddd179c