[Warhammer Dark Omen Forum]

Warhammer Dark Omen Forum | Modifications | 3D Scenery Models
Portrait meshes

[olly]

Thanks!

[EvgenS]

I haven't checked the forum for awhile and just noticed your sneaky conversation.
Great progress Dougie!

[dougie]

Thanks Evgen, I hope to have some screenshots and a working application with the coming weeks

[dougie]

Things are looking good here, but I have a few concerns like whether the system I'm making will run smoothly on slower computers, I'll have to test that out.  but otherwise I've got lighting to work with render targets.  I'll post screenshots of the grissburg scene that I'm creating.

[dougie]

[olly]

Very nice! Well done

[dougie]

Cheers  , I'll keep going with it till I've got some levels implemented, probably

[dougie]

An update on the portraits implementation. The animations are looking pretty good
like the original, First scene is working with clicks.

Here's a screenshot.


I'm about to start on some ui elements, arrow buttons basically

I maybe need help working out which animation sets are used by each
character, there are a multitude 0-64
so it's a time consuming task

For example Clouse has animation set 26 immediately when he starts talking.

All the animation sets currently are in 0.seq

code looks like this:

Code:

c->SetBodyAnimation(26, this); or
for example
c->SetBodyAnimation(0, this);

[dougie]

just realized, I might have edited that 0.seq a while back, could be less than 64

[olly]

Looking good!

[devast3d]

Picking up the work. Did some tests on the 1.seq using 0 animation (that is charge).

13 XX XX XX
Seems to be the same as 03 XX XX XX, but only occurs as the first command in the animation

03 00 XX XX or 03 04 XX XX
Second byte seems to be controlling interpolation somehow. By changing 04 -> 00 and recording the videos I see some minor differences during the movement, but nothing really dramatic, only slight diff. Probably we can ignore this.

01 XX XX XX
Is connected somehow to the mouth animation (0A). By removing it from the charge the mouth animation started a lot earlier. Not sure it always works like this because sometimes 01 appears after 0A. Need more investigation. This flag appears rather unfrequently though.

02 00 00 00
Appears before 08 00 00 00 in the end of the animation. Only tested on charge. By removing it from the list mouth animation ended much-much earlier, so it again is connected to mouth (and/or sound) somehow. Need more investigation.

I've written the tool to edit SEQ files . Here's the interface .

Open - select source and destination SEQ files
Save - save current state to the destination SEQ
MakeStatic - copies first frame of the animation all over the animation (kinda deprecated due to the next feature)
Edit - allows to edit the bytes manually, very handy. Bytes are in hex, each one should be separated by the whitespace/newline
ResetEdit - reverts the string to the original state

[olly]

Excellent Thanks!

[devast3d]

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.

[olly]

Awesome!

[devast3d]

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.