-
Posts
1,458 -
Joined
-
Last visited
Content Type
Profiles
News Articles
Tutorials
Forums
Downloads
Posts posted by Xycaleth
-
-
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...but when he ignites the lightsaber at start, he does appear vaguely in the middle, duller spheroid object (or was that only the saber blade? ...hard to tell)-- so why is that? Hmm... maybe Anakin is a Vampire (and doesn't cast reflections)?
-
Reflections are another can of worms they don't just happen automatically
SomaZ likes this -
Looking good
SomaZ likes this -
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:
SomaZ likes this -
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
minilogoguy18 likes this -
How is the FPS of the rain when you add alpha channel textures for them?
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?
SomaZ likes this -
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.
Smoo likes this -
On this line:
{ c, s, 0.0f },
Multiply c by ratio. That should scale everything along the x axis by the ratio variable.ent likes this -
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..
minilogoguy18 likes this -
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.but im not sure how xycaleth is going to handle the indoor/outdoor and collision checking that late in the frame.
Can also use this to randomly place rain drop effects.
Tempust85, Archangel35757, z3filus and 1 other like this -
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.
Stoiss, minilogoguy18, Tempust85 and 1 other like this -
No splashes atm. That could potentially be an improvement though.
I'll upload the code sometime today
SomaZ, minilogoguy18 and Tempust85 like this -
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
-
@@Xycaleth - thanks for the clarification. But my question remains... what is the point of storing tangent basis vectors in a GLM mesh file-- if the GLM mesh file itself is not used for the normal map baking process?
If the normal map is baked using FBX, OBJ, XSI... isn't it those formats where it's desirable to compute or store the tangent basis vectors? Then those FBX, XSI, etc. tangent basis vectors would need to be carried over and written into the GLM mesh (and not computed from GLM directly), or am I misunderstanding?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.
minilogoguy18 likes this -
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.
Archangel35757 likes this -
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.
Quickturn
in OpenJK
Posted
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.