[kitten maciver]

edit: deleted comment, makes no difference

Couldn't you make the engine apply the normal maps to the meshes or something? I'm just spirting out crap here feel free to shoot me down.

[rheanna bruining]

It's great that you work on this and seeing how many people has engaged in this and the enthusiasm you're putting into it, I'm sure that it will be done and that it will be awesome. It's simply wondrous how this game evolves!

[Tessa Mullins]

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.

I say we hack it on so that *map is applied if the texture name has a appended letter. So if a mesh used foobar.xyz, if the texture foobar_n.xyz was found, it would use foobar_n.xyz with the same uv as the normal map

[John Moore]

I say we hack it on so that *map is applied if the texture name has a appended letter. So if a mesh used foobar.xyz, if the texture foobar_n.xyz was found, it would use foobar_n.xyz with the same uv as the normal map

Can you dump that down for me. _n at the end is normal map. _s would be spectral, and _p would be parallax. Will the engine do the mesh edit automatically or will we need to edit the meshes.

[Rachel Hall]

Can you dump that down for me. _n at the end is normal map. _s would be spectral, and _p would be parallax. Will the engine do the mesh edit automatically or will we need to edit the meshes.

It was a suggestion as to how to implement it without having to manually edit meshes. Just get the engine to set up the mesh textures differently based on if a file exists for the normal/parrell/whatever map

[JUDY FIGHTS]

It was a suggestion as to how to implement it without having to manually edit meshes. Just get the engine to set up the mesh textures differently based on if a file exists for the normal/parrell/whatever map

Coolness Thanks Yacoby.

Who ever wants to test textures you can try these.

https://www.yousendit.com/transfer.php?action=batch_download&batch_id=cmcyQmtjTkwzS29LSkE9PQ

[Alexxxxxx]

That's a pretty simple implementation yacoby. Brilliant.

[Kara Payne]

I cannot express how much I'm looking forward to this. While I only understand a fraction of what is being discussed here, it all sounds good :goodjob:

[Emma-Jane Merrin]

I say we hack it on so that *map is applied if the texture name has a appended letter. So if a mesh used foobar.xyz, if the texture foobar_n.xyz was found, it would use foobar_n.xyz with the same uv as the normal map

Wouldn't it be far better to take whatever is defined as the texture name inside a nif as the name of an Ogre material? That way users can create texturing with Ogre's full power backing it. Customized techniques based on hardware profiles, multiple passes, selectable vertex and fragment programs, etc.


This is sort of akin to how Quake 3's 'shader' materials work. All Quake 3 md3 models (can) carry an extension-agnostic built-in texture path in their data. If this path matches the name of a shader material, then that material is prefered to any jpg or tga file (which iirc is all Quake 3 supports for textures out of the box) with a matching path. In order of preference a tga file is then prefered over a jpg file.


I propose OpenMW chop off the extension of the hierarchically first texture path encountered in the nif (nifs are hierarchical right?), preferably the texture path setting for the 'base' texture coloring and tries matching that to an Ogre material. If it is succesfull it discards any and all texturing information in the nif and uses the Ogre material as a complete replacement. If no matching Ogre material can be found, chop off the extension of all texture paths and try finding the texture with a prioritized queue of extensions. First dds (naturally), then png, then tga, then jpg (which is sort of the 'order of quality') and as a last fallback bmp (which no-one should really be using due to the size of raw bitmaps).

[c.o.s.m.o]

Wouldn't it be far better to take whatever is defined as the texture name inside a nif as the name of an Ogre material? That way users can create texturing with Ogre's full power backing it. Customized techniques based on hardware profiles, multiple passes, selectable vertex and fragment programs, etc.

What I think we want is:

• Something that allows compatibility with Morrowind (I.E. not editing the nif format)
  
• Something that is easy/simple to use from an artists perspective

