eezstreet

Our rules on porting have relaxed a little bit. Please see the rules section for the change:

And as I said... I don't care about aliens. There's exactly 2 speaking aliens in both JKA and JK2. There's only around 15 lines of spoken dialogue compared to the 50+ each for Lando and Jan. I decided Jan would be a good fit since there's a lack of female models out there, she has alot of dialogue, DT already modeled Kyle, and a female rig has eye candy factor as well.

Ideally I'd like to have only one _lipsync.gla, but I see no reason why other skeletons can't be used.

I don't care about aliens. If they use base lipsync, it'll be closer to the movies, actually. The only one I'm remotely interested in is Desann, but frankly his model is fine.

Yes.

tl;dr @ all My whole point to using two skeletons so that merging with _humanoid isn't necessary. Couple of reasons: - You can easily tell which skeleton the model is rigged to based on its MDXM header (_humanoid.gla vs _lipsync.gla) . This is important because otherwise, you'd have no way to detect if those bones are rigged correctly for that model. Keeps the facial animation working for older models that aren't updated. Lazy but I doubt someone feels like rerigging literally every model in the game. - By using a separate skeleton, you skip the need to merge to _humanoid. Just compile the GLA, no need to mess with _humanoid. - A separate skeleton is more easily extensible if we decide to add like capes etc (Sorry if I was brash before. Was running on low sleep)

Why use vertex animation? Bones are going to be a lot nicer-looking in general and you won't have as large of an FPS hit.

You need more bones. You can't add new bones to _humanoid without fucking it up.

You're correct, to some extent. We don't have a split skeleton, rather we have FACE, TORSO, LEGS, BOTH. (The names are arbitrary and have no bearing on anything at all, actually. Most are actually run on the torso..) What I'm suggesting is that we have a separate GLA entirely, and then rig new models to this GLA. The new GLA would have corrected face bones, but it would still be able to run animations from the _humanoid skeleton because the TORSO, etc don't modify the facial bones. The bones in the new GLA are run through the same transforms from the old GLA. Adding visemes to the existing GLA won't really work though because you need many more bones to get the proper effects.

