Application: djdduty

Join the team. This area is for people who want to participate in OpenMW's development in one way or another.
Post Reply
djdduty
Posts: 6
Joined: 08 Nov 2016, 23:47

Application: djdduty

Post by djdduty »

Hello everyone, I am djdduty.

About Me
I am a long term programmer who currently works professional as a backend web developer. I started programming roughly a decade ago and started game (and by game I mean engine, really) development a few years after. I have always been drawn to lower level aspects of games, such as graphics coding and optimization. I have created quite a few engines and graphics tests but they have become mostly scattered with only a few of my projects being collected on my github. A lot of the time I have started projects or joined them from the beginning of the code base so my major downfall is that I have never joined an in-progress project or adapted to a new code base, and I do worry that it may take some time for me to adjust. I have also never worked on actual gameplay code, always dwelling down in the depths of the engine where I can write new graphics features and optimize.

Recently, in the past year or two, I have become interested in networked multiplayer games and the various methodologies employed in creating a real time multiplayer game, so a lot of my newer projects have been focused around that in some way.

Outside of programming, I am a TES and fallout fan. I play many games, although not so much recently unfortunately. I really enjoy RPGs of any kind and the competitive nature of other genres such as MMOs.

Why do I want to help?
As I stated above, I haven't really spent too much time working on an actual game project, and I have come to the point where I want to expand my horizons a bit and work on game systems in a real-world scenario. I have also come to appreciate data+script driven approaches in engines and found an appreciation for just how much TES games abide this design principle.

How can I help?
I'm not sure, honestly. My programming experience is almost entirely c++ other than my job, and I hope that I can contribute to this project in any way possible. Be it optimization, features, or bug fixes. I have a good amount of experience in graphics development, albeit mostly with OpenGL / D3D directly and never higher level libraries. I understand most concepts to do with lighting, post processing effects, efficiently passing data to shaders or otherwise optimizing the render pipeline, pretty much all areas of rendering. I also have experience working with bullet physics and implementing it into my engines, and can test on many platforms (Windows, and Linux are my development platforms while I also use Mac).

So far I have read through all the developer related wiki pages and a bit through the code base and I think that contributing to this project would help me grow immensely. I've mostly only ever done things the same way, and I think I need to expand the types of interfaces and tasks that I'm exposed to. The opportunity to contribute to something with a community is also a very exciting prospect.

Links
My github, https://github.com/djdduty
User avatar
AnyOldName3
Posts: 2668
Joined: 26 Nov 2015, 03:25

Re: Application: djdduty

Post by AnyOldName3 »

If you've got experience with bullet you could start investigating why we have issues when the player or many NPCs are vaguely near objects with collision meshes. There are several issues related to this on the tracker, not limited to
We could blame this on there being too much going on, but equivalent situations work fine under the original engine and in other software using Bullet. If someone who knew what they were doing could take a look, that might go a long way to helping users without a top-end computer.

Alternatively, picking any interesting issue on the tracker and doing something about it is also helpful. There's no need to commit to doing something big.
djdduty
Posts: 6
Joined: 08 Nov 2016, 23:47

Re: Application: djdduty

Post by djdduty »

I'm not a bullet physics expert, but I can see if I can't profile it and figure out where it is maxing out at. If I can, then I will assign that issue to myself and commit to fixing it, until then, no promises as I haven't had a chance to fully dissect openMW quite yet . :D
User avatar
DestinedToDie
Posts: 1181
Joined: 29 Jun 2015, 09:08

Re: Application: djdduty

Post by DestinedToDie »

Hey. Nice to have you onboard. Since you are investigating bullet, here's my ingame experiments and also important discussion from other players. viewtopic.php?f=2&t=3696&hilit=sadrith+mora
djdduty
Posts: 6
Joined: 08 Nov 2016, 23:47

Re: Application: djdduty

Post by djdduty »

Well, I hope that it's not an issue with collision handling in bullet itself, otherwise it'll take a fork and revision of bullet itself to fix, however I doubt that's the case as morrowind meshes aren't complex relative to the type of collision meshes I've seen bullet handle. Bullet is definitely a more complex simulation than the original morrowind physics simulation though so it could very well be that it's just a much heavier burden to process the complex meshes. I'll try and profile the code itself and see which calls are taking the longest during that time, trace it from there.
Chris
Posts: 1625
Joined: 04 Sep 2011, 08:33

