[Warhammer Dark Omen Forum]

Warhammer Dark Omen Forum

The whole point of my post was that you're doing work that is mostly known.

- All sounds/music patterns have been converted into wav and imported into UE4 already.

- Most of the DarkOmen\Sound\H files have been converted into UE4 CUE files. There are some parameters that I've not used, but particularly pitch and volume were deviced using FREQ, FREQDEV and VOLUME. Also TYPE and LOOP were used to specify the type of the sound and looping. ATTACK/RELEASE, PRIORITY and FLAGS are not used. The first ones correspond to the fade in/out I think. Priority should be used when many sounds are playing I guess. FLAGS are unknown.

- Music FSM files don't need to be converted directly since FMOD plugin is used to play the tracks (right now I've only created FMOD project for the first level track, but that's enough)

- Speech sounds of the allies have been mapped as well. Mapping greenskins and undead is a bit more complicated and has not been done yet (some of them are mapped, like charge and death sounds though).


Very useful task would be to create new music track for the beginning.

Music and sound have been decoded.

DO tracks are split into short patterns. These patterns are played according to the state machine files stored in DarkOmen\Sound\Script folder. They are text files, so pretty easy to read. Basically there are blocks which contain patterns to play and transitions to another blocks depending on the state controlled externally. The states are: deployment, normal, good, bad. The block can play random patterns to add more variety.

I was able to recreate this behaviour exactly using FMOD studio. The tracks can be played via FMOD plugin then.

So there's not much that can be done in terms of original DO music. But if you're able to create new tracks (in the same style, with patterns and transitions) that would be great! We can discuss it.

p.s. I'm project PIC

I'm using Behavior Trees - https://docs.unrealengine.com/en-US/Engine/AI/BehaviorTrees/QuickStart/index.html

They are applied to the unit type and work the same on different levels. Waypoints are just parameters. Scripting manually is too much work.

I decided to go from scratch because it's faster. Waypoints are taken from BTB file.

For DOR we got most of the mechanics implemented. Last large areas left untouched yet are magic (will be delayed after the demo launch) and AI (is the next thing we'll implement after finishing with current hot tasks, that should happen in couple of weeks).

Unfortunately, I didn't plan to implement multiplayer since it simply wouldn't fit into my time budget. I'm the only programmer in the project and Dark Omen turned out to be _far_ more complicated that I anticipated at first.

p.s. Also answered you in another thread.

Our current remake attemp named Dark Omen Reborn as was mentioned. We're working for about 2.5 years already and plan to release the first demo in about 3 month from now. It's the closest Dark Omen replica so far, we're trying to make it look like Dark Omen and also trying to replicate mechanics as close as possible. Further project destiny is unclear at this point and will depend on the demo launch.

We're using Unreal Engine 4.16. But TBH it's not the best engine for the RTS game, the code is tailored specific to the Dark Omen replication.

The project was always in dire need of additional programming hands. However, 2020 seems like a distant date at this point, we can't say for sure what will happen with the project up to that date. I hope we will finish DOR before 2020, since it took too much time already (I'll do all I can do make it happen). We don't do many status updates, but the work silently goes on usually breaking shortly when real life demands it. When enough stuff is added user evgen compiles it in the blog post and uploads the video on youtube.

For more details I encourage you to join our Slack channel (olly can help with that).

Regarding b101 mission anims: "get the loot" and "they're heading to the trading post..."

- "get the loot" Uses 9 anim from the 2.seq (ngobs use 2.seq and 9th anim seems to be reserved for such cases)
- "they're heading..." uses 9 anim from the 1.seq
- these sequences are completely the same in terms of commands, but use different key files obviously
- the most interesting thing: while "get the loot" is very short, "they're heading..." is rather long (but commands are the same!). I think this is overriden by special flag of some sort, which tells the animation to stop when sound stops (if I remove 0A command from 2.seq, I see full sequence, not the short one!)
- both use 127.seq for the facial animation, however, 0A 04 command that's used is rather short, but in "they're heading..." the mouth animation looks much longer. I think this is another override: loop the 0A command while animation is playing. Proof: I've pasted 05 00/01 commands inside facial animation and Morgan was constantly opening/closing his eyes while "they're heading blablabla"

