[Elisha KIng]

OpenMW is an attempt to reimplement the popular role playing game Morrowind. It aims to be a fully playable, open source implementation of the game. You must own Morrowind to use OpenMW.

To give you a better idea of what this project is about, here are some of the aims for the future of OpenMW:

* be a full featured reimplementation of Morrowind
* run natively on Windows, Linux and MacOS X
* support all existing content, including Tribunal, Bloodmoon and all user created mods
* allow much greater modability: change game rules, create new spell effects, etc through scripting.
* fix system design bugs, like the "dirty" GMST entries in mods, and the savegame "doubling" problem
* improve the interface and journal system
* improve graphics to use more modern hardware
* (possibly) improve game mechanics, physics, combat and AI
* (possibly) support multiplayer at some point

http://www.gamesas.com/bgsforums/index.php?showuser=468902
http://openmw.sourceforge.net/jaws/
http://openmw.sourceforge.net/jaws/index.php/photos/album/1
http://www.gamesas.com/bgsforums/index.php?showtopic=963392
http://groups.google.com/group/openmw
http://www.moddb.com/mods/openmw

And a bonus http://freegamer.blogspot.com/2009/09/openmw-interview-with-nicolay-korslund.html

Faq:

Q: When will this come out?
A: Whenever it's done, don't expect it for a while though

Q: Will this be backwards compatible with all Morrowind mods?
A: That's the plan, though some mods that rely on weird scripts or third party programs might not be supported

Q: Wouldn't this be awesome, put in pleeease, it would make the game so much better!
A: The goal of this project is to support Morrowind with expansions and mod support, making the game better will have to wait until after the initial project is done

Q: Will my save game be compatible with this?
A: Probably. But until there's an actual, working way to port Morrowind save games over to OpenMW there's no way to be sure.

Q: Morrowind is ugly, how will the graphics be improved?
A: At the very least the rendering engine will be better, better lighting and distant land is already in and other shiny things should be forthcoming. However there is neither a plan nor a desire to improve textures, meshes, or animations.

Q: Will this work well with mods already created?
A: Most definitely yes! Not only should the game theoretically crash less, but mods should be easier to switch around, activate, deactivate, and ect.

Q: Will this allow new types of mods to be created?
A: Yes, with a new graphics engine, scripting language, and being fundamentally built on open source tools OpenMW should allow a wide new variety of mods to be created.

Q: Will this have a new construction set?
A: Possibly, the main goal however is to produce a running game

Q: I want to report a error, what do I do?
A: You can post about it here on the forums, or possibly here: http://bugs.snaptoad.com/?project=2

Lastly, if you have an idea for how to improve Morrowind, go ahead and post it. Also, if you think you can help with the project, please say so.

[Anna S]

I can't see Occlusion Culling being worth it overall. It may be worth a look, but from what other people have said if you do it on hardware it is asynchronous. Meaning if you move the camera fast, you could get object popup and Ogre doesn't have a plugin, so development time is long.

I think reducing batch count would be far more worth while. Last time I checked I ended up with something like 1.5k for Balmora (And that was without the 100 terrain adds atm)

[Siobhan Thompson]

I can't see Occlusion Culling being worth it overall. It may be worth a look, but from what other people have said if you do it on hardware it is asynchronous. Meaning if you move the camera fast, you could get object popup and Ogre doesn't have a plugin, so development time is long.

You could use portals and anti-portals from the PCZ (Portal Connected Zone) Scene Manager. You need to pre-compute potentially visible sets (PVS) for that to work though, meaning you'll run into trouble with large statics that can be 'disabled' in the game world, such as the three strongholds for the great houses. You'd either have to precompute a PVS for all possible combinations, or you'd need to figure out how to 'merge' one PVS into the other.

This can run as a background thread when large geometry becomes 'enabled' and pops into the game world, because then the PVS shrinks: you'd just be rendering 'too much' until the background thread finishes and delivers an updated PVS. However, running this on a background thread would fail when large geometry that affects the PVS is 'disabled': the PVS could possibly increase and until the background thread would finish updating, you'd potentially not render everything that should be visible. In the best case that would lead to awkward distant pop up after the background thread finishes. In the worst case what pops up with a delay may be geometry that is arbitrarily close to the player's viewpoint. For example: behind a wall of stone rubble that suddenly collapses to reveal a monstrous creature behind, leaving something 'invisible' to maul the player until it 'pops up'.



