Page 3 of 8

Re: OSG port roadmap and design plans

Posted: 24 Mar 2015, 23:10
by raevol
Let us know what you figure out! Sounds like a re-factor could be the most beneficial? You would know best though.

Re: OSG port roadmap and design plans

Posted: 25 Mar 2015, 02:13
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.

Re: OSG port roadmap and design plans

Posted: 25 Mar 2015, 02:57
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.

Re: OSG port roadmap and design plans

Posted: 26 Mar 2015, 23:05
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.

Re: OSG port roadmap and design plans

Posted: 26 Mar 2015, 23:27
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.

Re: OSG port roadmap and design plans

Posted: 27 Mar 2015, 03:13
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?

Re: OSG port roadmap and design plans

Posted: 28 Mar 2015, 02:59
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.

Re: OSG port roadmap and design plans

Posted: 29 Mar 2015, 22:16
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.

Re: OSG port roadmap and design plans

Posted: 29 Mar 2015, 22:33
by robcbwilson
Thanks for the update Scrawl, nice work!

Re: OSG port roadmap and design plans

Posted: 29 Mar 2015, 22:49
by Ascent
It sounds as if OSG is working out well. Great stuff, scrawl! :)