openmw.org

Yep, just what I thought. If you're familiar with OpenGL, you should see what's odd with those last calls. Looks like I have some complainingbug reporting to do.

scrawl wrote: ↑14 Apr 2018, 22:23 Looks like I have some complainingbug reporting to do.

Lol, do you actually see bug reports as a form of complaining?

It depends. If it's something that is hard to notice and it's not in a release build, it's less likely to feel like you're complaining and telling someone off than if it's an obvious error that's snuck into a release.

Regarding that APITrace, what's the specific problem? It's a while since I've used VBOs or VAOs, so the only obvious problem I'm seeing is a bunch of zeroes and nulls, which I always see all over the place when I use APITrace with OpenMW and stuff seems to get rendered by the calls with zeroes and nulls, so I think it might be an APITrace bug.

The odd thing is that leading up to the crashing call we've started both a display list and a VBO. Display lists and VBOs are different techniques you can use to upload vertex data. It makes sense to use one of them, but not both at the same time, and it makes sense that non-robust driver implementations can crash when presented with this.

I wrote "complaining" not because I would say it's a rookie mistake (it's easy for something like this to slip through in a massive refactoring), more because I already reported the thing a year ago which appears to have been forgotten both by me and the maintainer.

The nulls in the vertex calls are normal I believe, they denote offsets into a buffer which, when you use separate buffers for each type of data as OSG does, are usually 0.

I'd just assumed that you could put a VAO/VBO in a display list in case you ever wanted to repeat rendering of more than one object. It also would save on repeated calls to set up other state, like which shaders to use or how lighting is set up.

Well, the OSG guys basically did some work and I think managed to fix at the very least the crash. Noticed they had responded to Scrawl's bug report and tested their test and didn't crash, unlike previously. So that is something, I posted my apitrace into that thread just so that it could be verified that the vbo's are no longer used with display lists. The commit in question is https://github.com/openscenegraph/OpenS ... 94483fe9d6 so should be fairly easy to apply to the fork I would think, and OpenMW doesn't crash anymore with new khajiit/argonian bodies, so yay on that I guess. Other than that it seems to work as expected, though I am not sure, it seems like sometimes the performance of the 3.6 branch on the fork is less than the 3.4, but could be wrong on that, might need some profiling and such to make sure there hasn't been some change that caused a regression. Anyway, I think I can say the 3.6 branch is fixed for me, though Scrawl might want to go and take a look at the apitrace I posted in the bug report just to make sure. It was a 30 meg 7z file so hosted it on google drive rather than putting it into github.

Great work! Way to get their attention.

This is an early heads-up. The first stage of terrain texture editing is nearly complete. We may want to make a few minor additions to that, but the texture editing feature is now very close to the point where we can present it to the users for further testing.

Since we already have 92 closed issues for 0.44.0 we should start preparing for the release once the textures have been taken care of.

Woohoo!

Shadows are almost done too though. There has been a lot of issues before, but there are not much left now. They look awesome for me, except for when I use distant land with a high view distance. This introduces shadow flickering at the moment.

Maybe it is worth waiting for this? What do you say, AnyOldName3?

Hi there!

Sorry that I intrude; I just have a noob question: will the saves we made with OpenMW 0.43.0 be compatible with 0.44.0?