Long Term Planning

[lgromanowski]

Currently we have no plan beyond the current milestone. I suggest to plot at least 2-3 more milestones in advance, so we have a better idea of what is ahead of us. I would like to have a bit of input on this especially from Nico, since he has written most of the roadmap so far and he is still the project leader (despite another phase of inactivity, that hopefully soon comes to an end -- hint, hint! )

I propose the following tasks:

OpenMW 0.10 (this would be the last D-porting milestone)

- High: Bullet (probably multiple tasks)
- Medium: Finish up dialogue implementation
- Low: sort out the remaining path problems on Linux

OpenMW 0.11

- High: Rendering optimisations
- High: Sort out the cell load problems
- Medium: Allow multiple ESMs and ESPs
- Low: refactor the PlayerPos class

OpenMW 0.12

- High: fix NPC rendering
- High: implement proper character control, including camera and player character rendering
- Medium: implement animations
- Medium: implement the acrobatics skill (jumping, falling)

We can always move the Medium and Low priority tasks back and forth, if there is enough or not enough interest in doing them. The High priority tasks though should stay unchanged.

Edit: Wrote athletics skill, but meant acrobatics skill. Also removed swimming from the list, since swimming is controlled by athletics.

OpenMW 0.10 (this would be the last D-porting milestone)
- High: Bullet (probably multiple tasks)
- Medium: Finish up dialogue implementation
- Low: sort out the remaining path problems on Linux

What about Bullet?
I really, really would like it if we could abolish forever all potential problems with libraries, building, and dependencies by 0.10 or 0.11 on all platforms.

OpenMW 0.11

- High: Rendering optimisations
- High: Sort out the cell load problems
- Medium: Allow multiple ESMs and ESPs
- Low: refactor the PlayerPos class

Cell load problems? I know this may be a short list, but can you elaborate on this?

Also: How's rendering exterior cells going? I know that's something that was started and had some progress, but I'm not sure where we're at right now.

OpenMW 0.12

- High: fix NPC rendering
- High: implement proper character control, including camera and player character rendering
- Medium: implement animations
- Medium: implement the athletics skill (jumping, falling, swimming)

We may move the NPC stuff down in priority, actually, but I think it definitely should be done alongside any task for an actor / actornode

Something tells me we should, instead of spreading out problems and issues with meshes (rendering them, Physics, animations, etc.) over three versions, that we should spend one version just doing tasks related to that. What do you folks think?

What about Bullet?

Physics, collision detection, replace the Ogre raycast implementation for object activation with something that works better.

I really, really would like it if we could abolish forever all potential problems with libraries, building, and dependencies by 0.10 or 0.11 on all platforms.

Don't think this is going to happen. We need at least another library to play videos and I don't see that very high on our priority list.

Cell load problems? I know this may be a short list, but can you elaborate on this?

Okay. Here is a short recap: Currently OpenMW loads cell data (not the graphics part, just the actual data) only when a cell is rendered. But MW can access cells that are not covered by this (via scripts).
I am pretty sure by now, that MW does not load all cell data on startup. Instead it provides a couple of workaround, that allows access to other cells under very specific circumstances. IMHO this is one of the main sources of MW's flakiness. Therefore we should come up with a better implementation. I have worked out an idea by now, that does not require loading all cells at startup either, but has none of the drawbacks of MW's original implementation.

Also: How's rendering exterior cells going? I know that's something that was started and had some progress, but I'm not sure where we're at right now.

Moving through exteriors works. Objects are rendered correctly. Terrain is not yet rendered at all. Performance is slow. Moving outside of the predefined cells (i.e. swimming far away from the island) will not work properly.

Something tells me we should, instead of spreading out problems and issues with meshes (rendering them, Physics, animations, etc.) over three versions, that we should spend one version just doing tasks related to that. What do you folks think?

Absolutely not! Such a milestone would take forever. We need to keep the amount of work per milestone manageable.

