OpenGEX as .Nif alternative for OpenMW

General discussion regarding the OpenMW project.
For technical support, please use the Support subforum.
User avatar
cc9cii
Posts: 523
Joined: 28 Mar 2013, 04:01

Re: OpenGEX as .Nif alternative for OpenMW

Post by cc9cii »

Lamoot wrote: 06 Dec 2020, 15:32 At first I was afraid it was some overly complicated way to define which animations are used in the engine.
Well, technically some of them *are* used to define which animation frames are used - e.g. the text keys are used to play certain parts of the animations (in Morrowind all the animations seem to be combined into one file and text keys are used to specify what to play and when to stop whereas other games usually have different animations in separate files)
Lamoot
Posts: 176
Joined: 22 Apr 2016, 12:03

Re: OpenGEX as .Nif alternative for OpenMW

Post by Lamoot »

cc9cii wrote: 06 Dec 2020, 23:49
Lamoot wrote: 06 Dec 2020, 15:32 At first I was afraid it was some overly complicated way to define which animations are used in the engine.
Well, technically some of them *are* used to define which animation frames are used - e.g. the text keys are used to play certain parts of the animations (in Morrowind all the animations seem to be combined into one file and text keys are used to specify what to play and when to stop whereas other games usually have different animations in separate files)
Ah right, so they are not to be discarded just yet. I'm just glad I don't have to deal with the whole thing (yet?).

Two things I worked on recently is the walkforward animation and I tried to hack the better collada exporter to avoid manual scaling of the model and animations by 70 at every export. Not much success with the exporter, but the animations are progressing well enough.
Lamoot
Posts: 176
Joined: 22 Apr 2016, 12:03

Re: OpenGEX as .Nif alternative for OpenMW

Post by Lamoot »

Not much progress with animations, but I got the Better Collada exporter working with a scaling factor. This means there won't be a need for a time-consuming workaround at every export. Here's where the exporter is at https://github.com/unelsson/collada-exp ... tch11_2020

I also changed the bone names to fit the "Bip 01" naming scheme originally used in Morrowind. The reason is OpenMW is still hooked on those names for the player character.
User avatar
cc9cii
Posts: 523
Joined: 28 Mar 2013, 04:01

Re: OpenGEX as .Nif alternative for OpenMW

Post by cc9cii »

Just thinking out loud - wouldn't it be better if the bone names *are* different? That will allow the animation code to treat them differently (if there are any differences, that is). I would imagine there can be additional bones as well which will have to be handled by the animation code.
Lamoot
Posts: 176
Joined: 22 Apr 2016, 12:03

Re: OpenGEX as .Nif alternative for OpenMW

Post by Lamoot »

cc9cii wrote: 18 Dec 2020, 22:22 Just thinking out loud - wouldn't it be better if the bone names *are* different? That will allow the animation code to treat them differently (if there are any differences, that is). I would imagine there can be additional bones as well which will have to be handled by the animation code.
Eventually we'd indeed want to not be tied to specific bone names. For now though, we're focusing on getting the Template / Example Suite into a decent shape so we simply accept such constraints. This constraint applies to the player character (and I presume other NPCs). For creatures or other animated models there's no such issue.
Lamoot
Posts: 176
Joined: 22 Apr 2016, 12:03

Re: OpenGEX as .Nif alternative for OpenMW

Post by Lamoot »

I started documenting the collada pipeline. https://gitlab.com/OpenMW/openmw/-/merge_requests/505
unelsson
Posts: 227
Joined: 17 Mar 2018, 14:57

Re: OpenGEX as .Nif alternative for OpenMW

Post by unelsson »

Git-versions of OSG and OpenMW just got updated so that Collada finally works. Would be nice if someone could test and confirm that static collada models work with the following pipeline:

1) Use the newest 3.6 branch of OSG https://github.com/openscenegraph/OpenSceneGraph
2) Use the newest master at https://gitlab.com/OpenMW/openmw
3) Use this fork of collada exporter https://github.com/unelsson/collada-exporter
4) Use Blender 2.8 - 2.91, make a model, make material(s), and in shader node editor, use "Image Texture"->"Principled BSDF". 1 Blender unit = 1m in game.
5) Export "Better Collada (.dae)", with object selected and "Selected Objects" set ON in the exporter window, also use scale factor of 70.
6) Open the dae-file with text editor, look for your texture (.png or .jpg) and change it to "textures/yourfilename"
7) In OpenMW-CS, create an object using your new dae-model, then drag that object to some cell to create an instance

