openmw.org

SquireNed wrote:The problem with adding voxel support is that it's extra functionality not in Morrowind. It might come post 1.0, but it's not something OpenMW is terribly concerned about unless it would impact the game, and the old "add a mesh and put it in" is probably simpler than going into voxel work just for that purpose.

That's just the thing, modders don't need to use voxel creation tools, they can work with the vertex based tools they are used to and leave the conversion into voxels to the engine.

asmageddon wrote:That said, marching cubes result in tons of triangles, many of which are not necessary, if you're good at 3D math, you could probably find some articles on mesh decimation and implement that. Still, with big-ish chunks, and/or not a lot of voxels used(say, only used for caves, arches, etc.), performance should not be a huge problem.

I think the engine whose blog I linked to doesn't use marching cubes. I don't know much about graphics, though, so I cannot really tell you what it's actually doing.

Antsan wrote:That's just the thing, modders don't need to use voxel creation tools, they can work with the vertex based tools they are used to and leave the conversion into voxels to the engine.

Not necessarily. There are some concerns that would need to be taken care of; remember that vertex modeling covers surfaces, and not whole objects. In addition, the conversion process needs to respect certain things, and it'd be a hell of a task to do with any high resolution at run-time. You could, theoretically, reduce this to local area voxel mapping (i.e. use large vertex surfaces and then just say "wait, use voxels here"), but unless you're adding real-time destructible terrain there is practically no benefit for doing so and the code probably gets painfully complex.

Plus, another thing to consider is that if people are already doing the vertex thing and moving it in, unless you've got some black magic in store it'll be more efficient to leave it as vertex anyway.

Ruarl wrote:Normally height maps can be expressed as a .bmp file, with a 0 - 255 Grayscale value that presents the height (the (z) axis) Thus a darker color is a low altitude and a light color is a high altitude or that is how I understand it.

One way to add overhangs, tunnels, ect. is to split the Grayscale image into a RBG image, thus you get two more values to use in the (z) axis, and use it as such:

Red channel == Normal height map as commonly used.
Blue channel == Cave/Overhang "ceiling"
Green channel == Cave/Overhang "floor"

See the embedded picture for more details...

Example.png

This is really clever and would be a good way of maintaining compatibility, I'd guess. There's still an alpha channel that can be used for something as well.

So, I thought I'd ask a simple question in this thread rather than starting a new one, will landscape seams be fixed in 1.0? It would be really great to finally not have to worry about the absurd limitation of only two textures fading between each other at a time.

Afaik they were caused by a limit to the number of ground textures per cell or something. I read that this limit was removed or is much higher in OpenMW so it shouldn't be an issue. Not sure though.

OpenMW terrain uses alpha splatting which means there will never be landscape seams.

scrawl wrote:OpenMW terrain uses alpha splatting which means there will never be landscape seams.

you are referring to textures, right? Reason I ask is because I have played around with making new land for morrowind quite a lot, and it is common to have what looks like "torn" landscape if the MW vanilla engine couldn't figure how to handle too large a jump in height from one set of points to the next.

Actually, this leads to another question, has anyone yet tried to make a land that isn't dependent on any of bethesda's esms? as in a working build empty landscape for a TC?

ST

The tearing related to height changes may actually not be based on textures but rather on models; the traditional way the terrain works is by having an immense number of points and interpolating between them-the tearing occurs because the UV mapping, which applies the texture, doesn't necessarily scale up as the distance between points does. Divinity: Original Sin is a modern game that suffers from this a ton if you're not careful when designing levels. I'm not sure if OpenMW has a solution to this.

Alpha splatting simply means that where one texture meets another there isn't a jagged edge.

And yes, there is a (ongoing? defunct?) project to add a test suite to OpenMW that doesn't use vanilla Morrowind assets (and would be freely redistributable).

Resurrecting this to check on whether or not there's any future plans for either the tunneling/arching feature, or other features discussed in the thread like terrain holes/seams and a higher poly (more subdivisions per sq m) terrain mesh.

It helps a gazillion things an awful lot to know that the terrain is topologically a plane. The correct way to make an apparent tunnel or arch would be to create static meshes that looked like the top of the arch and place them above the terrain.