Physics, collision detection, replace the Ogre raycast implementation for object activation with something that works better.

That clears that up. I think it's time we really got that thing in, because grafting it in later when we will be changing a lot of things with objects looks like a bad idea.

Don't think this is going to happen. We need at least another library to play videos and I don't see that very high on our priority list.

I wish I could say that cranking out code is more important, but there is a very real problem when no one but the people most intimate with troubleshooting builds of large projects with this particular project can actually build our project - compounded that our support for windows is seen as only an inconvenience.

I think it's very troubling that we don't seem to have a lot of our own project thought out or designed in plain sight.

Okay. Here is a short recap: Currently OpenMW loads cell data (not the graphics part, just the actual data) only when a cell is rendered. But MW can access cells that are not covered by this (via scripts).
I am pretty sure by now, that MW does not load all cell data on startup. Instead it provides a couple of workaround, that allows access to other cells under very specific circumstances. IMHO this is one of the main sources of MW's flakiness. Therefore we should come up with a better implementation. I have worked out an idea by now, that does not require loading all cells at startup either, but has none of the drawbacks of MW's original implementation.

Ahhh we're talking about all cells.

Interiors:
I wonder if there's a way we map out what data is accessed when out of cell, when ,and maybe from there we'll understand what's necessary and what's not.

Exteriors:
I think you mentioned that it load the nearest and last in some ways, although I'm not sure how quadratic mode played into all this other than drawing and loading. I think, given the opportunity here, that a look at MGE (if they'd let us look) might reveal some ideas and pitfalls we'll have with this.

Absolutely not! Such a milestone would take forever. We need to keep the amount of work per milestone manageable.

Okay - list all of those tasks - now categorize them so they can be done together and divide them in half until we have version-sized bites. Then pick.

I notice a lot of these go together, and it seems like each version we'll be going back to make changes and fix more - unless you're seeing a way around that in your roadmap that I don't? You mentioned in an optimization thread that we want to avoid coming back too often, so here's an opportunity to one-shot all the problems with our game world objects/actors and our cell rendering.

-Our program doesn't build
-Cells
-Objects (including actors)
-Easy mode (Athletics, etc. Small things that have to do more with the game than the program.)

Three large categories. Now - if we want to spread that out to prevent boredom or roadblocks, I suggest we frame our tasks in these three for some n amount of versions.

I wish I could say that cranking out code is more important, but there is a very real problem when no one but the people most intimate with troubleshooting builds of large projects with this particular project can actually build our project - compounded that our support for windows is seen as only an inconvenience.

There was never much of a problem on Linux and AFAIK the problems on Windows have mostly been sorted out. At least an intermediate coder should be able to build OpenMW on Windows without too much trouble. I don't see any problem here (at least not anymore).

Interiors:
I wonder if there's a way we map out what data is accessed when out of cell, when ,and maybe from there we'll understand what's necessary and what's not.

You are thinking to complex. Its really just a matter of preloading a minimum amount of data per cell, that is sufficient for identifying when a cell is being touched, and then (when the cell is touched) load its data entirely.

