-
Posts
1,458 -
Joined
-
Last visited
Content Type
Profiles
News Articles
Tutorials
Forums
Downloads
Posts posted by Xycaleth
-
-
Ah nice Good find!
SomaZ, Tempust85 and Archangel35757 like this -
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.Archangel35757 and SomaZ like this -
@@Xycaleth - perhaps it is a coordinate system thing between MD3 and GLM? The MD3 specs state:
Also, aren't MD3 vertices/normals defined in a left-handed 3-space coordinate system and GLM is right-handed?
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 only difference I can see is that MD3 has tangent, normal and bitangent in a struct. GLM has normals in a struct, but not tangent or bitangent.
Also my VS likes to point to MDR code when finding the definition of normal, even though it is coded to point to the GLM one.
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?
Tempust85 likes this -
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?You can flip the normal channels in the shaders.
I'll try it with GLM, see how I go.
I don't think @@SmileTheory added support for AO or transparency.
-
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.
AshuraDX and Archangel35757 like this -
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
minilogoguy18, Tempust85 and Archangel35757 like this -
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.
minilogoguy18 and Smoo like this -
I don't have any plans to port it to SP for now. I'm already struggling enough just finishing it for MP
Smoo likes this -
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.
eezstreet likes this -
-
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.
-
-
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.@@Xycaleth would you have any time to look at my crash please?
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.
Tempust85 likes this -
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
eezstreet and LucyTheAlien like this -
Usually this happens when your have a pk3 mod whose directory structure is too deep, or the folder names are too long. The full path of every file in the .pk3 needs to be less than 64 characters. If not, you'll get this error.
There's nothing wrong with the error (it's not a memory leak), you'll just find some mods you have might not be usable or will be missing textures etc.
FEATURE: OpenGL 3 Renderer
in Dark Forces II Mod
Posted
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.