Here're several examples of what the code currently produces. All looks good so far. I think this is OK and I can stop portrait work here. Going to merge the code into DOR now.

[attachment=1]
[attachment=2]
[attachment=3]

p.s. Had to switch to nearest filtration (pixel look) due to DO portrait textures are unfriendly to bilinear.

A bit fixed seqreplaceui tool. Added proper vertical scrolling, otherwise you can't normally view/edit 126.seq/127.seq files (mouth animations).
[attachment=1]

These files are of the strange structure. They got many sequences, but only few of them contain data, other only contain single 08 command.

126.seq file:
Contains 32 sequences in total. Only sequences 0, 1, 2, 3 and 17 contain data. Sequences 0 and 17 contain 05 (eyes) commands and 06 (mouth) commands. The rest contain only 06 commands.

127.seq file:
16 in total, 0-4 contain data. Only contain 06 commands.

Most of the sequnces only contain 0A command with 00-03 index, however 9 sequence also contains 0A 04 which makes me think these seqs use 127 file for the mouth animation. Gonna try this file first.

The 0A command itself is very simple:

0A XX 00 00

where XX is the mouth index. There are 5 indices in total:

00 10
01 11
02

they correspond to the column/row of the mouth inside the bits texture.

To obtain the row/column one can easily do this:

uint8 col = (state & 0xF0) >> 4;
uint8 row =  state & 0x0F;

What's bothering me is that there's no time in either 0A or 06 commands. So it's probably hardcoded somewhere.

[attachment=2]

Ended up using TCB splines (https://en.wikipedia.org/wiki/Kochanek%E2%80%93Bartels_spline). Modifying tension and bias gives DO-like look. Used different sets for 0304 and 0300 commands. Not exactly the same as in DO, but looks pretty good.

Going to end curve research here due to lack of time. Moving to eyes/mouth animation.

Decided to move the experiments to the external 3d editor since I'm out of ideas.

Here're two options that I've tried (on the images you see x/y/z rotation channels):
[attachment=1]
[attachment=2]

First one looks similar to what I get in UE. On the second curve we see substantial overshooting and this looks like something DO uses (not exactly the same but in the same direction)! So the task is to find how DO devs calculated this curve (and tangents on the keys).

p.s. 03 00 XX XX overshoots much more than 03 04 XX XX command. Probably they differ either in curve type or in tangents of the same curve.

After toying with SEQ a bit more I think they're using some kind of spline interpolation between the frames.

Rationale:

I've taken 1 sequence from 1.SEQ file (enemy sighted)

13 04 01 04
03 04 05 06
03 04 19 02
0A 01 00 00
02 00 00 00
08 00 00 00

Here we have 3 animation keys: 13->03->03

If interpolated linearly the animation never reaches the same position on the first 03 command as in DO (stopping much earlier). This is where I thought there's some kind of overshooting applied. So I nuked second 03 command from the sequence, leaving only 2 animation keys. Playing this sequence in DO resulted in unexpected (at least for me) result: the animation stopped at the same position as in my program! There was no overshooting at all.

After that I think there's some spline interpolation applied. Tried Catmull-Rom spline interpolation today (different parameterizations, including most famous uniform, centripetal, chordal), but it didn't overshoot at all. Moreover, this spline type requires at least 4 points (and SEQ animation can have just 2, like e.g. "all is lost", 6 in 1.SEQ), so I had to duplicate and jitter end points to make it work. Probably other spline type is used in DO, going to try...

Something is really wrong with the animation interpolation in DO.

By using the KEY data and simply interpolating between the keys with linear interpolation sometimes the animation doesn't reach the same positions as in DO. So either we got KEY data extraction wrong (don't think so) or DO devs did something crazy with the interpolation.

I've tried to apply overshooting when interpolating, i.e. instead of interpolating between two keys using 0.0-1.0 factor, interpolation is done in 0.0-1.X factor, i.e. 1.0-1.2. In effect this creates some exaggeration of the movement. Actually, this worked in some cases! And I've finally reached the same pose as in DO for e.g. 01 animation in 1.seq file. It doesn't work the same for all animations though.