I've tested this, but it sure doesn't hurt to test it on different platforms and by different people too. Maybe these details could be added to OpenMW documentation too.
User avatar
psi29a
Posts: 5356
Joined: 29 Sep 2011, 10:13
Location: Belgium
Gitlab profile: https://gitlab.com/psi29a/
Contact:

Re: OpenGEX as .Nif alternative for OpenMW

Post by psi29a »

For point 1, I've pushed upstream master and OpenSceneGraph-3.6 to our OSGoS repo: https://github.com/OpenMW/osg

I have also rebased our 3.6 branch on top of OpenSceneGraph-3.6 so you should be seeing some perf improvement there.

https://github.com/OpenMW/osg/tree/3.6
unelsson
Posts: 227
Joined: 17 Mar 2018, 14:57

Re: OpenGEX as .Nif alternative for OpenMW

Post by unelsson »

psi29a wrote: 19 Jan 2021, 14:13 For point 1, I've pushed upstream master and OpenSceneGraph-3.6 to our OSGoS repo: https://github.com/OpenMW/osg

I have also rebased our 3.6 branch on top of OpenSceneGraph-3.6 so you should be seeing some perf improvement there.

https://github.com/OpenMW/osg/tree/3.6
Fantastic! It looks like we can actually say that Collada is supported now. :)

But of course, there's still work to do. Major thing is supporting base animations, character models, body parts, gear and clothes via Collada. As animations now work in general, supporting those should be a matter of connecting a few dots.

Another thing I noticed about Collada is that transparency is done via alpha blending by default. Collada has profiles for various modes, and OSG implements PROFILE_COMMON, which the Better Collada Exporter also relies on. Alpha testing on the other hand is supported only by PROFILE_GLES, and supporting that would require a hefty amount of work, both for the exporter and OSG. Alternative would be to support alpha testing via Collada extras, but while Collada spec allows it, it doesn't seem like the default way to set up alpha testing.

To see how OpenMW does it, I checked nifloader. NiAlphaProperty bit 9 sets alpha testing true/false. When true, OpenMW sets osg::AlphaFunc(ComparisonFunction e.g. GL_NEVER/GL_ALWAYS read from NiAlphaProperty bits 10-12 and value 0...1 for alpha treshold. This information should be set by Blender's Collada exporter or OSG, but what is the correct GL_flag there? If there's no single answer, how would Blender exporter know what it should be? Also, there's osg::BlendFunc for alpha blending, so what would happen if BlendFunc and AlphaFunc are both used - are there situations when it should be possible?

Then recently, there's also something called alpha-to-coverage, which relates to alpha testing, but in case OpenMW supports that, does it require extra steps from collada support?
User avatar
AnyOldName3
Posts: 2668
Joined: 26 Nov 2015, 03:25

Re: OpenGEX as .Nif alternative for OpenMW

Post by AnyOldName3 »

Alpha testing, controlled via GL_ALPHA_TEST and glAlphaFunc, or osg::AlphaFunc, lets you set a comparison function that works on the final fragment alpha to conditionally discard or keep the fragment. Alpha blending, controlled via GL_BLEND and glBlendFunc or glBlendFuncSeparate, or osg::BlendFunc, lets you mix the final fragment colour with the colour that's already in the framebuffer. I know Blender supports both as I've used both in Blender before, but it was before the Pricipalled BRDF was a thing and when it wasn't necessarily physically-based by default, so the buttons have probably been moved and the names changed. Blending might be called transparency or translucency, and testing might be called cutout or punchthrough alpha, for example. In theory, the Collada exporter should support either depending on how you've set up your model.

As for using both at the same time, back in the olden days, before early Z testing and tiled renderers existed, it could be useful to have testing on with a low threshold as a way of skipping blending, but these days, testing's actually more expensive than blending, so there's not much point having both on for one draw call. There's nothing on a technical level preventing it, though.

One thing to note is that correct alpha blending requires everything behind a fragment to have already been drawn before the fragment is, so alpha-blended stuff usually gets depth-sorted before it's sent to the GPU. This incurs a CPU cost for actually doing the sorting, and prevents the optimiser and the object paging system from merging similar TriShapes into one draw call. That's why MOP changes trees from blending to testing - even though the testing's more expensive than the blending, the extra draw calls and CPU work are even more expensive than that.

Alpha to coverage basically lets you use the alpha of a fragment to control MSAA, so, for example, if you set the alpha to 50%, 50% of the samples in the pixel get covered by the fragment and 50% don't. We can use this to antialias alpha tested stuff by making it so that if the alpha threshold gets crossed part way through a fragment, that fragment only covers some of the samples in its pixel.
Post Reply