I was playing with this briefly earlier, and tweaked the DLL to take any calls from Morrowind to set the first 8 lights (0-7, the sun is apparently #6), and cached the results.
I then passed them through to shaders as a vector array (containing the color), forced the alpha to 1, and set up a debug shader. I'll get the tweaked DLL (svn 116 + my edits) and the shader uploaded tomorrow (need to check over them again). MGE & Morrowind can handle up to 1024 lights, so I need to make a way to set each to a different slot. The first 5 or see seem unused.

Anyways, screenshots:
http://s4.photobucket.com/albums/y145/peachykeen000/?action=view¤t=MGEScreenshot1.png
No lights in the menu.
http://i4.photobucket.com/albums/y145/peachykeen000/MGEScreenshot4.png
Desile's, a few lights used according to this.

While outside, the lights are generally pink (?):
http://i4.photobucket.com/albums/y145/peachykeen000/MGEScreenshot2.jpg

This is only rough starting info, and I'm no DX programmer (anyone who's seen the ShaderConf preview window...), but supplying positions and colors to shaders should be possible. That will allow true normal, bump, and possibly parallax mapping. We'll just have to see.

Edit: Also, we may be able to add MWSE functions such as xAddLightSource, xSetLightColor, etc.

Umm... so could you explain to use non-coders what this is? If it's allowing normal, bump, and parallax mapping as you said I am interested, but I wanna know what this is.

Ok. The strange strips down the left edge of those shaders are the colors of the lights, intercepted as Morrowind set them.
The first box is black. I'm guessing some kind of world ambience (also, light 0 has special purpose in dX, if I remember right).
The rest are each (the bottom two identical) one light in the world. This is quick debug info, not good for accurately telling, but those are the lights.

It's also possible to access the position data as well, which would allow lighting effects. You could, for example, as lens flair, far better bloom, and possibly per-pixel lighting.

I'm stilled confused, but what it seems like is you found out some sorta break through.

Hmm, interesting. Is it one light per slot though? How does that work,as 1024 is the number of lights, but you say there are only 5 slots.

So with this we could possibly support things like ambient occlusion? If so, whoo!

Z-buffer is another problem. Nobody can find the z-buffer from Morrowind, not even Nvidia.
http://i51.photobucket.com/albums/f386/vtastek/morrowind/aotest/Morrowind-MGE-SSAO1.jpg
http://i51.photobucket.com/albums/f386/vtastek/morrowind/aotest/Morrowind-MGE-SS2.jpg
http://i51.photobucket.com/albums/f386/vtastek/morrowind/screenshotspart08/Morrowind-MGE5.jpg
I can get SSAO in MGE rendered areas. So interiors and near things don't get the effect.(You should lower the view distance as much as you can because default view distance is 5 fps. And with interiors, it is worse because view distance is higher. There is certainly a big fight happening between nvidia driver and morrowind engine.)

Returning to topic:
Peachykeen, you are my hero. This is the most promising thing, infinite times important than SSAO(and god rays :spotted owl: ). I should accelerate my learning curve for shaders.

you said you could try to do this just yesterday, you sure are good!
if this works it's going to change morrowind graphic as musch as distant land did

Wait wait wait, do I have this straight, you may have found a way for mge to intercept morrowinds lighting calls, that could allow for mge to possibly overide those calls with more realistic lighting? Or even allow it to display paralax/bump mapping oppropriately based on light position ect...........this may make Open Morrowind obsolete if the possibilities that I'm thinking of are actually....possible. Peachy, you should just rename yourself to astonishing morrowind breakthrough provider, and start charging for your services(kind of like a cable provider, only with dish like channel options).

Open Morrowind obsolete because of a few graphical innovations? I don't think so.

Peachykeen, you A BIG!!!!!

this is a great enhachement for morrowind, but don't forget that openMW isn't only made for graphic improvement... it has many other important purposes, such as improving scripting, much more animation rooms and so on

Plus cross-platform compatibility!

Fair enough, I have not actually followed Open MW that closely, mainly because it has always felt so far off, regardless, this could be be viewed as another "animated grass" type of advancement for MGE, which is still a drastic improvement in my opinion.

That being said, and this doesn't mean I wouldn't jump at OM when its released, I feel that MGE+MWSE+Morrowind(the trifecta) is a more dramatic improvement over vanilla, than Open MW is over the trifecta. Thats just my opinion on what I have actually seen, of course, I haven't seen anything to show off scripting improvements, so I can't or rather just won't comment on that side of the equation.

omg, dunno how I could forgot that, since I use ubuntu



you're right, MGE is a great improvement but I'm sure that om will bring morrowind to a new life
just wait and you will see

Oh, I agree OM will breath new life into the game, just as MGE has, and I am definately excited as to the possibilities a new engine can bring(new era of stability, distant land/ssao without the need for external programs, more advanced AI ect.)

I just mean, that new advancements in what is already available now(mge/mwse/vanilla related) such as light sourcing, water effects, swaying grass/trees are just as exciting to me, because they appear to be closer to, or are already realized, improvements.

Both a Horizon and an eclipse are beautiful events in nature, but I can more likely count on seeing another horizon, than an eclipse.

