OSG port roadmap and design plans

Everything about development and the OpenMW source code.
User avatar
scrawl
Posts: 2152
Joined: 18 Feb 2012, 11:51

Re: OSG port roadmap and design plans

Post by scrawl »

Sorry for the lack of updates, in fact there was nothing to write about, I've been busy moving to a new place in the last weeks, and decided to focus what little time I had on polishing the existing OpenMW. Now that's all wrapped up, we can go full speed again. I just pushed some new commits, most notably the new virtual file system, and particles.

I've been thinking some more about this part:
Creating multiple instances of the same NIF file should be overhauled. For static meshes we can just share the entire scene graph, since OSG allows multiple parents for a node. Currently we have to parse the file again for every instance that is created.
Should not be too difficult as OSG defines copy construction operators for its scene graph, with detailed control over Deep or Shallow copies for each component. We want a shallow copy, except for anything that has a controller attached to it.
One problem would be that Controllers store a pointer to the target node, which would become invalid. We can solve this by turning controllers into nodes, attached as a child of their target.
When that's done, we can create instances of any .nif (be it static or dynamic) without having to convert it again. Is that much faster? I'm not sure. Either way, I'm leaning toward this approach because it requires almost no code and we will have resource sharing (e.g. for Geometry) built in automatically due to the shallow copy.
Render the loading screen in a separate thread
I *think* that's already done, or rather, not an issue in the first place. With the default threading mode, osgViewer uses a separate graphics thread for OpenGL calls, which goes on drawing (and swapping) while the main thread is already running the next frame's update (or in the case of the loading screen, loading stuff). I bumped into this when attempting to change a StateSet from a key event handler, which crashed sometimes when the graphics thread had not submitted that StateSet for drawing yet. (FWIW, that was easily fixable by setting the StateSet's DataVariance to DYNAMIC, as explained in Robert's post)
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:I've been busy moving to a new place in the last weeks
Congrats! Hope the new place is good, moving is always an adventure.
User avatar
Mistahtokyo
Posts: 139
Joined: 07 Sep 2013, 18:31

Re: OSG port roadmap and design plans

Post by Mistahtokyo »

Thank you for the update! Any info regarding the OSG port is welcome. Speaking of, would you mind updating the first post's status/es? It's nice to get an overall sense of what's in progress and what's done or yet to be done.
User avatar
scrawl
Posts: 2152
Joined: 18 Feb 2012, 11:51

Re: OSG port roadmap and design plans

Post by scrawl »

Should not be too difficult as OSG defines copy construction operators for its scene graph, with detailed control over Deep or Shallow copies for each component. We want a shallow copy, except for anything that has a controller attached to it.
One problem would be that Controllers store a pointer to the target node, which would become invalid. We can solve this by turning controllers into nodes, attached as a child of their target.
Found a much better solution, controllers should be turned into osg UpdateCallbacks, which can be set on anything we need to control (StateSets, Nodes, or Drawables), and will be run when the scene graph is traversed. That also means we no longer need to do things like

Code: Select all

        for (unsigned int i=0; i<controllers.size(); ++i)
            controllers[i].update();
in the frame update for every model we've created - the scenegraph will take care of it automatically.

Each object can have one callback set on it, but each callback can also have a "nested" callback... so you can chain them together, just like it's done in NIFs for chains of controllers.

Not sure why I didn't do it that way to begin with. I guess from the years of Ogre usage, I'm still used to the scenegraph standing in my way, rather than actually doing useful work. :)

I have to say I'm deeply impressed so far with OSG's level of flexibility, also the more I work with it, the more parallels I can find to how Gamebryo / NIFs work... it's getting almost spooky.
User avatar
raevol
Posts: 3093
Joined: 07 Aug 2011, 01:12
Location: Caldera

Re: OSG port roadmap and design plans

Post by raevol »

Very exciting!!
HiPhish
Posts: 323
Joined: 02 Jul 2012, 08:36

Re: OSG port roadmap and design plans

Post by HiPhish »

I'm just curious here, but can you give an estimate on how long it will take until we can see OSG be working in OpenMW? Like one month, or two, or six or twelve?
User avatar
scrawl
Posts: 2152
Joined: 18 Feb 2012, 11:51

Re: OSG port roadmap and design plans

Post by scrawl »

People have asked for more updates, so I created a public to-do list.
This is by no means a complete roadmap (refer to this thread or the issue tracker). Instead, it should give you an idea what I'm working on currently and in the near future.
User avatar
ElderTroll
Posts: 499
Joined: 25 Jan 2012, 07:01

Re: OSG port roadmap and design plans

Post by ElderTroll »

Thank you, Scrawl.I like Trello a lot and use it for work. Keep up the awesome work and we'll keep up the support! If we only had a second Scrawl for the OpenMW-OpenCS. Well four Scrawls for the engine and one or two for OpenCS. Plus zini, Chris, and all the other contributors.
User avatar
dEnigma
Posts: 248
Joined: 24 Nov 2013, 21:24
Location: Hla Oad

Re: OSG port roadmap and design plans

Post by dEnigma »

scrawl wrote:People have asked for more updates, so I created a public to-do list.
This is by no means a complete roadmap (refer to this thread or the issue tracker). Instead, it should give you an idea what I'm working on currently and in the near future.
The "Post 1.0" list certainly is interesting :mrgreen:
Nice to have an overview of what you're working on.
User avatar
scrawl
Posts: 2152
Joined: 18 Feb 2012, 11:51

Re: OSG port roadmap and design plans

Post by scrawl »

Unexpected problems with assembling skinned bodyparts / equipment parts.
Image
I thought that was pretty close, but then I tried Better Bodies and all hell breaks loose.
The old code was simply loading the parts into a new skeleton and then manually updating that skeleton's bones to match the master skeleton, every frame. I wanted to get rid of this and load the parts directly onto the master skeleton instead. Judging by the "showscenegraph" command, that is also what the original game is doing.
Problem is, it's incompatible with the current skinning code, which pre-transforms the vertices using the initial bone transforms to get bind position correct. The "slave" skeletons have the same skeleton hierarchy as the master skeleton, but can have different initial bone transforms. Only slightly visible with the default assets, but all the more visible with Better Bodies.
I have two possible solutions in mind:
- Refactor the skinning code to get rid of the pre-transform if possible
- Pre-transform using the master skeleton instead of the part skeleton
If all that fails, we can still just do it like in the old code, i.e. keep a separate skeleton, but I would like to avoid that for the sake of efficiency.
Post Reply