Discussion Bump maps / Normal maps

[Pyromaniac605]

I had a little idea one day while I was playing Orbiter, why doesn't Orbiter have bump maps? Bump maps are a great way to add detail without a higher polygon count on the meshes, so why aren't they implemented?

I posted in the d3d9 thread asking if bump maps may be added in the future.
What's your take on bump maps? As an addon developer would you use them?

 

[HAL9001]

I'm not a REAL developer, but I thinkthat bump-maps would be really cool.

 

[agentgonzo]

The built-in rendering engine that comes with orbiter is written in DirectX 7. Bump mapping in this is not particularly well supported and it was only when vertex/pixel shading came along in DX8 that bump mapping became easy and fast. That's probably why it's not included in the core rendering client.

I don't see any reason why the devs of the D3D9/OpenGL client for orbiter can't support it.

 

[Coolhand]

OGL supports Normal Mapping, the DX9 engine should also support that.

Normal Maps are like Bump Maps, only better.

[ame="http://en.wikipedia.org/wiki/Normal_mapping"]Normal mapping - Wikipedia, the free encyclopedia[/ame]

The XR2 will have normal maps (or bumps) for those engines that support it.

 

[Artlav]

I don't see any reason why the devs of the D3D9/OpenGL client for orbiter can't support it.

OGLAClient support bump (normal) maps since forever:

The problem is that there are currently three vessels that support bump maps, and all are boilerplate OGLAClient demos.
Further problems is when D3D9 client would implement bump maps it will be another interface for them. So developers would have to support two or either.

I've proposed an extended client features common interface scheme twice before, but it was ignored/overlooked.

 

[agentgonzo]

Further problems is when D3D9 client would implement bump maps it will be another interface for them. So developers would have to support two or either.

I always hope that if there are two different systems (OGLA and D3D9 in this case) and one develops some new features (OGLA doing normal mapping) then the other system would just do their implementation to match, so that the vessel developers wouldn't need to worry which system you used.

History, however, has smirked at my naïvety.

 

[Artlav]

then the other system would just do their implementation to match

The problem is, to access the features you'll have to link to OGLA.dll.
So, even if D3D9 matches the interface, there is still a problem of linking to another DLL.

So the vessel code or some common SDK would have to look for both DLLs determine which one is active, and link to it.

Solvable, but needs cooperation and a common, client-independent SDK.

 

[Eraser]

Solvable, but needs cooperation and a common, client-independent SDK.

Why would you not talk to jarmonik about this? :thumbup:

 

[agentgonzo]

The problem is, to access the features you'll have to link to OGLA.dll.

Strange. I'm sure there's a reason, but I having to have vessel code link to the rendering engine's DLL seems a bit backwards. I would have thought that the Vessel code should be independent of the rendering engine (with the exception of common engine-independent hooks)

 

[jarmonik]

The XR2 will have normal maps (or bumps) for those engines that support it.

From where can I get one ?

 

[orb]

The problem is that there are currently three vessels that support bump maps, and all are boilerplate OGLAClient demos.
Further problems is when D3D9 client would implement bump maps it will be another interface for them. So developers would have to support two or either.

I just looked at the tcube.msh, and I wonder, why does mesh format need any modification? There could be just one texture and one UV map referenced by a mesh, like for example "tp\tc.dds" for the common for all Orbiter versions diffuse map, and graphics clients would load and apply to the same UV map a normal map and light map (and other possible), just by adding a suffix to name. For example if there is "tp\tc.dds", a client would look also if there is "tp\tc_normal.dds" and "tp\tc_light.dds", like for example base textures have their "_n" version for night lights not referenced explicitly anywhere.

I don't understand why there is a need for extending the mesh format for other texture maps. All can be done with only some common texture naming standard.

 

[agentgonzo]

I don't understand why there is a need for extending the mesh format for other texture maps. All can be done with only some common texture naming standard.

This was pretty much my thoughts.

 

[jarmonik]

I don't understand why there is a need for extending the mesh format for other texture maps. All can be done with only some common texture naming standard.

Yes, I agree.

 

[Artlav]

Strange. I'm sure there's a reason, but I having to have vessel code link to the rendering engine's DLL seems a bit backwards.

Something have to be written somewhere, an engine can't read developer's mind.
Naturally, intended features are defined by the vessel. Linking to the client is one of the easier and most versatile ways. Adding commonly used things to the mesh format is another.

Why would you not talk to jarmonik about this? :thumbup:

Because my interest in OGLAClient development is near the lowest point at the moment.

why does mesh format need any modification?

For convenience.
First, it's the case of graphic-client-independent thing - any client can use or ignore the alterations. Orbiter core ignore them anyway.

Second, a secondary set of UV coordinates is a useful modelling feature. You can have the normal and diffuse maps with one UV, and the light map with the other. Or have a complex layout of diffuse/light/normal textures on UV1, and reflection map with simple wrap-around by UV2.

Third, convenience of defining textures. You can have a common diffuse and different normal maps, for example.

And i just don't see why not.

 

[orb]

And i just don't see why not.

For example, that's why not:

The problem is, to access the features you'll have to link to OGLA.dll.
So, even if D3D9 matches the interface, there is still a problem of linking to another DLL.

And another why not: because to use the extended features you explicitly call "oglcBindExtMesh", which won't be called from a simple, .cfg only vessel, or a base object.

 

[Artlav]

And another why not: because to use the extended features you explicitly call "oglcBindExtMesh", which won't be called from a simple, .cfg only vessel, or a base object.

Alternatives?
There is no possible way of knowing which mesh file was loaded, Orbiter only gives the mesh data itself.

For textures naming convention might work to some extent, for mapping - i don't see a way.

At what point are additional textures to be loaded?
Orbiter gives commands like load a texture, but a mesh is presented separately, and the global identifiers of the textures are provided for the groups.
Should i load every matching texture into some kind of buffer, regardless of it being used?

And the problem of needing to link can be solved by the common SDK. oglcBindExtMesh would be a call into it, and it then calls the relevant client.

A pity M6 forum is down, can't find a copy of the full description, and i'm currently not in sync with this stuff enough to make a consistent new one on the spot.

 

[orb]

Alternatives?
There is no possible way of knowing which mesh file was loaded, Orbiter only gives the mesh data itself.

There is a way. For example you can hook "??0?$basic_ifstream@DU?$char_traits@D@std@@@std@@QAE@PBDHH@Z" MSVCP80.DLL function in Orbiter's IAT, which opens meshes for reading - a pointer to file name is passed there.

I use such hook for reading meshes from a named pipe instead of physical file (to initialize the pipe and create pipe writing thread), and then call previous version of the function with altered file name.

 

[Coolhand]

From where can I get one ?

An XR2 with normal maps?

I have been meaning to contact you with regards to making that happen... as a trial run for the mk2 and perhaps between you, doug and myself producing a dx9 version with full normal maps. But at this stage this is very much news to both of you i'm sure

 

[Artlav]

There is a way. For example you can hook

Sure there is, you can hook some functions and replace DX with OpenGL straight in the inline client.

The question is how to make a proper way instead of how to hack in a crutch.

 

[jarmonik]

An XR2 with normal maps?

Yes, Something like that. I have a normal map for a brick wall but that probably doesn't map very well on a surface of the XR2 and I don't have a proper tools to create a normal map. Even a very simple one would be enough for testing the code.