Edit: I am sorry for having derailed this thread at all, it was not my intention, nor was it my intention to suggest that any improvement, released, or wip is any more or less significant than another, I tend to throw my opinion around on quite a few matters where an individuals opinion is probably not necessary..........back OT, keep up the good work Peachy!

oh, yeah, I'm also sorry for the OT...

so, if you can get the light position from the game isn't it possible to generate realtime shadows? or this is far too much ?

I only added 8 slots to save on memory. If a quick way (say using a std::map) is found to manage all the lights, that will be possible. I didn't know how many Morrowind used, so for the test DLL I added 8 pre-allocated spaces.




Ambient occlusion has more to do with depth than lighting. If the depth buffer is found (something apparently no one can do), then things are possible (I'm still searching, but given that it's made on the video card, not in system memory, it's extremely hard to read).




This isn't as major of a breakthrough as it may appear. The code is already mostly there (the sun position and color are already intercepted). I don't know why whoever added that didn't do regular lights. There may be some issue I haven't run into yet.




MGE can intercept all light calls to DirectX, yes. It may be possible to improve lighting, I'm not sure.
It can certainly supply position and color data to shaders and scripts, which should allow parallax and bump mapping to a limited extent.
The maps would still have to be on the texture, hence vertex shaders and hooked textures loading. Unless a universal texture is applied, say as the base for all texture, and MGE gives it texture info.
Example:
- Morrowind loads model
- Model has texture tA.dds
- MGE loads fx_parallax.fx (shader) and gives it the texture variables:
- - baseTexture = "tA.dds"
- - mapTexture = "tA_n.dds"

It would slow the game down quite a bit, I think, but if a shader (similar to a UT3 material) is loaded and that shader performs all texturing, as well as bump/normal mapping, then all texture effects that are possible on the GPU would be possible, at the cost of speed. Simply using the vertex shader to texture objects shouldn't be too hard on performance, and only applying this technique to ones that need special effects (parallax, specular, bump, halo, motion blur, refraction, reflection, etc) would certainly speed things up.
The only possible downside is ENB incompatibility. However, I think many people may be willing to trade a bit of bloom for essentially unlimited graphical effects.

Now, before people start getting to excited (this'll save your pants here):
This is only debug info from the beginning of testing. The entire thing may not work, say if Morrowind internally handles lighting. It is likely that lights can be supplied to shaders, but I make no promises or guarantees.
I can tell you, if this is all possible, it'll cost. Probably in memory and framerate. The more effects, the slower it will go.
And I cannot, for the life of me, use Subversion, so I haven't any clue how I'll spread any improvements I may make.
I may just branch the code. PKGE. It has a nice ring to it.

just trying to do this is something like an improvement to me


well, if this thing was already done for the sun why don't try to use those informations and build a bump map shader based only on the sunlight? just to test if it is possible, you know

A ) last night I didn't have shader code for those things
B ) need to figure out how/make hooked textures work
C ) need to pass the data to shaders (already done, though)

It would be, what, normalize(SunVec, NormalVec)?
I'll play with it.

You're going about it wrong, I think I should explain how lighting works in most engines including Morrowinds.

You can place as many lights as you want in the world, each light has an extent (radius) which determines how far it has an effect on objects; objects outside the extent don't get lit by that light. In other words no every object is lit by every light, simple, but it means that one call to SetLight (with a new index) doesn't equate to one light in game. The engine determines for every object which lights affect it, and picks (up to) the closest 8 lights. It then sets only those lights into the render state for that object and renders it. You realize, then, the debug palette only shows the lighting of the last object to be rendered, which is most likely a UI panel which wouldn't actually use lighting at all.

Passing light data to shaders is pretty simple already. When a hooked object gets rendered, just grab the fixed function lighting state and then set some equivalent constants in the D3DXEffect. That's it.

That would explain the values.
However, it doesn't hurt much, seeing as MGE wraps the full rendering pipeline, so intercepting it at render time (when the hooked texture & shader would be loaded anyways and lights are all set right) shouldn't be an issue.
That also greatly simplifies what I was trying, if actually managing the lights isn't needed. Thank you, then.
I'll have to play with this. If what you're saying is as simple as it sounds, then my work is at least halved, if not less.

Anyways, I'm working on a sun-based shader. Just need to get the shader and such working (haven't gotten MGE texture hook to work right yet). If anyone's often used, or knows the tricks to hooking textures (if there are any), by all means, please share.

I have some experiance hooking textures. Things I've concluded:

*Seems sky doesn't want to be hooked properly, tested once, not 100% certain about the fact.
*Does not work with Landscape textures applied to MW landscape 100% certain
*AVI works quite fine, so does some other formats
*Works fine with models. Models can even contain their transparency!
*ENB will crash any texture hook :/ not 100% certain of this either

Great work Peachykeen!

A bit don't understand, peachykeen, sorry, u want to make bump mapping and normal mapping in Morrowind like in Oblivion O_O?
If yes - u will be my god, i give my word .
Waiting foryour answer!

In my researches I come to conclusion that with z-buffer and using existing hardware features, you can have shadows too. And there are plenty of shadowing methods to pick, from soft to hard.

"Depth buffer based custom shadow mapping..."

http://developer.download.nvidia.com/GPU_Programming_Guide/GPU_Programming_Guide_G80.pdf
There is information about z-buffer access, INTZ and RAWZ usage at page 58.