My proposed solution allowed someone to ship additional textures, or a patch containing textures to allow OpenMW to generate the necessary code. It also allows someone who doesn't want to write some complex material file.

I propose OpenMW chop off the extension of the hierarchically first texture path encountered in the nif (nifs are hierarchical right?), preferably the texture path setting for the 'base' texture coloring and tries matching that to an Ogre material. If it is succesfull it discards any and all texturing information in the nif and uses the Ogre material as a complete replacement. If no matching Ogre material can be found, chop off the extension of all texture paths and try finding the texture with a prioritized queue of extensions. First dds (naturally), then png, then tga, then jpg (which is sort of the 'order of quality') and as a last fallback bmp (which no-one should really be using due to the size of raw bitmaps).

I think it sounds a good idea to have OpenMW take into account any custom written materials first, however, I still think that we should allow OpenMW to generate maps based on if a file with a postfix exists.There is no reason why we can't do both, as they are not mutually exclusive.

Although I like this idea, I don't think we should discard all the other information, as a Nif is actually a collection of submeshes, we would need to check the path of the texture of every submesh in the nif.

[courtnay]

What I think we want is:

• Something that allows compatibility with Morrowind (I.E. not editing the nif format)
  
• Something that is easy/simple to use from an artists perspective

My proposed solution allowed someone to ship additional textures, or a patch containing textures to allow OpenMW to generate the necessary code. It also allows someone who doesn't want to write some complex material file.

Fair enough. The complexity of material files might scare off the less experienced and prevent them from modding media for OpenMW. I hadn't considered that.

I think it sounds a good idea to have OpenMW take into account any custom written materials first, however, I still think that we should allow OpenMW to generate maps based on if a file with a postfix exists.There is no reason why we can't do both, as they are not mutually exclusive.

Although I like this idea, I don't think we should discard all the other information, as a Nif is actually a collection of submeshes, we would need to check the path of the texture of every submesh in the nif.

I kind of forgot about the whole submesh thing. But like you already understood: my idea of runtime anolysis of the texture paths can work on a per-submesh basis as well.

If you want to incorporate underscore delimited _n(ormal), _s(pecular), etc. maps to combine with textures, then that can ofcourse also be part of such a runtime anolysis of extensionless texture paths. Just look for a match to a material first and ignore anything else if you find a match to an 'advanced' material, since it can do everything by itself. If you can't find a material match, look for textures, including the _n, _s, etc. postfixed ones for easy addition of normal, specular, etc. maps.

That way you get both without conflicting and without having to alter the data in the nif file.


You wouldn't alter the nifs anyway. You'd use a custom resource loader in Ogre to load the nifs and convert them to Ogre's internal mesh and material format on the fly. I do recommend that you take that route and do not use manual rendering techniques to write out the nifs using handmade vertex and index buffers when rendering. Ogre's internal mesh format is optimized for rendering with the engine, iirc.

[Eileen Collinson]

Fair enough. The complexity of material files might scare off the less experienced and prevent them from modding media for OpenMW. I hadn't considered that.



I kind of forgot about the whole submesh thing. But like you already understood: my idea of runtime anolysis of the texture paths can work on a per-submesh basis as well.

If you want to incorporate underscore delimited _n(ormal), _s(pecular), etc. maps to combine with textures, then that can ofcourse also be part of such a runtime anolysis of extensionless texture paths. Just look for a match to a material first and ignore anything else if you find a match to an 'advanced' material, since it can do everything by itself. If you can't find a material match, look for textures, including the _n, _s, etc. postfixed ones for easy addition of normal, specular, etc. maps.

That way you get both without conflicting and without having to alter the data in the nif file.


You wouldn't alter the nifs anyway. You'd use a custom resource loader in Ogre to load the nifs and convert them to Ogre's internal mesh and material format on the fly. I do recommend that you take that route and do not use manual rendering techniques to write out the nifs using handmade vertex and index buffers when rendering. Ogre's internal mesh format is optimized for rendering with the engine, iirc.