I think, given the opportunity here, that a look at MGE (if they'd let us look) might reveal some ideas and pitfalls we'll have with this.

AFAIK MGE only increases the viewing distances for cells that are loaded anyway, so this is a problem completely unrelated to what MGE is addressing.

I notice a lot of these go together, and it seems like each version we'll be going back to make changes and fix more

Yes. That is called iterative development. And it is a VERY GOOD THING (TM).

There was never much of a problem on Linux and AFAIK the problems on Windows have mostly been sorted out. At least an intermediate coder should be able to build OpenMW on Windows without too much trouble. I don't see any problem here (at least not anymore).

Whatever's been worked out remains a mystery to even me, and I've been reading the 4 threads where these problems have been discussed!

I can't imagine how disastrous it'd be if we threw the source code at the bethsoft, PES or TESNexus forums and told them to try to build it and asked them what they thought or what the results were.

I still think these problems are real until I can, speaking to someone, instruct them on what to do and have it work without failure - circumstances being normal. It's not a problem for linux developers (certain package managers notwithstanding) but for windows users, and I keep harping on window's market share, I can imagine how many good people would like to get involved but they won't have much motivation if our project doesn't even know what libraries it's using or what to do with them.

It more or less tells people: "It doesn't work". Even if that's not necessarily true. The current thread on Bethsoft shows they are rather skeptical already. Let's settle that problem and show them we'll rise above their expectations.

Anyways. I say we find a video library as part of our next milestone. Settle the library questions - we don't have to implement it. Just get it in.

You are thinking to complex. Its really just a matter of preloading a minimum amount of data per cell, that is sufficient for identifying when a cell is being touched, and then (when the cell is touched) load its data entirely.

Of course I am - I'm in applied sciences, too, ya know!

I don't immediately know what data you would think is the only important data - I haven't taken time to think about it myself(and I have a cold. ). So if we (or you) already understand what data is important and what isn't, then it's a done deal.

AFAIK MGE only increases the viewing distances for cells that are loaded anyway, so this is a problem completely unrelated to what MGE is addressing.

Well, MGE has to use DirectX to render interiors and exteriors differently, but when you throw in other things, along with recent developments including the ones in shaders- it simply increasing the clipping plane isn't a great description. I just thought it'd be worth a look to see what they are actually piping into MW because we have to accomplish the same thing.

Yes. That is called iterative development. And it is a VERY GOOD THING (TM).

This that Six Sigma thing I hear about? I got a book on that. I found it cheap for a dollar. (Score!)

I can't imagine how disastrous it'd be if we threw the source code at the bethsoft, PES or TESNexus forums and told them to try to build it and asked them what they thought or what the results were.

I don't know what PES is, but the people at the Betheda and TESNexus forums are mostly modders AFAIK. They are not supposed to build OpenMW. They get the binary.

I say we find a video library as part of our next milestone. Settle the library questions - we don't have to implement it. Just get it in.

If you want to do it, I guess nobody would try to stop you. But I do not see any purpose in burden us with an additional library before we need it.

Well, MGE has to use DirectX to render interiors and exteriors differently, but when you throw in other things, along with recent developments including the ones in shaders- it simply increasing the clipping plane isn't a great description. I just thought it'd be worth a look to see what they are actually piping into MW because we have to accomplish the same thing.

These optimisation techniques aren't black art. This is fairly standard stuff and Ogre has most of it already implemented anyway. Little point in digging through DirectX code to learn about something, that is readily available.

I have edited the wiki : great idea !

I wanted to wait on Nico's input on this. But no harm done. Its a wiki after all.

We will have to clean that up a bit eventually. Some of the task already exist in the Unplaced tasks section and should be copied over instead of making new entries. Also, some entries should be split up. But we can take care of that later.

I think your plan looks very good. The only thing I reacted to was putting rendering optimization as "high" - do you mean exterior cells? At least for interiors I don't see that there is a problem, and in any case I wouldn't put any optimization this high up on the list unless performance is really atrocious.

Other than that, as I said, this is a great plan. You've more or less summed up all the remaining major parts that need to be done on the core engine, before we start on pure gameplay work.

There shouldn't be much difference between exterior and interior optimisation. We can use the same techniques.

And yes, it is an problem. I have fairly high-end hardware and currently on my box the exteriors don't work totally smooth. We have to consider, that we will also have to add terrain which will slow it down more. It should still run somewhat acceptable on my box, but I would expect testing to become very painful for people with lesser hardware.

I haven't tested exteriors that much yet before now, but doing so I see what you mean. My hardware isn't exactly great, and the FPS is pretty crappy in exteriors. On the plus side, that means I'll have enough data to profile it properly.