Maybe you should invest in finding out how to do progresssive LOD instead, like the Croteam's Serious engine did with Serious Sam. They managed to push ungodly amounts of enemies and great distant views on much less powerful hardware by dynamically scaling back geometry to a point where the polycount became greatly reduced on complex objects far off in the distance, but not affect the perceived image quality. Because geometry was scaled back dynamically, rather than in several hard levels of LOD, you also didn't get the ugly LOD increase/decrease 'pop' on objects.

With hardware that supports DX10 or OpenGL 3.0 geometry shaders, you could possibly do the dynamic LOD scale back blazingly fast in parallel on the GPU.

I think reducing batch count would be far more worth while. Last time I checked I ended up with something like 1.5k for Balmora (And that was without the 100 terrain adds atm)

1.5k batches for Balmora makes me think that game world statics are not compiled into static geometry. Each seperate mesh in Ogre is rendered as a seperate batch, iirc, unless you explicitly merge all of it into a piece of static geometry. You should probably take every static instance of the same nif into one static geometry object. Just counting the walls in Balmora alone, this could save massive amounts on your batch count.

Same issue as with the PVS though: you'd need to precompute static geometry, which takes time. Then again: you probably aren't going to disable individual wall elements and such, so you can probably figure out some way to precompute all needed combinations of objects into static geometry during cell load and keep the different versions in memory as alternative meshes to plug into the scene manager's scene graph when necessary. In this case though, you would only have a portion of lost FPS while the static geometry is 'unbundled' back into components, altered and rebuilt on the background thread, rather than popup artifacts.



(PS: Told you in the previous thread I'd give some input, didn't I. )

[Becky Cox]

You could use portals and anti-portals from the PCZ (Portal Connected Zone) Scene Manager. You need to pre-compute potentially visible sets (PVS) for that to work though, meaning you'll run into trouble with large statics that can be 'disabled' in the game world, such as the three strongholds for the great houses. You'd either have to precompute a PVS for all possible combinations, or you'd need to figure out how to 'merge' one PVS into the other.

I have been thinking about doing something like this for the landscape. As we pregen landscape data, I am thinking that it might be good to generate the ridges and the valleys. If you got a decent data structure, you could wipe out huge amounts of distant objects for the price of a couple of vector calculations. I would want to try and do it in the scene manager rather than doing culling twice though. People need to tell me what scene manager we are going to use (I think we are using one based on octree culling atm).
It is the only good way of being able to render the exterior world using a better culling method that I can see, and I am not even sure if it is possible to do well.

Although PLSM did something like this. I may go and dig out the code at some point. See if I can find some papers. I am having issues (;)) with Haskell at present, but I will get back to messy impure languages at some point.


I never had any problem with frames in any exterior except Mournhold Expanded back on a really old computer, which was why I wans't that bothered (Plus, when I think Occlusion Culling, I think of the really accurate methods)

This can run as a background thread when large geometry becomes 'enabled' and pops into the game world, because then the PVS shrinks: you'd just be rendering 'too much' until the background thread finishes and delivers an updated PVS. However, running this on a background thread would fail when large geometry that affects the PVS is 'disabled': the PVS could possibly increase and until the background thread would finish updating, you'd potentially not render everything that should be visible. In the best case that would lead to awkward distant pop up after the background thread finishes. In the worst case what pops up with a delay may be geometry that is arbitrarily close to the player's viewpoint. For example: behind a wall of stone rubble that suddenly collapses to reveal a monstrous creature behind, leaving something 'invisible' to maul the player until it 'pops up'.

For interiors, we may be able to grab the basic room structure from the AI. I don't know how AI is going to be implemented atm, but I have seen implementations where the cell is divided into rectangular blocks and the AI is done from there (in more detail when the npc reaches that block). (I am not sure if there is any other good way of doing it)
The downside is that the rendering then depends on the ai

The upside is we don't have to do much processing, as the AI should be able to cope with the wall vanishing, as when when an object is disabled or enabled, you would need to flag all nearby boxes as needing updating

Maybe you should invest in finding out how to do progresssive LOD instead, like the Croteam's Serious engine did with Serious Sam. They managed to push ungodly amounts of enemies and great distant views on much less powerful hardware by dynamically scaling back geometry to a point where the polycount became greatly reduced on complex objects far off in the distance, but not affect the perceived image quality. Because geometry was scaled back dynamically, rather than in several hard levels of LOD, you also didn't get the ugly LOD increase/decrease 'pop' on objects.

Getting rid of the pop requires vertex shaders to do well. Uploading the index buffers every couple of fames doesn't sound good imho.
I am not sure how much polygons are worth worrying about. I was fairly sure that the GPU could render fast. Having two lod levels may be a good idea if we are going for distant statics though.

In other words, it could be good

