openmw.org

SmartGuar wrote: ↑06 Apr 2019, 20:17 Especially since OpenMW depends on software made by other people which this project can't improve significantly.

SmartGuar wrote: ↑06 Apr 2019, 17:40 I meant Bullet and maybe also OSG.
There was a discussion about it, but it was more than a year ago and I can't find it. Something about physics problems and Bullet, I think.

As a matter of fact, someone (Stomy) was working on dedicated physics for OpenMW for a few months, but he hasn't been around for a while. I don't think anyone is about to make a dedicated rendering engine any time soon, but it's worth noting that OpenMW did already jump from OGRE to OSG, so it's not utterly inextricable from one or another either. In any case, it's not as though OSG and Bullet aren't themselves open-source and in active development.

Most of our bullet problems would go away for one reason or another if we switched to using it in double precision mode, but single and double precision bullet have different ABIs, so it can cause problems for distributions that only package it one way and not the other, too. Bullet is the kind of thing that should always be exactly the version the dependent application was developed with, so it's kind of weird.

wareya wrote: ↑07 Apr 2019, 20:02 it can cause problems for distributions that only package it one way and not the other, too.

Can we, forgive my lack of technical expertise, compile it in? So we're shipping it instead of linking to it? I guess we can't do that for distributing the source code...

We do that with WIndows, MacOS and our Generic Linux builds. We have all the control there to make sure everything is double precision.

Bullet is complied with double precision on downstream distros depending on 64 and 32 bit. If arch is 32-bit, then it is float. If arch is 64-bit, then it is double.

So the question is, do we just drop 32-bit support and make it easier on ourselves?

Maybe release 1.0 with 32 bit support and then drop it? So that at least a final, fully Morrowind engine-replacing version for 32 bit exists..? I dunno...

If someone wants 32-bit morrowind, they can use morrowind.exe? (answer not meant to be taken seriously)

Haha, well yeah I guess. Except linux and mac. At least not natively.

I'm sort of in favor of the "drop it and see if anyone complains" approach that was suggested somewhere...

I don't really know how distros handle it exactly, but I'd say just require double-precision Bullet and have an option to static-link it (on by default?). Leave it to the distro to worry about putting together a proper build for whichever architectures it supports; if they don't want to support double-precision Bullet on 32-bit targets, even when static-linked so they don't have to change their Bullet package, that's not up to us. The only other thing we may want to require is SSE2 on x86 32-bit builds, since the x87 FPU is terrible.

Could also check if we're running into problems with floating-point denormals, and see if they can be disabled without creating an issue, since they murder performance. SSE allows disabling them, and I think ARM doesn't have them to begin with (x87 is left in the dark).

Husaco wrote: ↑07 Apr 2019, 08:38

SmartGuar wrote: ↑06 Apr 2019, 20:17 Especially since OpenMW depends on software made by other people which this project can't improve significantly.

SmartGuar wrote: ↑06 Apr 2019, 17:40 I meant Bullet and maybe also OSG.
There was a discussion about it, but it was more than a year ago and I can't find it. Something about physics problems and Bullet, I think.

As a matter of fact, someone (Stomy) was working on dedicated physics for OpenMW for a few months, but he hasn't been around for a while. I don't think anyone is about to make a dedicated rendering engine any time soon, but it's worth noting that OpenMW did already jump from OGRE to OSG, so it's not utterly inextricable from one or another either. In any case, it's not as though OSG and Bullet aren't themselves open-source and in active development.

I tend to get distracted by other projects but I am still working on the dedicated collision/physics system, and I fully intend on giving the same treatment to the rendering system eventually. I'm very disappointed with OpenMW's performance and want to improve it as best I can but it will take a whole lot of time to unravel.