Re: Application: djdduty

Post by Chris »

djdduty wrote:Well, I hope that it's not an issue with collision handling in bullet itself, otherwise it'll take a fork and revision of bullet itself to fix, however I doubt that's the case as morrowind meshes aren't complex relative to the type of collision meshes I've seen bullet handle. Bullet is definitely a more complex simulation than the original morrowind physics simulation though so it could very well be that it's just a much heavier burden to process the complex meshes. I'll try and profile the code itself and see which calls are taking the longest during that time, trace it from there.
Most likely, it's related to how we utilize Bullet rather than Bullet itself. The actor movement code in particular was very hackneyed back when I originally wrote it, designed in a way to just work rather than utilizing it efficiently. In part because the Bullet docs are horrible in teaching you how to most effectively use the API, particularly with engine-controlled movement (e.g. a walking NPC or creature).

Things might've changed on both sides since I last dealt with the code, though.
User avatar
psi29a
Posts: 5356
Joined: 29 Sep 2011, 10:13
Location: Belgium
Gitlab profile: https://gitlab.com/psi29a/
Contact:

Re: Application: djdduty

Post by psi29a »

Bullet people are generally good with reacting to bugs/issues, especially when there are pull requests that fix them. We've had good interactions with them in the past.

However, as Chris said, it is likely how we use Bullet that isn't optimal.
djdduty
Posts: 6
Joined: 08 Nov 2016, 23:47

Re: Application: djdduty

Post by djdduty »

I found something a bit interesting in the code, but I don't think affects anything relating to the problem at hand, just thought I'd share.

The "physics" statistic seems to be measuring the entire MWBase::World::Update method (ultimately MWWorld::World::Update) and not exclusively physics things. The problem is definitely physics related I just thought this was interesting. MWWorld::World::Update calls some things that aren't physics related per se, MWWorld::Scene::Update for example. It also seems to call a weather update function and a method to reposition the 3D sound listener (the player's ears basically).

It's interesting that the "physics" metric is a measurement of all world processing(not including scripts), but seemingly includes weather updating, scene updating, effect updating, camera updating, updating fog properties, updating the 3D sound listener, whatever 'mPreload->updateCache' does from MWWorld::Scene::Update, and then also updating physics. This is assuming I am reading the code right, I don't have the full context as I haven't read everything.

I don't know if this other processing is even close to significant enough to separate into its own measurement statistic, especially since it is technically stuff that should always take the same amount of time to complete and not fluctuate based on scene complexity. Weather will probably always take the same amount of time to process, just like moving the sound listener and updating the camera, effects, and fog.

There have been lots of edits to this as I have continued to read the code and fix grammar mistakes in my post, along with generally improving readability.
djdduty
Posts: 6
Joined: 08 Nov 2016, 23:47

Re: Application: djdduty

Post by djdduty »

Okay, so it appears I CAN reproduce this problem. On average my physics was remaining < 1.0ms (0.5-1.25ms or so usually), but when I go to Sadrith Mora it goes up to 3ms or so on average, and upon colliding with those slave cages I get roughly 5-7ms, if I collide in the right spot and rotate my camera (changing direction vector), it goes to about 10ms. This is with definitely completely vanilla game files. I'm going to see if I can't look in to it now that I've got my environment setup with everything building from source.
User avatar
Pherim
Posts: 140
Joined: 27 Aug 2014, 15:37

Re: Application: djdduty

Post by Pherim »

Oh yes, that would be great if you could somehow fix the physics/collision issue. The vanilla game has absolutely no problem with complex collision meshes (many modded meshes don't have collision meshes at all and so their actual geometry is used), but OpenMW sometimes even has issues with vanilla meshes. One example I found myself is the bellows mesh which can be found near forges. It is relatively complex for a Morrwind mesh and does not have a collision mesh. I experienced a noticeable framerate drop when running against it in OpenMW.
Post Reply