I guess there really isn't any harm in posting it, then. Source. No, I'm not kidding. This is what I'm bringing to the table. While playing Vampire: The Masquerade - Bloodlines (see below example), I was completely enthralled by the level of detail in character expressions. I did some digging and it turns out that the VCD and LIP files from Source can be read/parsed the same way that .sabs, .shaders, and other things are read. As a result of this, you can use stuff like FacePoser etc in order to generate the positions of the face. Since you'd be making your own model, you can convert the model to whatever format FacePoser likes (.obj or .fbx, I guess?) and preview it that way. Example: If you're not familiar with Source's method, it involves a shared skeleton for the body, and then a set of transforms which get fed into it, and these transforms get certain aliases (ie an 'ah' sound) Process So, let's start with the nitty-gritty of how this works. Whenever the level loads, target_scriptrunners which point to a script with a sound block in it cause what is called a precache event. On precache, the sound file is loaded. My plan is to hook this process and in turn load our VCD and LIP files as well. The LIP files control the mouth positions involved with the corresponding .mp3, while the VCD file controls the scripture - gestures, emotions, etc. Here's an example of a .lip file: VERSION 1.2 PLAINTEXT { "Whoa" } WORDS { WORD Whoa 0.000 1.000 { 119 w 0.000 0.250 1.000 0 652 ah 0.250 0.750 1.000 0 596 ao 0.750 1.000 1.000 0 } } EMPHASIS { } CLOSECAPTION { english { PHRASE unicode 12 " W h o a " 0.000 1.000 } } OPTIONS { voice_duck 1 speaker_name Neo } And an example of a VCD file: actor "Vandal" { channel "My unique channel name" { event speak "My unique event name" { time 0.000000 14.461179 param "character/dlg/santa monica/vandal/line551_col_e.wav" param2 "70dB" fixedlength } } channel "Gestures" { event gesture "A little something extra" { time 0.000000 14.666667 param "ACT_CONVERSE_NORMAL_TALK" } } channel "Expressions" { event expression "A smiling finish" { time 12.000000 14.666667 param "vandal" param2 "Joy" event_ramp { 1.0000 0.0000 } } } } So the plan is to parse this data and use it for later when we're actually in dialogue. You might be wondering now how this all plans to be rigged. Again..there's another plan for this. Split Skeleton I noted something curious in the _humanoid.GLA, and perhaps you did as well. Remember how facial animations only modified the head, not the rest of the body? Well, my solution involves 2 distinct skeletons. One is the current _humanoid.GLA, and another is a _lipsync.GLA. The lipsync GLA has many more bones than the _humanoid.GLA, and only contains data/animations for lipsynching. Essentially, you would rig your new model to the _lipsync.GLA, since it has all the original bones of the _humanoid, + certain bones for detail, like in the face (maybe hands or something too? I dunno). I'm sure all of you will be saying "BUT BUT BUT...all the animations are in the _humanoid!!" Well, yes. All of the body animations. The idea is that the new skeleton will be able to mimic the _humanoid animations since it has all of the same body bones, but none in the face or head. Basically, the bone transformations from the _humanoid.GLA are run on the _lipsync.GLA, and since the _lipsync.GLA has all the same bones, it's no problem. The game won't allow for this unless you recode it to do so. But the capability exists based on principle as it is. The same thing could be done for capes too, actually. What I Need So basically, here's what I need to be made in order to get anything conclusive done with this: _lipsync.GLA (same as _humanoid.GLA, but more bones for the face and phoneme/viseme animations, as well as others (like rolling of the eyes, moving of the eyebrows, etc)A model (in GLM format, rigged to _lipsync, as well as in FBX/OBJ for faceposer)I'll probably also need to be able to contact someone directly via IM whenever it gets close to model rigging/animation time.

I know exactly what I need to do. I've researched the subject over and over again, and I have an exact plan made up. I need to make sure it's actually feasible before I do anything about it though. If someone makes the model, I will divulge my plan in full. No point in a theoretical debate about this sort of subject again.

I'm down with that.

If a modeller makes a new Jan model for this mod, I will add in better lip synching. As in, phenomenal lip synching that will blow your pants off. But naturally I need a model to test this out on that isn't JKA quality. It'll also need to be rigged special. Details to be provided on progress report of the model. @@DT85, @@minilogoguy18 and @@Psyk0Sith might be interested..

Yes, I've talked it over with them. Apparently, their latest tests work fine with OpenJK. However, their engine hooks are still in place. It's pure luck that nothing breaks, but it isn't safe. As I understand, the plan is to add a cvar which indicates whether or not the client is running OpenJK. But I think they use custom hacks for certain things. Not sure. A lot of the coders involved now are pretty amateurish when it comes to Q3, so it'll be most likely be assigned to me to work on it. So far, I've only done minor fixes and code cleanup, but whenever I get out of my current rut, I'll look into it. The current plan however is a complete hat toss. I've heard conflicting things from at least 5 different people. Some claim no, the mod is never going open source. Some claim that it's part of the active agenda. Others claim that they'll only release the source once the mod is dead. Either way, there's a big-ish release that's being worked on. I dunno why they haven't teased it or anything.

It's in a .bik video format. I could extract it from the CD and give it to you (I think I have JKA on my HD? could be JK2)

There's nothing really wrong with Awesomium. Sure, on outset, it does use a lot of resources and it has some weird licensing issues, but it allows for a very shallow learning curve when it comes to developing menus. This is why I use it in my game engine; my ultimate goal is to make it extremely easy for both content developers and programmers to create content for the game.

] My girlfriend was singing this the other day and it's been stuck in my head ever since. Listen, and think about clones. (or something)

I could do something, but I'd rather if we had good models first.

One bad shader probably broke all the others. It tends to happen when a .shader file has issues with the { }s

They're probably used in SP. I know JK2's ATST does have turning animations which work.

I used the colon to specify that it was a sort of spinoff, or different version entirely. Really though, the names JK2: HD, JK: Remastered, etc don't really capture the true point of this mod or the mods before it. The point wasn't just to simply improve the graphics, but improve the feel of the game as well. My thoughts immediately went to AoE2 HD/The Forgotten expansion pack, which, in addition to adding some higher resolution modes and some improved sprites, also added in a number of new gameplay features including the ability to stream to Twitch (this would be a nice option to add for this mod, but not right now). So my point is, perhaps we ought to stray away from simple names such as "HD" or "Remastered" or "Improved". It's not simply an alteration of the graphics, but something more beyond that, with tons of optional gameplay adjustments, custom games, a new mission or two for each game, etc.

I'd like to add one more game to the pot: http://kotaku.com/buffy-the-vampire-slayer-imagined-as-a-lucasarts-advent-1572484567

Because it would render base clients incompatible with OpenJK server, and vice versa. You can't modularize movement like you can a renderer. The renderer is just for graphics, and it can support whatever it wants, as long as the game works fine. With movement, it has to work a certain way, otherwise you get issues like desync.

Also: "music <map name>" works too, for dynamic music

Looks to be a fringe case, there's likely similar issues with all elevators.