Xycaleth

Players can already peek around corners in JKA with 3rd person view

I don't think anyone's thought about it, but funnily enough there is an existing animation that spins the character 180 when standing which I don't think is used.

There's no central place that bounding boxes are fetched from. There's a single set of functions that do the collision detection but you still need to find all the places where the bounding boxes are stored and manipulated.

There are no classes for it. Pretty much all the code assumes AABBs are used so it's not going to be an easy replacement. Btw, in terms of anything being modularised in jka, answer is always "it's not modularised" unless you're asking about large systems like rendering, or server code etc.

Your build script looks fine to me. Are you able to run the provided builds without it segfaulting? If so, are you able to get a stack trace for your build when it segfaults?

That's a specular highlight

Reflections are another can of worms they don't just happen automatically

Looking good

If you're installing from disc, maybe the disc has been damaged? The cyclic redundancy check (CRC) is there to make sure that files are copied correctly and have the expected "fingerprint". If the CRC is consistently failing then the disc could be scratched I would recommend buying the game again online (Steam/GoG) and install it that way

I think N is the direction from the sphere which you are currently integrating over. This might help: https://github.com/knarkowicz/IntegrateDFG

Here's a really useful doc I found on PBR for artists. It's a bit of a read but I think it covers everything you need to know: https://docs.google.com/document/d/1Fb9_KgCo0noxROKN4iT8ntTbx913e-t4Wc2nMRWPzNk/edit?usp=sharing

All the rain drops in that video have an alpha of 0.4 so they're already being alpha blended. There's almost no perceivable fps drop

You can derive surface positions from the depth map. Water drops aren't going to be (and don't need to be) pixel perfect. You can randomly place them and they will look completely natural.

Implementing proper support for IBL?

Even if that were true (I'm not saying it's not, it sounds very plausible!), people still complain about altered saber blocks when simply recompiling the sdk code with no changes. Or made changes in completely unrelated areas of code.

On this line: { c, s, 0.0f },Multiply c by ratio. That should scale everything along the x axis by the ratio variable.

Here's the source code for the FBX to G2 converter in case anyone was wondering: https://github.com/xycaleth/FBX-Ghoul2-Converter I can't remember where I got to. I think I had problems with normals not being written correctly..

I was planning to use the same principle as a shadow map. At the start of the map I'll render a birds eye view of the entire map depth into a texture (or multiple). Then each rain drop can check against this depth map to see if it should be drawn or not. Can also use this to randomly place rain drop effects.

Code is here: https://github.com/xycaleth/OpenJK/tree/rend2-dev/weather There's some hard-coded stuff there at the moment, so it only really works properly for mp/ffa5. If anyone wants to improve on it, first thing to do would probably be to stop it raining inside, and also to make the rain follow the camera.

No splashes atm. That could potentially be an improvement though. I'll upload the code sometime today

So... I had the misfortune and fortune of having a full weekend where I could just work on rend2 the whole time. It's unfortunate because this only came about because I'm ill. Fortunate because I've been able to get somewhere with adding weather Here's what I have so far: All I'm missing now is to stop it raining indoors and underneath things, and to make it a bit more customisable so that it can do other weather effects. I also need to actually spawn rain around the camera, instead of covering the entire map. When I get around to doing any of that, who knows So, the fun thing about this rain, is that there are around 250k rain drops, with very little performance impact. It even runs well on my MacBook Air which isn't the most powerful thing in the world

The tangent vectors are also used by the renderer when rendering a model with normal maps so ideally it needs the same tangent vectors that were used when generating the normal maps. From reading the posts so far, FBX/XSI already store the tangent vectors (I don't know if it's the same ones used for creating the normal map?) so it's a matter of copying these tangents into the GLM file.

Just to point out - normals in the GLM format aren't written as half-precision (actually, nothing is). Normals are written as full 32-bit floats. @@Archangel35757 your confusion may come from bone data which uses fixed-precision numbers, which can be less accurate for small numbers. I still don't fully understand why the tangent vector needs to be stored in the model itself, but here's what I understand so far. Hopefully others will find it useful. For a normal vector, there can be any number of tangent basis vectors. As long as these vectors are perpendicular to the normal, then you can consider them basis vectors.For this reason it's useful to define a standard method to compute these vectors - this is what mikktspace is. Given a model and its vertices, regardless of triangle ordering, or ordering of the vertices in each triangle, the mikktspace algorithm will always produce the same tangent vectors.Normal maps created from hi-poly models will need to create its own basis vectors during the generation process. Rendering a normal-mapped model, using different basis vectors can cause artefacts.Therefore, you want to store (or alternatively calculate at load time) tangents created from the model. mikktspace gives the same vectors for a given mesh so is a good candidate.You probably want to store the tangents instead of calculating them at load time because it looks to be more time-consuming than other simpler methods.Even if mikktspace is not used, storing the tangent in the model means the renderer will use the same tangent vectors as those used when generating the normal map.Hopefully @@Almightygir can tell me if I've missed anything here or said anything wrong. I don't fully understand all the problems, but the reasoning for storing the tangent vector in the file makes sense to me. I think someone else mentioned in an earlier post that an auxiliary file containing the tangents could be produced. This seems like a good way to go if you don't want to change the GLM file format. Anyway, I would say, if you have more important features you want to add to your renderer then ignore this problem for now and come back to it later It's no use having perfect normal/tangents if everything else looks bad

Not very. It's just storing one more field per vertex, and reading one more field in the renderer.

I would recommend against using FBX as a format that the renderer uses directly. FBX is designed as an interchange format i.e. An intermediate format for ease (certainly not speed) of conversion between formats. I'd imagine it to be quite a lot slower to load as well.