I think besides not wanting to 'scare' people from modding for openmw it's also important to stick to the promise that you can use all of the current mods with it. To that end, I would still like to see openmw support more than just the nif format. In addition I think it would be better to let people still use the nif while having the choice to switch to the newer better format. This is similiar to the question on what to do with the esm format.

It would be nice to aim for a complete migration to openmw so that we could eliminate the need for legacy support. We could make a converter for the current mods' nifs and esps. We could even put such a converter into a new editor as a "save as" function. After that we could to try to convince the community to use openmw instead of the vanilla engine - eventually cycling out vanilla (legacy mw) support. That is, only if we could eliminate legacy support and improve engine speed.

Btw, the custom resource loader sounds like it would give openmw a slow start up. If we're going to go the route of internally coverting nifs to ogre's mesh and material format, we may as well save the resulting converted files to an archive or to file so that you don't have to do it each time openmw loads or every time the nif loads during gameplay.

Whew, writing that out on an iPod touch was a nightmare!

[Josh Sabatini]

I really like the filename-based normal map idea! It should be as simple as that. I can spot a couple of potential challenges though - the obvious one is if the _n etc file name collides with another existing file, and the second more subtle one is the extensions. The original images are stored as dds, but I think we should allow normal maps in png, gif, jpg or whatever. It's a bit bothersome (and slow) to search for all possible extensions for each texture.

Here's one proposal for a solution: For each texture you want to replace or improve, create a texturename.txt (eg. for in_sometex.dds you make in_sometex.txt). This file contains something like this:

Normal=my_normal.pngSpectral=my_spectral.gifParallax = some_file.ddsMaterial=my_material.material

where each line is optional, case insensitive and allows spaces wherever you want. Not quite as simple as Yacoby's solution - but is it too complicated?

We could also add a 'Replace' field to replace the texture itself.

[benjamin corsini]

I think besides not wanting to 'scare' people from modding for openmw it's also important to stick to the promise that you can use all of the current mods with it. To that end, I would still like to see openmw support more than just the nif format. In addition I think it would be better to let people still use the nif while having the choice to switch to the newer better format.

:nod:
I don't think it would be much (any?) effort to support the .ogre mesh format if/when we move the nif loader to a Ogre resource class (If we can?)

You wouldn't alter the nifs anyway. You'd use a custom resource loader in Ogre to load the nifs and convert them to Ogre's internal mesh and material format on the fly. I do recommend that you take that route and do not use manual rendering techniques to write out the nifs using handmade vertex and index buffers when rendering. Ogre's internal mesh format is optimized for rendering with the engine, iirc.

Surely the .nif format is going to be in a fairly good format for reading fast. I can't see the huge benefits as to moving to something else :shrug:

I really like the filename-based normal map idea! It should be as simple as that. I can spot a couple of potential challenges though - the obvious one is if the _n etc file name collides with another existing file

Yeah, that is an issue, but I can't see it being a major problem. If it is, it wouldn't be too hard to write a program that patches the problems.

the second more subtle one is the extensions. The original images are stored as dds, but I think we should allow normal maps in png, gif, jpg or whatever. It's a bit bothersome (and slow) to search for all possible extensions for each texture.

We are going to have to if we want to maintain compatibility. You may have noticed that if you set a texture to use foobar.tga, but in the filesystem, foobar.dds exists, it will use the dds. Landscape textures are all assigned as .tga, but they use the dds files.

I wonder if we could just subclass the filesystem resource class to do this for us. So rather than search through the textures to find the right one at runtime when we are loading the mesh, we try and do it at startup. It isn't that bad searching for duplicates as long as the algorithm is ok. (No need to look for files with duplicate names outside the directory that the base file is in).
If you wanted to do it at runtime, you could always add the list of available files into a Ordered List, which would make the search extremely fast.

:shrug:

[Elizabeth Lysons]

