saberhawk

A new asset plugin is somewhat required. Let's dig in on the engine details a bit before we call things giant unwieldy mega systems with no merit, shall we? So, skinned mesh rendering? The engine originally shipped with CPU-side rigid (i.e. one bone) skinning. It was stuck at this for a while because the contemporary exporter only supported rigid skinning, which doesn't work great for actual skin. The BFME version of the exporter added support for two-bone soft skinning by duplicating the rigid skinning system and storing an extra set of vertices optimized for rigid skinning along with the extra bone IDs and weights required. This is incredibly memory bandwidth and space intensive and doesn't scale very well to soft skinning with more than two bones. It does look better though, and the engine was updated to read and use this "new" type of skinning data. You are. The purpose of WWskin was to make the content in the content authoring tool behave like content in the engine does. Things like inverse kinematics (i.e. feet following terrain) require engine level support when not faked via baked hierarchy transform animations. Which is what mocap data generally is, until you get into facecap, and already supported by the engine. k. PS: Whatever you do, don't log how long MeshModelClass::get_deformed_vertices(Vector3* dst_vert, Vector3* dst_norm, uint32 stride, const HTreeClass* htree) takes as it hits the slow weighted skinning case many times each frame in a multiplayer match. Getting rid of confusing features like the W3D fixed function emulation übershader generator would really help. An audit was performed on a large library of .w3d files and per-vertex specular lighting wasn't found, so I didn't bother to both create test cases and implement accurate emulation of those test cases to prevent the übershader from exploding much more than it already had. I wish I knew what all the various material settings really did. The options in the exporter GUI don't always match up with the data contained in exported files. Old exported files need to keep working, they don't just disappear. Exported files contain lots of features not exposed by the exporter, such as alternative materials. The rendering system runtime data is very different than the stored data. For example, all texture coordinates are stored upside down and need to be flipped. Why? Because Renegade originally used SurRender 3D which followed OpenGL math conventions instead of Direct3D ones. These quirks in the file format can't really be fixed without updating all the required related tools, like the level editor. Which we couldn't really update because the GUI used MFC6 which is now two decades obsolete and incompatible with newer compilers. The engine also performs plenty of fixups for "oh noes, we exported the file but the settings are wrong and we can't export a new version" and fog. After all of that, the post-processed mesh finally makes it to the step of generating #defines for the shaders that it needs to compile to render triangles with that particular combination of settings. This happens with the source code found here. https://gist.github.com/saberhawk/199235c38a2b1051f06f0340cec9b5b4#file-ff_generator-cpp-L22. The rest of the gist contains the übershader code. There are some optimizations to prevent compiling a particular shader twice and to load compiled shaders instead of compiling them as required, but there are still a ridiculous number of combinations. And then the actual D3D11 rendering engine just uses whichever shader (i.e. compiled .fx code, not the "shader" in the W3D exporter) and a combination of constant buffers and textures, some static and some dynamic. Which is so much more powerful than the limited options from the exporter, and what those options eventually end up in anyways so they can work. Is it really that much of a dream for tools to just use that directly instead of maintaining the fixed function emulation übershader generator?

A fair question, we don't know yet. The game should have created crashdump files and stored them at %USERPROFILE%\documents\W3D Hub\games\apb-release\debug. If you compress (zip/rar/7z/bz2/whatever) the most recent crashdump files and upload them here we can take a look.

That's good, because it's still quite new

What engine limitations? If we managed to overcome the primary challenges, we'd already be well equipped to handle any platform differences. Consoles do work differently though; something like the launcher wouldn't pass technical requirements.

No, because it's packed into always.dat. Why would any other file packed into alway.dat be fine?

The current launcher is unlikely to ever support Linux as it's a WPF application. http://www.mono-project.com/docs/gui/wpf/

Changing settings in engine.cfg or through the launcher? Both apparently. I tried what saberhawk suggested and it didn't work. engine.cfg changes definitely affect the game. Is it possible that you are using an older version of Bandicam that doesn't support capturing D3D11 games?

Something you could try is changing the fullscreen mode to 2 in Documents\W3D Hub\games\apb-release\engine.cfg.

Or you can just go in game to Options->Configuration->Performance, select Expert Mode and change the Texture Filter?

We'll see.

