Terrain rendering

Everything about development and the OpenMW source code.
User avatar
Site Admin
Posts: 1193
Joined: 05 Aug 2011, 22:21
Location: Wroclaw, Poland

Terrain rendering

Post by lgromanowski » 15 Aug 2011, 09:34

gus wrote: Okay, as i have finished with bullet, i can try to do the Terrain rendering task, if nobody wants to take it.
Could somebody just sum up what's need to be done/ what's already done? That would save me a lot of time ;)

Zini wrote: 1. Nico did already some work on this feature. The first task would be to see how far he has come.

Check the ESM loader first. The records we are interested in are LTEX and LAND (see components/esm).

2. Then we need to decide how to implement the rendering. Here we have basically two options:

a) Add a custom terrain system. This means transforming the ESM records into geometry and texture.
Hard and a lot of work. You would need to implement all those niceties like LOD and culling (required to get a decent performance). Maybe you could have a look into the old Ogre terrain scene manager or the terrain implementation in the previous D version of OpenMW. These should give you some ideas.

b) Use the Ogre Terrain component.
Hard and slightly less work. The documentation of the terrain component is lacking and it is not so easy to use.

I am strongly favouring b), because this way we can leech all the improvements that the Ogre community is doing to the terrain in future version of Ogre. Also, we would get things like LOD and culling for free.

But since you are going to do the implementation, it is your decision.

3. Implement the terrain solution we decided about in 2.

Once we got to this point I can give you some additional hints.
Greendogo wrote: Any progress on this?
Zini wrote: Probably not, since gus is still busy with ironing out the physics code.
corristo wrote: I'll take this task.

If somebody wants too - let me know :)

Now I'm looking at code and trying to figure out where terrain rendering should be placed.

Also reading Ogre Terrain System documentation.

I'm prefer option b)
Zini wrote: There is a terrain component (components/terrain) that deals with the terrain records, I believe.

The actual rendering implementation would be best placed in apps/opoenmw/mwrender/mwscene and apps/openmw/mwrender/exterior.
corristo wrote: Experimenting with Ogre terrain system.
Fortunately size of cell's heightmap is 2^n+1 (65), so Ogre can work with heightmaps like this.