1.5k batches for Balmora makes me think that game world statics are not compiled into static geometry. Each seperate mesh in Ogre is rendered as a seperate batch, iirc, unless you explicitly merge all of it into a piece of static geometry. You should probably take every static instance of the same nif into one static geometry object. Just counting the walls in Balmora alone, this could save massive amounts on your batch count.

Yeah, I know. If the meshes are built right, you can merge sub meshes that have the same texture (and there are quite a large amount. The number of exterior halua(sp?) textures is under 20 I think) as it doesn't matter about the mesh itself. That 1.5k was on a old engine. As you mention though, it is quite expensive to setup.
If you wanted to batch objects that are the same mesh, I don't think that would be costly at all, as you would just need to hack the scene manager a bit to group meshes. Of course, the downside is you lose due to culling, but IMO taking the load of the CPU is the important bit

[Melung Chan]

I have been thinking about doing something like this for the landscape. As we pregen landscape data, I am thinking that it might be good to generate the ridges and the valleys. If you got a decent data structure, you could wipe out huge amounts of distant objects for the price of a couple of vector calculations. I would want to try and do it in the scene manager rather than doing culling twice though. People need to tell me what scene manager we are going to use (I think we are using one based on octree culling atm).
It is the only good way of being able to render the exterior world using a better culling method that I can see, and I am not even sure if it is possible to do well.

You could try something like what's done in "Voxel column culling: Occlusion culling for large terrain models", by Zaugg and Egbert. If you can manage to compute in what voxel(s) of their columns-based algorithm each piece of static geometry in the world resides, you can also use this to cull large objects sitting on your terrain (though it only culls by terrain, not other large objects).

If you wanted to batch objects that are the same mesh, I don't think that would be costly at all, as you would just need to hack the scene manager a bit to group meshes. Of course, the downside is you lose due to culling, but IMO taking the load of the CPU is the important bit

You could retain some kind of hierarchical structure of various different static geometry (sub)sets going with your culling algorithm, then redistribute and rebuild static geometry on a background thread when that structure becomes fragmented enough.

[Sudah mati ini Keparat]

You could try something like what's done in "Voxel column culling: Occlusion culling for large terrain models", by Zaugg and Egbert. If you can manage to compute in what voxel(s) of their columns-based algorithm each piece of static geometry in the world resides, you can also use this to cull large objects sitting on your terrain (though it only culls by terrain, not other large objects).

Thanks for the paper

It may be good to go and write a exterior scene manager. Maybe I will volunteer for that next.

You could retain some kind of hierarchical structure of various different static geometry (sub)sets going with your culling algorithm, then redistribute and rebuild static geometry on a background thread when that structure becomes fragmented enough.

Sounds cool. I am not sure how well (if) threading is sorted or what model it uses. It would be nice at least to have some worker threads that you could pass non-critical data processing to.

[c.o.s.m.o]

Created a ModDb Page for OpenMw, I'll give a link when the mods there approve it. Which is ok, since I'm still trying to figure out how to make sure everything is on there.

[k a t e]

Just chiming in to show my support.
However for me it is mostly the support for MW construction set for an open engine. That is just so full of win!

The videos on youtube are looking great!

Best of luck.

Programming love & cookies
Mireneye

[MatthewJontully]

is there going to be DX10 support eventually, that would be awesome .

[Manny(BAKE)]

is there going to be DX10 support eventually, that would be awesome .

Why doesn't anyone want OGL3.1 support It makes me sad.


(Almost as sad as was the letdown that was OGL3)

[Prue]

how beautifull a game look depend on artist more than tech.

dx9 compatible is enough to me.

keep up the good work.

[D LOpez]

Would a non-programmer (Like me!) have any use for this at all? Do you need any help? Testers or something?

[NEGRO]

Why doesn't anyone want OGL3.1 support It makes me sad.


(Almost as sad as was the letdown that was OGL3)

Once Gallium3D on radeon supports it, then I will want it personally... rather than in an abstract sense.

[Sheila Esmailka]

Would a non-programmer (Like me!) have any use for this at all? Do you need any help? Testers or something?

Yes, testers are required. Go http://openmw.sourceforge.net/jaws/index.php/page/download.html and download version 0.6 ... then by the time you're done testing that... 0.7 should be out with Yacoby's new exterior work and other goodies.

[Esther Fernandez]

Silly idea: would it be possible to include the ability to shift the camera (in 1st person view) to any static or other NPC? I've been playing a game where you have a spirit guide (a bird), and you send him to a perch and are then able to "look" through his eyes at the scenery. This is very useful for scouting out areas. I can see how something like that might be interesting in Morrowind? I'm not sure.