It is the latter. While it would be a neat feature, NVIDIA and Oculus have both released SDK's in order to help developers create new games for the HTC Vive and Oculus Rift. From what I've seen, the Oculus rift also takes advantage of motion controls as well. That would mean an entirely new animation system, as the current one is so rigid it requires button presses to change animations. While I don't doubt the skill of the guys at tiberian technologies, I seriously doubt a complete, VR-ready animation system is in the works or even in the scope of their scripting knowledge. And if it was to favor the HTC Vive as opposed to the OR, you would want to make sure that the motion controllers could give feedback if used. Shit, I'd like to see a limited, adjustable aiming deadzone put in place (not that I would use it, but it's a nice feature). Long story short, while definitely possible, it would take too much development time. Without some sort of grant from EA to start working it, there would be no reason to do it. What most people think about modding and "scripting" with this engine is wrong, especially when it comes to recent iterations ("scripts 5.0"). Yeah, there's probably a feature where a button press will play an animation (on what?) in a networked game. Some people use it. It's far from the actual animation system capabilities, it's an old "script" using a hacky interface put in place about a decade ago. Before we, you know, added a decade's worth of code and all the man-years of previous thought in the designs we cloned. Like all the one the ones required for defining the concept of a "script" in the first place, the input system to detect that button press, the netcode to send it to the server and synchronize clients, and the animation system to actually play it by sampling animation curves and feeding the also cloned/rewritten/rewritten again/and again rendering engine. All of these with many of our original hacks in place for backwards compatibility with ourselves and some other closed source projects and shared between a huge number of mods. Things are "laggy" because too much gameplay is written literally in scripts.dll in "script" form which is all server side scripting. Things are "ugly" because the tools suck and can't feed the engine better data, and I'm working as fast as I can to make better ones. I wish people would/could help, but they usually don't so I prioritize whatever I feel like doing. Taking a break from thinking about VR systems (which is part of my day job) and working on a simple 3D engine is supposed to be relaxing. Always, but it's going to be much broader than what is traditionally thought of as gaming and adding in other forms of entertainment and communication. It's also incredibly useful when it comes to jobs that deal with designing physical objects. Designs for "things" are growing increasingly virtual and the ability to visualize and manipulate those designs directly and easily is incredible.

It's not much work to remove the one line or so of code that updates the camera direction at all. Using head tracking is slightly more complicated because nobody seems to agree on directions; is +Z up, into the screen, or out of the screen? What's actually complicated is getting the engine to render twice as much content to a 2560x1200 screen at 90FPS. Failure to maintain frame rate could get people physically sick. Sudden camera movements need to be avoided, otherwise people get physically sick. Each eye uses a slightly different perspective, so any tricks that assume a single perspective need to be fixed, otherwise they will look weird and could also make people sick. A few things that immediately come to mind are certain particle systems, "billboards" (camera aligned objects), and the sky actually being a tiny sphere that's shrinkwrapped to the camera and nowhere close to where it should be physically. After people can finally stay inside the virtuality for more than a few minutes, then comes the matter of controls and redesigning the HUD. The old trick of "put it in the corners" doesn't work anymore, as those are almost entirely outside your field of view and very difficult to see. Depth contrast also needs to be introduced because it's a lot more effective than color contrast. The trickiest thing will likely be compelling and fair gameplay for VR players vs non-VR players. A 24 player VR-only match would be cool, but that's years away realistically. This only holds true if you assume the desired return is something like X new players or Y more sales because of that VR mode. It's very likely that there are only a few players with VR capable computers, and APB is a free project. But it's run by volunteers. Some of which might see the experience of adding support for emerging VR technology to an existing game engine as rather valuable, even if only a handful of other people will see it at first. Kinda. SteamVR has something called "Desktop Theater" which simulates a large screen for you to play games with. Potentially IMAX sized, pretty epic. That's probably the closest that you can get to running any existing game in VR and it's likely that it'll support a fake VR-like mode for games already supporting stereoscopic 3D rendering. But you can only count on it for the HTC Vive right now since it's still very early in the VR wars; it's unclear if Oculus will support SteamVR.

A mission in the SP campaign was Havoc infiltrating a Nod ship.

If anybody tries that, I'll change the code reading/using stylemgr.ini to break compatibility. Because that's the better place to change it in the first place.

This is news to me since I specifically avoided using simultaneous multiple render targets due to lack of hardware adoption. Which Intel GPU are you using?