I'm in trouble with materials, looks like terrain is loaded, but not shown because no material associated with it, so I think I should figure out how original MW textures terrain and do the same. If somebody knows original MW terrain texturing behavior, let me know.
Zini wrote: A cell's terrain texture is made up of a regular grid of smaller textures. That is all I know about MW terrain texturing:
sir_herrbatka wrote: You may (or not, not quite sure about it) be intrested in project aedra, old openmw and crystal scrolls. All of those projects already implented terrain rendering.
Greendogo wrote: Any progress here?
corristo wrote: No, not so much free time :(
I'll try to do something next week.
Cepheid wrote: I've been playing around with terrain rendering on my own time, unfortunately the code is in C/C++ and D3D, and so far, all I've managed to get done is the ability to load and render individual cells. No textures, yet. Also don't know if there's height scaling in effect or not, so it's hard to tell. Currently I'm dividing the height values by 8 so I can get something visible to look at.

As for why I was doing it, boredom mostly, and to see if I could do it. Also, it's not a true height map. Based on what little documentation I have, it's effectively a map starting at a specific height, and each pixel along the X axis of the "height map image" represents the amount of change for a given vertex along that axis from the previous vertex. It's this particular feature that allows for maintaining reasonable quality while allowing for height maps of insanely high heights.
Cepheid wrote: I was playing around with the DATA Sub Record of the LAND Records, and I'm not sure if this is covered anywhere, but it appears to be a bit field of some sort.

Going from Right To Left, the bits are:

BIT 0 - Height Map Usage
BIT 1 - Colour Usage
BIT 2 - Texture Usage

Still looking at the higher bits, but this appears to be all it's for. I'm looking for patterns in the available data and the DATA field, to see if there's any correlation.

Regardless, changing it from 7 or any other value it's set to is *NOT* a good idea. It's probably set to that value for a good reason.

EDIT: Also, the WNAM data has to do with the zoomed out world map. Change it to all FF bytes, and it'll appear perfectly blue. Change it to alternating FF and 00, and it's a checkerboard. Dunno the colour format though. Working on it.

EDIT #2: Palette based, probably. The entire WNAM sub record is a 9x9 grid of pixels for that cell. Since there's one byte per pixel, one can conclude that it's palette based. The alternative is they somehow packed a colour format into it(3-4-3?). Problem is, I don't want to go through that, since testing it requires I go through the entire create character process time and time again.

EDIT #3: Last unknown field(The 2-byte value after the height map data) in the VHGT records have a common trait. All edge cells on the map have the value zero. All others have the value 166. Possible bit field? Need to test. I need to write up a quick land editor that can allow me to change these fields first, though. I'll have said editor out over the weekend, with source code available. I know it's re-inventing the wheel with the other tools out there, but I want one with a specific UI for myself, for easy manipulation of this data.
Cepheid wrote: I got slightly bored at one point, and took what I had written thus far to display this. It's the WNAM subrecord data in the LAND records, using the byte values as the RGB values of the pixel colour.


Yeah, I know it's ImageShack. At the moment I got nowhere else to post it.

Also, note: It's upside down. I know. It's cause of how Windows stores and renders bitmaps.

Darker area is the land, bright areas are the water. If I had the palette used by the game, I could use it to render the map as if it were in-game.

Black squares are cells that exist, but have nothing in them. Anything else, with exception to the text, is non-existent data. IE: What's shown is what's stored in the Morrowind.esm file. Note, this does NOT include Tribunal or Bloodmoon.

More as I design and implement the user interface for the tool. I spent most of the evening working on loading up the data. I might keep this particular view mode implemented as a separate tab or sub-tool.

Anyways, I'm going to bed. It's 4:40 AM.
corristo wrote: Tanks for all this info!
I found heightmap recalculation code in CrystalScrolls sources.
sir_herrbatka wrote: You can't imagine how happy to help I am ;-)
Cepheid wrote: I've done some further research on those VHGT unknown values. Crystal Scrolls ignores it. And judging from the overall layout of ESM/ESP files in that their data is always aligned to four bytes, it's likely that the format is actually:

4 Bytes - Float - Base Height
4225 Bytes - Signed Byte - 65x65 Bitmap Image, as described in Crystal Scrolls and any relevant ESM documentation.
3 Bytes - Byte - Unknown, probably padding.

In other words, the order is changed slightly(The base height float, followed immediately by the heightmap data, then three unknown bytes, rather than base height, one unknown byte, heightmap data, and then two unknown bytes.) from the ESM documentation.

Ultimately, this means that the unknown are those last 3 bytes. They may just be padding.

Edit: Insomniaaaaaaaaa....!

Edit #2: No... Padding is too easy. I just graphed out the cells that don't have those 3 bytes set to zero, and there's quite a number of them. They all appear to be out in the ocean, though. They aren't consistent either, and a majority of them are along the southern edge of the game world.

The bytes are also identical among all of these cells. They read as 00 A6 EF, or in binary: 0000 0000 1010 0110 1110 1111. These are in little endian.

... They better not be bit fields, that's sixteen different bits to turn on and off, and test extensively to determine their effects, if any.
ap0 wrote: You can try to look at the aedra project : the terrain rendering works well.
corristo wrote: yeah, I'll try, already downloaded it.
corristo wrote: Sorry, no progress yet, writing my graduate work now :(
Greendogo wrote: Any progress? How goes the graduate work?
Zini wrote: I haven't seen any activity on github and as far as I remember corristo hasn't shown up on the forum for a while. I am pretty sure that this task is still dormant.
raevol wrote: I feel like I need to teach myself C and do this myself. :(
Zini wrote: I guess you mean C++. C wouldn't do you any good for OpenMW.
ShinAli wrote: I was just going to post about how I have some experience in terrain collision detection with bullet (and some minor terrain rendering work; mostly just reading an image file and using it as a height map). I could look into terrain rendering as well but I can't really guarantee anything.

I remember the big deal with Bullet was that btHeightfield shape wasn't creating the right collision shape with all the heightmap data I've passed in (maybe it orders the heightmap data differently?), so I've went ahead and used btBvhTriangleShape, which is pretty slow to create (at least on a 513x513 terrain). I feel like it was a waste as it's not really so expensive to calculate the height at any given position on the terrain, which, aside from normals, all what you really need.

Is there any high level overview of the project that explains the renderer in more detail, as well as any of the scene manager components?
Zini wrote: Collision with terrain is still far off. First we need terrain. ;)

We have source documentation via doxygen, but we currently lack any high level documentation. We have a couple of WIP pages on the wiki, but they are not very far yet.

http://openmw.org/wiki/index.php?title= ... _Reference

Renderer and scene manager are standard components from the OGRE library.
ShinAli wrote: I'll look into it, then, see what I can do.
corristo wrote: Hi guys, I'm still writing my graduation work.

ShinAll, feel free to use my code on github and ask questions.
ShinAli wrote: Have been settling in a new job, but finally got my build going under Windows, thanks to whomever that provided those prebuilt binaries.

Unfortunately the performance seems to be real awful under Windows. It's nothing too detrimental yet, it doesn't change the way how the code would work.

Should I set up a Linux install instead? I remember building it under Linux awhile back and it seemed to have ran just fine then.
Zini wrote: While it is generally a good idea to use Linux instead of Windows, I don't think it will help you any here. OpenMW should not be any faster on Linux than on Windows. If your Windows build is slower, than something went wrong. You are running in release mode, right?
ShinAli wrote: I'll check when I get home, though it should be.
ShinAli wrote: Yeah, it was in Debug mode, but can't into Release as the prebuilt binaries appear to be just Debug binaries as well.

Should Debug mode be able to slow it down so much? Windows is getting more and more annoying as a dev environment.

I'll try to setup the environment by myself again. Don't have the space to install Linux right now.

EDIT: I set it up right this time, release runs.
gus wrote:
Should Debug mode be able to slow it down so much? Windows is getting more and more annoying as a dev environment.
Debug mode can be more than 10x slower than release mode. And it's the same under windows and linux.
ShinAli wrote: I was basing experiences on the 3D engine that I've written, which I've always run in debug mode. I know that debug binaries lose some performance but I didn't think it'd be so bad with Ogre. Of course Ogre is infinitely more complex than what I've written.
Greendogo wrote: Hey ShinAll, got any progress on this?
Zini wrote: Apparently not.

I was planning to give the people who were supposed to work on Terrain a bit more time, before I pull the plug.

But thinking about it, the mwrender refactoring is blocking just too many tasks. Which is bad. Very bad. We are running quickly out of tasks, that I can easily assign to people.

There are a few roadblock-tasks, each blocking a larger number of tasks from being taken. And the mwrender refactoring is one of the biggest roadblocks now (this is why I was originally not planning to do any mwrender refactoring at all, despite the suboptimal state of this subsystem).

I think it would be better to move Terrain to 0.13.0 and do the refactoring in 0.12.0. I won't have time to do it myself, but I should be able to write a short design document over the next couple of days.
Star-Demon wrote:
Zini wrote:I think it would be better to move Terrain to 0.13.0 and do the refactoring in 0.12.0. I won't have time to do it myself, but I should be able to write a short design document over the next couple of days.
*emperor voice* "Goooooooodddd....."
Zini wrote: Yes, yes, we all know what you think about this topic.

Just a warning, with 4 active GUI tasks that each will require my assistance to some degree, I won't be able to keep the promised time scale. Better make it a week or two instead of a couple of days.
Star-Demon wrote:
Zini wrote:Yes, yes, we all know what you think about this topic.
It's nice having more than one person with knowledge of how the program works and how it's supposed to work. I am emphatic about you sharing your design because I figure you'd want to spare yourself a lot of posts like that one and be more satisfied with everyone's future work.

You said you know this - so are you too busy or have no interest?

Okay - I've edited this enough times.
Zini wrote:
It's nice having more than one person with knowledge of how the program works and how it's supposed to work
That is exactly the point. You are misunderstanding the situation here. For the new mwrender design, currently no one knows how it works. I can't pull a complete design out of my hat. Developing something at this complexity level is hard work and time consuming.

Same for quite a few other parts of OpenMW. When I took it over it came with no manual. If we consider the commit statistics on ohloh as a good measure (which I actually don't, but let's put that aside for now), I have written about 40% of OpenMW. These 40% I obviously know. The rest, not so much. With some parts I have worked (and know somewhat reasonably well now), others I haven't touched at all.

If I were going to write a complete design spec for every part of OpenMW, that would require a huge load of research. And then there are obviously the parts of OpenMW that simply haven't been fully designed yet (neither by Nico nor by me). There are still a couple of open problems we need to think about.

I don't know how you came to the conclusion that I had a complete plan of everything in my head. But I can assure you, that is not the case.

Having everything designed and laid out in advance is an ideal world scenario, that is completely unrealistic with our resources and situation. It will never happen.
gus wrote: As I've worked quiet a lot with the mwRender during the optimization work, i understand (more or less^^) how it works. So when the design document will be done, i can try to implement it.

PS: I've exams right now, and they last two weeks, so you can take your time.

Edit: but maybe we should discuss this in the appropriate thread?
Zini wrote: I was going to ask you anyway to take the task (besides the rendering it will also involve moving the physics code around a bit). I will open a new thread, once I have some material.
best regards,