I would still like to see openmw support more than just the nif format. In addition I think it would be better to let people still use the nif while having the choice to switch to the newer better format.

This sorta goes with my suggestion on one of the previous threads about OpenMW having compatibility with all the Nif formats, like OB and Fallout 3 nifs, as well as all the other nif formats used in other games (which are listed in the nif export settings in blender). I also think that common mesh formats like OBJ's should be read as well, allowing easier compatibility with all sorts of new stuff.

About the textures (extra maps that is), I think it's a great idea with the automatic reading of maps. But as said, it wouldn't rely on the meshes, so you could attach maps to landscape textures and such as well.

[Kat Ives]

MW nif format supports the following texture maps:

Base Map
Dark Map
Detail Map
Decal Map
Bump Map
Gloss map (so far not working in MW - in the game, TES exporter does the job)
Glow Map
Normal Map (not supported in MW nif format, v.4.0.0.2)
Paralax Map (not supported in MW nif format, v.4.0.0.2)
Shader Textures, array (not supported in MW nif format, v.4.0.0.2)


Can additional mesh texture map (e.g. normal map source file) information be stored/read in/from NiStringExtraData node that is attached to a specific NiTriShape node?

[N3T4]

Surely the .nif format is going to be in a fairly good format for reading fast. I can't see the huge benefits as to moving to something else :shrug:

It's not an issue of disk I/O where you have to load the file into a structure in memory. Ogre's .mesh format is a binary image that is molded exactly against the engine. It has all the data in exactly the right place to stream through the pipeline of Ogre's engine with its optimized built-in mesh rendering techniques. It would give far better rendering speed of complex models to OpenMW than any kind of native .nif renderer you could produce, I think.

[Ryan Lutz]

This is for down the track but instead of rendering the nifs I'd also like to see everything converted into .mesh and hopefully down the track we can do it for other formats aswell so a sort of conversion selection chain is used.

[Nicole Kraus]

This is for down the track but instead of rendering the nifs I'd also like to see everything converted into .mesh and hopefully down the track we can do it for other formats aswell so a sort of conversion selection chain is used.

I think there are potential legal issues with converting .nif files (I remember tbrick saying he only intended to allow the use of Morrowind-level .nifs in OpenMW). Original .mesh files should be OK though, though it's up to tbrick I guess.

[Eilidh Brian]

Do you guys have ideas about how to implement grass? I think most people will want some kind of a grass mod. Vality7's mod might be finished with all regions one day, but if it's easy to do a grass system that's more easily expanded to new areas, that could be a good idea too.

[Charlie Sarson]

Do you guys have ideas about how to implement grass? I think most people will want some kind of a grass mod. Vality7's mod might be finished with all regions one day, but if it's easy to do a grass system that's more easily expanded to new areas, that could be a good idea too.

If grass is going to be used. I suggest animated grass that can be reduced by a slider. Like in Oblivion. Static grass doesn't look as good in my opinion.

[Silvia Gil]

If grass is going to be used. I suggest animated grass that can be reduced by a slider. Like in Oblivion. Static grass doesn't look as good in my opinion.

The grass we have is animated and does have a slider, where've you been?

[Hilm Music]

The grass we have is animated and does have a slider, where've you been?

I think he means for OpenMw, but yeah we already have the meshes and textures. Hook it to specific ground textures and there you go. Still, it would be nice if it didn't collide with other meshes touching the ground

[Karine laverre]

The grass we have is animated and does have a slider, where've you been?

This seems to be the name of the thread.
OpenMw NewERest Thread!, I dub thee... PROGRESS!

So I'm not sure what your referring to when you say we have....

[Alyesha Neufeld]

This seems to be the name of the thread.
OpenMw NewERest Thread!, I dub thee... PROGRESS!

So I'm not sure what your referring to when you say we have....

I'm referring to MGE of course, I don't know where you got the idea that the grass would be static though.