Custom levels for Jak 2/3 now support envmapped TIE geometry. The TIE
extract was also changed to ignore materials that have the specular flag
set, but are missing a roughness texture.
Jak 2/3 now also support the `build-actor` tool.
The `build-custom-level` and `build-actor` macros now have a few new
options:
- Both now have a `force-run` option (`#f` by default) that, when set to
`#t`, will always run level/art group generation even if the output
files are up to date.
- `build-custom-level` has a `gen-fr3` option (`#t` by default) that,
when set to `#f`, will skip generating the FR3 file for the custom level
and only generate the GOAL level file to skip the potentially slow
process of finding and adding art groups and textures. Useful for when
you want to temporarily edit only the GOAL side of the level (such as
entity placement, etc.).
- `build-actor` has a `texture-bucket` option (default 0) which will
determine what DMA sink group the model will be placed in, which is
useful to determine the draw order of the model. Previously, this was
omitted, resulting in shadows not drawing over custom actors because the
actors were put in a bucket that is drawn after shadows (this behavior
can be restored with `:texture-bucket #f`).
This PR does a few cleanups:
- improve method names/comments/flags for `enemy.gc` and a few other
files
- fix `new-stack-matrix0` not working for jak 3
- add `matrix-copy!` detection for jak 3
- add `vector-copy!` detection
---------
Co-authored-by: water111 <awaterford1111445@gmail.com>
There's a feature to draw levels with a different camera matrix. This
uses `camera-temp-other`, `camera-rot-other`, etc instead of
`camera-temp`, `camera-rot`... I assumed that `trans-other` was the
"other" version of `trans`, but it turns out this isn't true -
`trans-other` is combined with `quat-other` and the original camera
matrix.
This fixes the issue by using the translation part of
`inv-camera-rot-other` for othercam levels only. (it works in all cases,
but I didn't want to use it for normal levels since I think it will be
less accurate)
Co-authored-by: water111 <awaterford1111445@gmail.com>
Migrates all code, there should be no change in the compilation output
(linter should check this)
At first i was considering making these builtins, which short of a bunch
of code generation, would require some sort of dynamic definition in
`Atoms.cpp`. This isn't hard but, i figured it would be better to keep
it simple and just generate the OG macros.
Fixes https://github.com/open-goal/jak-project/issues/233
Kind of silly fix.
The cloth update function sometimes runs before the "setup" is done
(`need-setup` is set), which divides by zero in a bunch of places. This
fix prevents NaNs from spreading during this time.
Co-authored-by: water111 <awaterford1111445@gmail.com>
This should fix the crash when entering the freedom HQ elevator. It was
caused by a large number of prints, one for each process in the city
being killed by `check-for-rougue-process`, which would overflow the
print buffer. So I increased the print buffer.
Detecting buffer overflow here is hard because lots of things are
allowed to write to it, including the user's GOAL print methods. I added
a basic check that will assert when there's 1k or less space in the
buffer. It won't catch every overflow, but it would have caught this
one.
Co-authored-by: water111 <awaterford1111445@gmail.com>
I finally went through and worked out the math for the camera matrix,
and improved how it works for PC rendering. I was able to finally avoid
the double perspective divide issue, which I always thought would cause
accuracy issues.
This will help tfrag, tie (no envmap), shrub, and hfrag have less
z-fighting in cases where the camera and the thing you're looking at are
pretty close, but the entire level is far from the origin - like jak 3
temple. I was able to modify the camera matrix so we don't have to do
all the weird scaling/addition in the shader.
Here's a screenshot from the temple oracle checkpoint, cropped from 4k.
This used to have a lot of fighting issues.
It doesn't help issues where the thing you're looking at is very far
away (jak 1 mountains, some jak 2 city stuff). It also doesn't help with
jak's skirt/scarf, since those use a different renderer.
There's definitely more to do here, but this is a good starting point
and proof that I can at least figure out the math.
Co-authored-by: water111 <awaterford1111445@gmail.com>
In Jak 3, the default PC settings file would have a language of 255
because it runs before the first settings update. This would cause the
game to crash the second time it is started.
I also added this simple imgui window to see the names of streams in the
"SPU" memory, which has been useful for debugging
---------
Co-authored-by: water111 <awaterford1111445@gmail.com>
Accidentally incrementing `s` twice in the loop, so queued streams in
slot 1, and 3 were skipped by the overlord.
This would usually cause the audio to never start playing because the
game would wait for the audio to successfully get queued.
Co-authored-by: water111 <awaterford1111445@gmail.com>
Change jak 3 SPU DMA to run the interrupt handler "immediately" (or at
least before `DMA_SendToSPUAndSync` returns).
This fixes an issue where audio can hang during fast cutscene playback.
I'm hoping it fixes more issues with looping/stuck audio as well, but
this needs more testing.
I originally wanted to do it this way, but thought that it didn't work -
from Jak 2 it seemed like things broke if the DMA was too fast. But, at
least for Jak 3, everything seems to work like this. This will remove a
huge source of non-deterministic timing in audio stuff and hopefully
make things easier to debug. It also means that a large portion of
streaming audio code will never have to run - from the game's point of
view there's always the next SPU buffer available.
If this works well, I might revisit jak 2 as well.
Co-authored-by: water111 <awaterford1111445@gmail.com>
Fix a missing scale factor when using the large mode in the animation
compressor. This would make some joints have a translation of near 0 if
the original animation had stuff moving a large distance
Co-authored-by: water111 <awaterford1111445@gmail.com>
Two new flags were added to the Blender plugin to allow reusing the mod
and/or eye draws of the original model that is being replaced. Works
pretty well for eyes, but the blerc draws can cause some Z-fighting with
the non-moving parts of the model.
Also a small refactor to the merc replacement code to de-duplicate some
code by moving stuff to `gltf_util.cpp`.
A few improvements to color palette selection. These were made by
tracing some particularly bad colors through and seeing where it made
obviously bad decisions for splitting. I tested on crystal cave, and a
test GLBs from Kuitar that previously had issues with alpha.
- The previous approach to splitting was based on trying to keep a tree
of deduplicated colors balanced (same count in each leaf). This is not
really a good idea for generating color palettes. A better approach is
to try to minimize the volume of the child node, limiting how inaccurate
a color can be. Splitting is now chosen based on the average of the
_deduplicated channel values_, which in practice seems to work pretty
well for Kuitar's levels. Other approaches could work here too.
- The previous approach of alternating through dimensions to split on
was kept.
- The depth of the KD tree during the initial split was increased,
allowing it to use up to 8192 colors, instead of just 1024.
- In most cases, not all child nodes of the tree have colors in them,
meaning that a tree of depth 13 would have less than 8192 colors. If
this happens, child nodes are split until the color count reaches 8192.
The selection of which nodes to split is somewhat arbitrary, but is
breadth-first. The axis for splitting is the one with the largest range.
(which might be a better idea in general?)
On crystal-cave, the worst case color error was reduced from 221 to 9.
---------
Co-authored-by: water111 <awaterford1111445@gmail.com>
Fixes the issue with animations doing a full 180 degree rotation and
disappearing. The quaternions in the GLB export "flip", and when
interpolating animation frames in between a flip, we got bogus
quaternions.
Fixes https://github.com/open-goal/jak-project/issues/3786
Also fix a crash in `goalc` when using merc models without any
materials.
Co-authored-by: water111 <awaterford1111445@gmail.com>
After collecting 600 orbs, cloth systems that didn't have any
`alt-tex-name`s defined would vanish because the `static-cloth-params`
macro doesn't default them to `#f`.
Store a small database of which models have already been swapped out in
a level to prevent duplicate processing.
Also a small fix for cases where using a model replacement that has no
armature would cause merc nightmares due to only having a `max_bones` of
3.
Folder names were in common with the normal intel x86 build, the release
wasn't going to work. Hopefully with these changes it will but, still
technically untested. Don't have time to do so tonight.
Several users have reported that ArchipelaGOAL is not launching
properly, even when using the OpenGOAL Launcher. The window pops up with
a black screen, and then quits. The only way they can run it is if they
double click gk.exe.
This comes down to the Launcher providing gk.exe with the `config_path`
parameter, which leads the program to find `archipelagoal-settings.gc`.
Here is an example from me:
```
D:\Applications\Games\OpenGOAL\features\jak1\mods\JakMods\_settings\archipelagoal\OpenGOAL\jak1\settings/Mods/archipelagoal-settings.gc
```
If a user's base OpenGOAL install directory is long enough, this path
becomes longer than 128 characters. This overflows the character buffer
in `kopen` which is used to open file streams. If you're only slightly
over the limit like myself, at 135 characters, you may not have noticed
a problem. But some users have paths a little longer, like 168
characters, and they report the issue is consistent.
Water111 suggested we remove the 128 character buffer and use the
filename data directly. This fix requires no changes to the Launcher,
just to the kernel, and every mod could stand to benefit from this fix.
When a material in Blender has its IOR level changed to anything other
than the default value of 0.5, the `KHR_materials_specular` extension is
applied during the glTF export, which is what we use to check for
envmaps in custom models. If an envmap is undesired, but the IOR value
was accidentally changed, the program would assert during model
processing if there is no metallic roughness texture attached to the
material.
Since this is an easy mistake to make and is hard to spot, this adds a
better error message for such cases.
water111