Another very interesting observation. I've taken 0 animation from 1.seq (charge). It contains the same 03 commands

13 04 14 04
03 04 0A 0A
01 05 00 00
0A 03 00 00
03 00 0A 0A
02 00 00 00
08 00 00 00

notice, two 03 commands have the same 0A key! The only difference is in 04/00 byte (we know this somehow affects interpolation). Observing charge portrait animation in DO I can see that there slight movement in the end of the animation (though the position shoud be the same!).

So I did some testing. I've copied last 03 command and pasted it many times. Got following results in DO:
- animation is NOT static on these copied keys, I still see small movement (really small but noticeable)
- depending on 00/04 byte the movement is either constantly periodic or fading away slightly

And if I can somehow understand the fading case, I really don't get how can one get non fading movement between the same keys!! Even when using overshooting of some sort. It's like they have some sort of acceleration applied (which is also non-sense since the positions are the same). Another DO dark magic...

[during]

About 01 XX 00 00 command.

It's simply the delay command. The animation playback in DO will wait certain amount of time (controlled by the second byte XX, not sure the exact conversion rate though) before issuing commands that follow, i.e. everything is still executed in the linear fashion.

=====

Although, everything is not really that linear. E.g. 06 sequence (all is lost) looks like this

13 04 14 03
03 04 14 07
0A 02 00 00
01 05 00 00
05 00 00 00
02 00 00 00
08 00 00 00

05 command (close eyes) happen during the body/head animation (03 command). Not right away, but after some time (01 command).

=====

OK, I think I got it after twiddiling with SEQ files for couple of hours.

01 command actually isn't simple delay. It's a parallel command! Let me elaborate.

First, 01 command is dependent on 03 commands. 03 has its own time of animation. Basically all the animation happens between 03 commands. Let's call single 03 command execution time a segment. So 01 command starts parallel execution in the current segment (i.e. relative previous 03 command) after specified delay. But, 01 also has time! From my experiments if 01 time is less than its 03 time, then current segment's length is unchanged. However, if 01 time is larger than 03 time, then current segment is extended! It doesn't really makes sence to use this since it'll simply introduce pause in the animation (because 03 will already finish its job).

Second, 01 is used in conjunction with 05 and 0A commands. Its main job is to delay these commands relative to nearest 03 command (by specifying 01 time less than its 03 time). This will make eyes/mouth/sound play during the current animation segment.

Third, time scale of the 01 command seems to be the same as in 03 command.

Not sure if all this 100% correct, but at least it fits into my current tests without breaking anything.

BTW, for some reason 05 command is ignored if there's no 0A command in the sequence! At least this happened in my tests with battle SEQ files.

More KEY stuff.

Quick reminder:
- each file starts with header byte (num of items)
- each item is 12 bytes long (first 6 is body, second 6 is head)
- each rotation consists of 2 bytes
- second byte has more influence

New stuff:

These 6 bytes represent Pitch, Yaw, Roll respectively in the 1st, 2nd and 3d byte pair. E.g. if you only want Roll you write
00 00 00 00 RR RR

Now, second pair byte always has first digit 0! I.e. actually only 3 digits matter: XX 0X

As was mentioned second byte has more influence. By doing some simple replacements I've figured out the following:

Second byte
- 04 gives 90 deg rotation
- 08 gives 180 deg rotation
- that means 01 of the second is 22.5 deg of rotation

First byte
- Logic says that FF of the second byte should be equal to 01 of the first byte
- This seems to be true from my tests
- i.e. 01 of the first byte is 22.5/256 deg of rotation (let's call it UR - unit of rotation)

So basically they have quantized 360 deg using 2 bytes. Also animation is done via shortest arc, i.e. going from 00 to 07 will go one way, from 00 to 09 the other way (google SLERP on this). Checked this by experiments:

- 00 00 to 01 08 (that's 180deg+1UR) one way
- 00 00 to FF 07 (that's 180deg-1UR) other way
- Going from 00 00 to FF 0F (360deg-1UR) practically shows no movement, although theoretically it should be 1UR of rotation (0.087890625 in degrees), probably too small to be noticed.

That's all for now.