Page 4 of 4

Re: Very low FPS

Posted: 30 Apr 2019, 09:23
by Stomy
Chris wrote: 30 Apr 2019, 08:05 Someone who doesn't know OpenGL well, though, is going to make unoptimal and error-prone OpenGL code because they're unfamiliar with how to use it correctly.
True you don't have to learn about culling and sorting, but you still have to know about transforms, shaders, the fixed-function pipeline, the renderTraversals system, the node hierarchy, and any number of OSG's OOP architecture quirks. Someone trying to write efficient code effectively still needs to know what the video card is going to do, and OSG is simply a different API to interact with. Realistically it ends up being the same risk, because you still have to have knowledge of underlying concepts and you need to know how OSG expects you to implement it, or else you'll also end up writing bad code, you'll just have a different API to blame it on.
Chris wrote: 30 Apr 2019, 08:05 It's not just total line count, but also compartmentalization and maintainability.
Those elements are not diametrically opposed, and it's possible to have compartmentalization and maintainability expressed in a small number of lines just as well, with the added benefit of there being less to compartmentalize out in the first place.
Chris wrote: 30 Apr 2019, 08:05 But after we have the code, what then? Can you guarantee you'll always be available to deal with issues as they arise, or add new features as they become desirable? If someone wants to contribute, will you be there to help them learn what they need to know about your code? If you leave, is someone else going to be able to pick up where you left off?
Well my pledge to you is that you won't need me to explain how it works because it will either be simple enough, or sufficiently well commented, that a person could understand just by reading it. I mean you guys already lost your rockstar Scrawl and you've been managing just fine, just because the engine links OSG doesn't mean the code using it doesn't have to be legible. It's not a new problem, it's an inherent part of working in a group project.

Re: Very low FPS

Posted: 30 Apr 2019, 10:05
by wareya
Bullet's internal structure is very poorly suited for how OpenMW is using it right now. (And so is its interface. And its general behavior.) Any in-house replacement for it would be a relative quality improvement, even if it was written by a CS 101 student with a poor grasp on geometric 3d math. And there's basically no chance of it being unmaintainable given how few things OpenMW needs out of a collision system. And we can always continue to include bullet for things like oblivion-style physics dynamics, which is the kind of thing bullet is actually designed for in the first place.

We can worry about replacing OSG if and when it happens. OSG is quite decent so it would be hard to design something better and there's no point talking about it if there's no code on the table. On another note, custom rendering engines are the norm for game engines, by the way.

Re: Very low FPS

Posted: 30 Apr 2019, 13:43
by psi29a
I'm leaning heavily on wareya here with the post above.

Regardless of performance on both the physics and rendering side of things, while important... not as important as getting OpenMW nearer to the established goals of 1.0

I'm still of the opinion that getting OpenMW 1.0 is more important than bike-shedding about performance issues. It's distracting, at least in my eyes, unless someone is willing to put forth the code.

If people wish to focus their time coding, great, I think that what Stomy is doing has merit and if he can deliver on efficient/performant/small/self-sufficient/well-documented code that allows us to drop, at least temporarily, a dependency on Bullet, then it's well worth the effort.

We can then use Bullet for what it was meant for when we get to supporting other bits like Oblivion/Skyrim style physics.

Re: Very low FPS

Posted: 30 Apr 2019, 19:04
by onionland
wareya wrote: 30 Apr 2019, 10:05 Bullet's internal structure is very poorly suited for how OpenMW is using it right now. (And so is its interface. And its general behavior.) Any in-house replacement for it would be a relative quality improvement, even if it was written by a CS 101 student with a poor grasp on geometric 3d math. And there's basically no chance of it being unmaintainable given how few things OpenMW needs out of a collision system. And we can always continue to include bullet for things like oblivion-style physics dynamics, which is the kind of thing bullet is actually designed for in the first place.

We can worry about replacing OSG if and when it happens. OSG is quite decent so it would be hard to design something better and there's no point talking about it if there's no code on the table. On another note, custom rendering engines are the norm for game engines, by the way.
+1

When the bottleneck that is the current bullet implementation has been removed we will likely get a clearer image of just how much OSG is dragging openmw down, and then if needed consider the alternatives

Re: Very low FPS

Posted: 29 Sep 2019, 11:04
by faerietree
All of you have a point. My position is: Never change a running system if you don't know the scope of the effort (I see this in my electronics day job everywhere. Easy words. Difficult deeds. "This or this is much better" while actually the difference is minor and the effort switching over and all the interrelated a priori forgotten consequences produce unimaginable extra cost and consume time at its best). Or in case you know the scope of the effort: Never change a running system if the effort is bigger than the reward."

The problem is we do not know the reward. We can only let do as Stomy wants as he is a very capable coder for sure and seems to value the words of Leonardo da Vinci: "Simplicity is the utmost sophistication".

Sometimes things are good enough the way they are. Until someone comes up miraculously with something better that convinces even the last sceptics. These people are to be honored. It has happened throughout history. But that is not limited to only those persons. Many people work hard towards noble goals and should be rewarded better.

For me I must say the engine even works on systems without dedicated graphics cards. It may not be super immersive then and I understand people wanting more. Let's hope science will lead to more performance and possibilities in the near future. Thus let's not break our heads too much about it (which does not mean we should be ignorant about it).

Just as an example: I know other projects where they have custom rendering code. It is stalling. Noone dares to really update|improve it - for years. Only the initial creator, a capable coder, did.
Not using Bullet, collisions are on the wish list for almost a decade. The entire feel of the engine over there suffers from the lack of dynamic possibilities (cell loading, combat physics, supply lines) as well as peaceful diversity (animation blending|inventory|stackable entity|special effects|particle systems).

Things OpenMW has all built in already. In a not exactly bad performing way at all. A reason to be very very proud of what OpenMW already is.

Re: Collision detection system discussion [Original title: Very low FPS]

Posted: 30 Sep 2019, 13:39
by lysol
I moved this topic and changed the title. See reason in first post.

Re: Collision detection system discussion [Original title: Very low FPS]

Posted: 01 Oct 2019, 04:43
by wareya
Reward: we can get rid of a library that makes it very hard to ensure that the game isn't glitchy as as hell when moving to a more-sane movement solver.