Keep up the great work! :foodndrink:

[Natalie J Webster]

Silly idea: would it be possible to include the ability to shift the camera (in 1st person view) to any static or other NPC? I've been playing a game where you have a spirit guide (a bird), and you send him to a perch and are then able to "look" through his eyes at the scenery. This is very useful for scouting out areas. I can see how something like that might be interesting in Morrowind? I'm not sure.

Keep up the great work! :foodndrink:

Maybe that specific idea wouldn't work very well, but a detachable camera would be nice, sort of like that one feature in Oblivion that you can toggle to run around without collision while your body stays in one spot.

[mimi_lys]

Maybe that specific idea wouldn't work very well, but a detachable camera would be nice, sort of like that one feature in Oblivion that you can toggle to run around without collision while your body stays in one spot.

Yeah that's pretty nice, especially for screenshot making.

You could also use TAI on NPC's to freeze their current pose.

[jennie xhx]

I look forward to the future of this (especially where all encompassing graphics
enhancements are concerned [i.e. possible use of normals and specular maps]).
Keep up the good work :thumbsup: !

Silly idea: would it be possible to include the ability to shift the camera (in 1st person view)
to any static or other NPC? I've been playing a game where you have a spirit guide (a bird),
and you send him to a perch and are then able to "look" through his eyes at the scenery.
This is very useful for scouting out areas. I can see how something like that might be
interesting in Morrowind? I'm not sure.

Keep up the great work! :foodndrink:

I love the Mark of Kri games :bolt:

[Kerri Lee]

Silly idea: would it be possible to include the ability to shift the camera (in 1st person view) to any static or other NPC? I've been playing a game where you have a spirit guide (a bird), and you send him to a perch and are then able to "look" through his eyes at the scenery. This is very useful for scouting out areas. I can see how something like that might be interesting in Morrowind? I'm not sure.

Like it - I'm pretty sure we can make this kind of camera control possible through scripting. Maybe a new 'control cliffracer' spell?

Hmm, this kind of camera control could also be used for in-game cutscenes and similar.

[Breautiful]

Ok, ModDb page is up. Compliments already, and the more people who know about the mod the better I guess.

[Daniel Lozano]

a wish:

is it possible to make the 3rd persion camera like the witcher game [shoulder camera view] ?

that looks better than orgrinal center camera view. I'm hardly use the 3rd person view in morrowind.

[Rinceoir]

a wish:

is it possible to make the 3rd persion camera like the witcher game [shoulder camera view] ?

that looks better than orgrinal center camera view. I'm hardly use the 3rd person view in morrowind.

It's like that in Fo3 too, and I do agree it looks better, but you should be able to customize the viewpoint. It'd also be cool to have an arial view like in the Diablo games, fun!

[Star Dunkels Macmillan]

Just checked out the ModDB page... looks great! Can't wait until Morrowind becomes Open Source

[Marcus Jordan]

I've got another thought or two:

The ability to put creatures into factions. In Oblivion, there was a hidden creature faction. This was useful for the following http://www.uesp.net/wiki/Oblivion:Boots_of_the_Crusader#Boots_of_the_Crusader, which placed the player character into that faction, allowing him/her to walk among the beasts without fear. I can also imagine this would be useful for any mods that may wish to re-create Battlespire, which has what appears to be several factions (though likely not implemented as such in the game) of daedra.

Secondly: the ability to add dialog (like NPC dialog) to all creatures. This, coupled with the first 'wish' I mentioned, would open the doors wide on druid-style gameplay (talk to beasts, be their allies), as well as anything involving daedra or other creatures (daedra worshipers, a Battlespire remake, necromancy, etc). Examples of critter dialog might include their own sets of rumors, background, information about the landscape, landmarks, locations, local activity (bandits, caravans, dens, lairs), etc. For the daedra, this could involve their own alliances to Daedric Princes, information about Daedric Princes and Artifact lore, their own background and history ("Why, I remember I was hurled back into the Dark Abyss by that good-for-nothing Eternal Champion! But my, what a fight it was!"). This would add a colorful, enriching aspect to the sentient daedra in the game. Dialog would also make charm and calm humanoid/beast spells more useful, in that you can calm them down and chat with them.

[Shae Munro]

Tombofsoldier asked texture makers if since they are making textures anyway. Are they going to make spectral, normal maps and I'm guess it can take parallax. So they will show up in this project.

This would of course mean editing the meshes to take the maps.

Now I'm read where Tbrick got the green light on this project at the state it was at the time. Gstaff was able to clear it legally. :celebration:

So would changing meshes so as to take these new maps cause a problem for the project.