DaemonEngine
WIP: Move most skeleton stuff to engine
Cgame-side pr: https://github.com/Unvanquished/Unvanquished/pull/3276.
A proper solution to the issue of highly inefficient IPC with skeletal models. Skeleton will now be built and blended in the engine instead of cgame, and it will no longer be transferred through IPC at all, +this will avoid a bunch of extraneous copies. An additional benefit is that this will skip doing anything with skeletons for entities that get culled away. Cgame will now only send the relevant frame numbers/lerp/etc through IPC as part refEntity_t.
The layout I'm using for testing is this: https://users.unvanquished.net/~reaper/maps/layouts/plat23/test.dat.
Probably related to that problem reported by CodeQL:
Thread 1 "daemon" received signal SIGSEGV, Segmentation fault.
Util::SerializeTraits<refEntity_t, void>::Read (stream=...) at src/engine/client/cg_msgdef.h:127
127 ent.boneMods = stream.Read<std::vector<BoneMod>&>();
So, this fixe dll. I now can get it run as exe too, but with nexe (PNaCl) I get:
Warn: IPC: Unexpected end of message
So, this fixe dll. I now can get it run as exe too, but with nexe (PNaCl) I get:
Warn: IPC: Unexpected end of message
I've added a few more fixes, can you check if you still get this error? Do note that I have pushed fixes both on this branch and on the Unvanquished one.
I get the same.
Anyway, can you rebase on latest for-0.56.0/sync so I can also test with Saigo? 🙂️
I get the same.
Hmm, that's weird. I'd need to look at it later, there are stil la few bugs that need to be fixed.
Anyway, can you rebase on latest
for-0.56.0/syncso I can also test with Saigo? 🙂️
Done, although I haven't tested it yet after rebase.
Thanks, the rebase was successful (I can build the game with Saigo).
I get the same error with a nexe built with Saigo.
Maybe there's padding being inserted into BoneMod in either daemon or saigo/nacl game, but not the other... At least that's the only potential explanation I have right now.
This is mostly done now, I believe the only remaining issues are because trap_R_LerpTag() needs to be modified to just work from the engine instead, +fixing the legs skeletons. Well, and whatever the above error is.
So I've unfortunately run into another issue: CG_SetAttachmentTag() (which is used for particle systems and such) requires some of the skeletons to already be built.
There are 3 options I can see right now: add more IPC calls to get skeletons just for those entities (which is really ugly), go back to the implementation that simply batches skeletons, or move particle systems to engine. The latter might also solve some performance issues with particle systems that we have right now.
This fixes a few things. The problems still remaining are legs skeletons not being set to torso skeletons, some animations missing/incorrect, and the above problem about particle systems/trail systems attachments.
So I've unfortunately run into another issue:
CG_SetAttachmentTag()(which is used for particle systems and such) requires some of the skeletons to already be built.There are 3 options I can see right now: add more IPC calls to get skeletons just for those entities (which is really ugly), go back to the implementation that simply batches skeletons, or move particle systems to engine. The latter might also solve some performance issues with particle systems that we have right now.
I figured out another solution for this:
- Add all non-particle and non-trail entities.
- Update their positions/skeletons etc. with an IPC call, but don't render them yet.
- Write the positions of bones (for tag attachments) that we're interested in with the command buffer.
- Read it on cgame side, and use those positions to spawn particles/trails.
- Add the particle and trail entities and render everything as normal.
Most issues fixed now, particles and trails work through a render entity cache. Just need to figure out why view weapons and jetpack behave weirdly (probably just because the original skeleton code in cgame was written by a fucktard).