OSG port roadmap and design plans

Everything about development and the OpenMW source code.
User avatar
raevol
Posts: 3093
Joined: 07 Aug 2011, 01:12
Location: Caldera

Re: OSG port roadmap and design plans

Post by raevol »

Let us know what you figure out! Sounds like a re-factor could be the most beneficial? You would know best though.
Chris
Posts: 1626
Joined: 04 Sep 2011, 08:33

Re: OSG port roadmap and design plans

Post by Chris »

scrawl wrote:- Refactor the skinning code to get rid of the pre-transform if possible
This is certainly my suggestion. We should be able to use the vertex data as-is, and I've never understood how the pre-transform actually produced working results with Ogre's skeleton system.
User avatar
scrawl
Posts: 2152
Joined: 18 Feb 2012, 11:51

Re: OSG port roadmap and design plans

Post by scrawl »

- Pre-transform using the master skeleton instead of the part skeleton
I've got this approach implemented, though I'm not so happy that it requires loading the NIF files once for every skeleton they will be attached to. Don't think I'll end up using this code.
scrawl wrote:
- Refactor the skinning code to get rid of the pre-transform if possible
This is certainly my suggestion. We should be able to use the vertex data as-is, and I've never understood how the pre-transform actually produced working results with Ogre's skeleton system.
Starting to think that's impossible in the given constraints. One of the pre-transform components (NiSkinData.BoneInfo.trafo), which I assume is somehow related to the bind matrix, can be specified per TriShape rather than per bone, as OSG and Ogre would have it. There can be multiple skinned trishapes on the same skeleton, needing different bind matrices each. But with osgAnimation we can only specify one bind matrix per bone. I don't see how that would work.
I guess a clean solution would have to use all custom nodes, not based on osgAnimation.
User avatar
scrawl
Posts: 2152
Joined: 18 Feb 2012, 11:51

Re: OSG port roadmap and design plans

Post by scrawl »

Finally a solution for the infamous bounding box problems ("invisible cliff racers") :)

https://www.youtube.com/watch?v=JFgQs2l ... e=youtu.be

I'm using osg's ComputeBoundingBoxCallback to update the bounding box every frame. For each bone influence, NiSkinData stores a bounding sphere, describing the maximum offset of any given vertex from that bone. The callback transforms the spheres by their bone matrix, then merge all spheres into an axis aligned bounding box.
User avatar
raevol
Posts: 3093
Joined: 07 Aug 2011, 01:12
Location: Caldera

Re: OSG port roadmap and design plans

Post by raevol »

scrawl wrote:Finally a solution for the infamous bounding box problems ("invisible cliff racers") :)
Hooray!!

Thanks for the video, I know it's a small thing, but it's really awesome to see your progress visually like that.
ghales
Posts: 41
Joined: 25 Jul 2014, 00:25

Re: OSG port roadmap and design plans

Post by ghales »

scrawl,

It sounds like your solution could address more than the problem with Cliff Racer and Netch corpses. Will it address the problems with collisions during animation? Such as, for example, when Wild Guar attack you, they will run up to you so close that your POV will be inside their head, resulting in some pretty weird graphics clipping.

Are you planning on keeping NPCs and creatures at the outer limit of their maximum bounding box (they way it appears they do in Morrowind), or will you move them further back if they stick some part of their anatomy forward, or will you interrupt the animation if something collides?
User avatar
Lazaroth
Posts: 220
Joined: 30 May 2012, 05:04

Re: OSG port roadmap and design plans

Post by Lazaroth »

Just a thank you to Scrawl for being such a beast, updating trello. It's really fun/interesting to watch. A tip though would be to add the link to your message footer, plus a link to your blog and perhaps to your github as well.
User avatar
scrawl
Posts: 2152
Joined: 18 Feb 2012, 11:51

Re: OSG port roadmap and design plans

Post by scrawl »

Took much longer than expected, but I think it's safe to say now the NIF loader and everything related to it is done! :)

I should write a quick summary of how awesome it is:

- Self-contained: the result of loading a NIF file is an osg::ref_ptr<Node>, nothing more. All peculiarities of the format are built into the scene graph. Frame updates are handled by UpdateCallbacks attached to the nodes, no more manual update calls are necessary. BillboardNodes no longer need be manually rotated, instead are handled by a custom Transform node that undoes the rotation part of the modelview transform, inherently supporting multiple cameras.

- Abstracted: The nif loader is hidden behind a SceneManager. Anything that loads objects (the various Animation classes in OpenMW, projectiles, effects, OpenCS, etc.) have no idea they're actually loading NIFs. Adding support for more model formats (.osg? OpenGEX?) will be easy now, instead of changing 20 unrelated pieces of code we just have to change one.

- Resource oriented: a loaded NIF scene graph behaves like a resource in that it can be shared (i.e. have multiple parents), can be used by multiple GL contexts, can be "cloned" (i.e. making an independent copy of that scene graph, with its own Controllers and Nodes, but sharing anything that can be shared, like Drawables and StateSets). Essentially this means we are doing the NIF -> OSG conversion just once for each file, rather than once for every instance of that file.
Additionally, NIF scene graphs can be loaded from a background thread, thanks to being self contained. This will be the heart of the new background loading mechanism. The original plan was to make background loading a post 1.0 enhancement, but given how easy to do that is now (literally a couple lines of code) not taking advantage of it would be a crime ;)

I also took the opportunity to add some NIF features missing from the master branch, namely StencilProperty, skeleton based bounding boxes, NiPlanarCollider, and controller extrapolation modes. Funny enough, the new loader is still less code than the old one (about 12% less now).

Next up: figure out where to start with this "OpenMW" thing. Getting that running looks like an exercise in pain and frustration. I'll probably break it up into smaller pieces and get those running first.


It sounds like your solution could address more than the problem with Cliff Racer and Netch corpses. Will it address the problems with collisions during animation? Such as, for example, when Wild Guar attack you, they will run up to you so close that your POV will be inside their head, resulting in some pretty weird graphics clipping.
Probably not. The physics controller doesn't know how to respond to a growing or shrinking bounding box, so that alone wouldn't fix the issue.
robcbwilson
Posts: 39
Joined: 04 Dec 2014, 14:15

Re: OSG port roadmap and design plans

Post by robcbwilson »

Thanks for the update Scrawl, nice work!
Ascent
Posts: 39
Joined: 28 Jun 2014, 04:32

Re: OSG port roadmap and design plans

Post by Ascent »

It sounds as if OSG is working out well. Great stuff, scrawl! :)
Post Reply