Announcing switch to OpenSceneGraph

[uelkfr]

Are you serious? My opinion this is just waste of time. I think OpenSceneGraph lacking too much features and switching to it will not solve issues with performance (FPS) and memory (https://bugs.openmw.org/issues/2350). I think proper way is to develop tools to debug/profile those issues and solve them contributing to Ogre3d 1.10, last time I was profiling OpenMW the issue with performance was on OpenMW's side as it uses too much strings compare instead of integer compare.

[lysol]

Sorry, but did you even read scrawls post? It's not that performance was his only point of why he wants to switch. Ogre is developing in a way that works less good for OpenMW.

[raevol]

Are you serious? My opinion this is just waste of time. I think OpenSceneGraph lacking too much features and switching to it will not solve issues with performance (FPS) and memory (https://bugs.openmw.org/issues/2350). I think proper way is to develop tools to debug/profile those issues and solve them contributing to Ogre3d 1.10, last time I was profiling OpenMW the issue with performance was on OpenMW's side as it uses too much strings compare instead of integer compare.

Obvious troll is obvious. If you have a better way to solve our FPS problem please send a pull request.

[Chris]

Are you serious? My opinion this is just waste of time. I think OpenSceneGraph lacking too much features and switching to it will not solve issues with performance (FPS) and memory (https://bugs.openmw.org/issues/2350).

Can you say what features in particular are lacking? Moving to OSG will almost certainly improve performance since a measurable performance impact is linked with the rendering batch count, and the batch overhead is demonstrably less with OSG compared to Ogre 1.10/2.0.

Not to say there aren't also bottlenecks still in OpenMW itself, but there's also some in Ogre3D too.

I think proper way is to develop tools to debug/profile those issues and solve them contributing to Ogre3d 1.10

Trouble is, Ogre is monstrous. And it's currently in a transition towards an AZDO redesign with 2.1 which makes contributions difficult. Some of what we need fixed are being addressed in the redesign, but we can't rely on that version so we'd have to duplicate or attempt to backport that work. What's not being addressed we'd have to work on anyway, and it'd be better to do it as we need instead of a more general-purpose solution like Ogre would want.

[scrawl]

last time I was profiling OpenMW the issue with performance was on OpenMW's side as it uses too much strings compare instead of integer compare

Not sure what exactly you've profiled, but it sounds like the startup routines, rather than the frame update. StringUtils don't show up for me with a significant margin when profiling the frame update.
FWIW, some of the redundant string handling comes from the NIF loader, which is being overhauled for the port.

I'm curious too about what features you think are lacking. I spent a lot of time just reading code, so I'm very confident everything we need is there.

Forking software can be tempting when you're making a short-lived commercial product, but in the open-source world, the overhead of keeping up with upstream developments is almost never worth it in the long run. Especially when diverging significantly enough that you can't just "merge" patches from upstream anymore.

On a semi-related note, I found that it could take anything between a week to several months to get trivial patches merged to Ogre3D. One of my requests was stuck for five months, then merge conflicts started showing up, and it got stuck for another two months. How was I supposed to know about the conflicts? No one even told me...
Another one of my requests was stuck for over a year with no new comments, then finally closed with... no comment. When I inquired, the reason given was "we don't think this is important enough". That's fine, but shouldn't you explain that to me *before* you close it? Closing something with no comment doesn't exactly send the right message to other potential contributors.
Two years ago this wasn't a problem, I remember that MasterFalcon used to merge my patches quickly, but he left unfortunately. It seems that the new maintainers all have their own agenda and aren't overly interested in engaging community members, which is a bit sad.

In contrast, my first submission to OSG just got merged the day after I proposed it, which is nice.

[daret]

https://www.unrealengine.com/blog/ue4-is-free

Maybe ...

[Ace (SWE)]

OpenMW is as much of a game engine as UE4 is, trying to port one onto the other will just lead to issues and complications. Not something we want to do really.

[HiPhish]

"Free" does not necessarily mean "free". There are two meanings in English, one being "gratis" and the other "libre". Gratis-free means free of charge, i.e. with a 0 price tag. All other restrictions can still apply, such as copyright, restricted usage and so on. Libre-free on the other hand means free of restrictions, you can do whatever you want with it. In reality you will often find libre licences that still apply some restrictions like not being able to make changes without making them public.

Unreal 4 is gratis, but not libre. You still have to sign up to get your license and you have to pay royalties for the profits you make. And that's just the stuff on the surface, I'm sure there are even more restrictions for the source code.

[psi29a]

Another question is if UE's license is GPL compatible, if not, then it can't be used with OpenMW.

[matthewfarmery]

https://forums.unrealengine.com/showthr ... ource-game

I think that is a no, from what I understand, a user's work is fine, but not the engine itself, but then again, isn't that what the team are doing anyway? you get the openmw code, but you still need to download the other stuff separately, like the ogre engine. so in that respect, I'm not sure, but I think its a no, but could be wrong.