This looks like a great project to me, plenty ambitious! A small feature request: allow scripts to move distant land around and enable it in interiors. I've managed to get MGE to do this, so I can have interiors-as-exteriors with open windows. But it's a (semi) hack, only works on my modified version of MGE, etc. If I release a mod using it, I'll either a) have to commit my changes to MGE's SVN and distribute a compiled version of the latest SVN, which has its own bugs (before I noticed, the MWSE pipe wasn't working at all...), or B) backport it to 178 and release it as a fork. Or ask Hrnchamd nicely to include it in MGE XE, or both. So that's all a little complicated.

What a great idea, I never thought of using distant land for that. I probably won't understand it but how do you managed to keep track of where you're at to make sure that the right distant land shows up in the interior?

I don't, actually. Getting it to work for generic interiors poses a lot of difficulties, so I haven't looked into that. Right now, it's done manually- a script in the interior tells MGE what cell to pretend the player is in. In the CS, I've taken the house that's in that cell, then modded its x and y position by the number of game units in a cell, and move the interior statics into that location. This makes the interior's 0,0 position line up with a corner of the exterior cell. https://imgur.com/W6UWt.

One of the problems of getting it work with generic interiors- without modification- is that they don't always fit into the space allocated to it outside. Ex: anything with a basemant or embedded in a mountain could look weird inside. One problem which I'm still trying to work out a good solution for is that since MGE will have generated distant statics for the exterior of the house, you might be able to see the "distant" house rendered behind or inside the real inside house. My solution right now is to have a version of the mod that just includes land changes and no statics. This works, but you can't see the house in distant land outside.

Seems like a bit of work to do by and and the non matching interiors and exteriors does seem like a bit of a problem.

Is it theoretically possible to make voodoo load the closest interiors when being outside? They'd be in their own coordinate space that would get "mounted" (file system anology) to the exterior space at manually marked portal spots, so that the bigger internals wouldn't bleed outside the exterior shell. The size difference would make a slight visual distortion when one can see the interior from two windows at the same time, but that's rare i think. Also, i presume since it would be handled through the distant land mechanism, no AI and hence no NPC's could be present in the interiors. Does that make any sense?

Interiors visible from exteriors and exteriors visible from interiors. I love it, except it would suffer from the mismatched interiors and exteriors too.

Disclaimer: I'm not really an expert, but...

Yes, it's probably possible. You would take windows and hook their textures so as to be able to render to them. peachykeen has mentioned that Voodoo can do this, I think MGE can in a basic way. Then you would have a distantland-version of the interior; Voodoo would be told where the interior window and exterior window are, and render the proper view of the interior based on the viewpoint of the player. Conceptually, at least, it seems doable. I had the same idea yonks ago, actually, but didn't (and still don't!) have the actual ability to carry it out.

I don't think Bethesda was completely consistent with their interiors/exteriors space-wise. If you place an interior house right onto the exterior version of the house, do they fit exactly? I doubt it.

In one of your posts, you had asked for suggestions for other games. Gothic 1 & 2 spring to mind (poor low-poly games could really use a facelift more intense than new textures!).

Gothic1-2 would be great indeed

I might even be willing to part with my copy of Gothic Universe (I have G1, G2, and G3 in separate boxes, too. Actually, I have two copies of G2 Gold's 4-disc set). 'Twould be for a good cause!

Well, it'll be a bit till I have distant land working (have to rewrite that from the ground up), but I don't see why that wouldn't be possible. Just moving the player's position by script, then resetting it when they enter a new cell (to prevent poorly-written scripts from breaking things). It will depend on how I render distant land, but it should work fine.

It would also be possible, and possibly more useful, to just keep track of interior-exterior relations in an external file. Similar to the material shaders, mods could provide a cell-location file. It might be messier than using scripts, especially since cell names aren't always unique.



Eh, in theory, yes. In practice, it might be a bit difficult. The most difficult part would be defining the portals and checking how to render the interior through them.
The general idea of making distant interiors is possible, but could certainly get messy. I'm not going to speculate much on it until I get the basics running well.



Well, you can attach a shader to any given texture (MGE can as well, but their implementation replaces the texture file and is generally awkward and prone to breaking things).

Now, in theory (and this is a stretch), you could use a material shader to render a few objects to a separate surface (an offscreen texture). Render the regular scene and using either alpha or chromakeying, composite the other scene behind it.

A somewhat similar, but probably simpler method will be used for distortion effects (heat shimmer and refractive glass), writing the distortion mask to an offscreen surface and compositing them after the scene is done rendering.


I don't think they were, and I know modders have taken advantage of N-space and played around with scale.


I'll take a look at the Gothic games and see how they work. They're pretty common, so I bet I could dig up some copies around (might even have one, have to check). I'm not sure about taking games from people, not sure if there would be any issues with that (especially legally), so finding a copy myself would probably be a bit better. I need to get the ones on the list working first though, but these will certainly be added to the to-do list.



Anyway, gotten a few reports back from a couple of the folks I sent test copies to. It seems there might be a minor bug with the location stuff (I keep the core files in one spot and game-specific files in another). On some system, the hook is having trouble retrieving the path of the main files. Until that's working, we can't test the rest of it, so I'm not sure if that part works yet. Everything is still working great on my comps, so it's just some little detail. Hopefully I'll have that pinned down and fixed soon.
I've also been playing with some new and slightly more complex shaders (roughly at the level of MGE's best). They run fine, so once I've verified that this part works, I'll be improving on the shader system a bit more (which is where it'll start to have more features than MGE). The per-pass and per-technique target system is already in place (allows you to chose the texture the shader will draw to, instead of just to the screen).

I like the idea of using an external file, in that scripts can be a bit messy too. The way I have it set up right now requires three scripts. One attached to an activator starts it when the player enters the cell, then starts a script to wait for the player to leave and disable it. The activator also detects reloads and sets up the distant land when the player loads a game in the cell. There's a third script that runs as a startscript to turn it off if a player inside the cell loads a game where he's outside the cell. It all seems to work, but it's not really ideal.

I made a post about maybe extending this to Unreal Engine games on the voodooshader.com forums, didn't want to post about it in a morrowind mod forum.

This is true. In actuality, almost none of the interiors will fit inside of exterior statics.



Well one thing you can do here is a trick - if the windows are transparent - you take a half a cylinder and apply the viewpoint as a texture to it. You then set the half cylinder just inside the window. You get an illusion of being able to see inside without it seeming like a flat surface and without having to rez the inside of the building.

In regards to everything else, this seems to be coming right along. Hopefully there wont be any greivous errors to contend with.

The latest version just finished compiling. Need to do some research on how to automate the Gem installer (so it installs the right files to the MW and Voodoo directories), then I'll have another test copy to send out. Hopefully the bugs from the last one are squished, but I need to do some heavy testing on the registry functions.

If anyone absolutely just has to be involved in the testing, let me know and I'll send you a copy too. Until I know it works for most of my testers, I won't be posting the links, but as soon as I get more success than fail reports they will be up in this thread (I haven't gotten too terribly many back, what with the holidays, but there were obviously a few bugs).


The only problem with external files is tracking the exact cell. Otherwise, they're more or less a perfect solution. For data like this, I like keeping things in nice neat files. Preferably one directory under the Morrowind folder, with subdirectories for material definitions, shaders, etc. Things are a bit different here, since plenty of Voodoo shaders will be universal, so there will be a central location as well. Anyway, I'll have to look at the most optimal way to handle that. If you have any further thoughts on it, please let me know.


Replied there. Like I said, the whole premise of this is universal shaders, so the more games it works with, the more useful it is for everybody.



That works in general, but has a few issues. You have to pregenerate them, first off, which is just a minor pain. More problematic is the perspective, although with some tricksy math, I suppose you could get it to look pretty good. Another thing, which probably wouldn't work here but is awesome enough to be worth mentioning, is that Voodoo supports loading a few extra image formats (I like DevIL and it supports plenty of formats), including both true HDR and volume/3D textures. Besides the obvious use of volume textures to do light shafts inside and special fog and other such effects, you might be able to cast rays through them for windows, if you were to calculate the end-point of the ray based on player's location.


Few minor bugs, but so far nothing horrible has popped up. Good (well, decentish ) coding standards and an occasional run-through with some static anolysis tools have pointed out a few bugs that could've popped up. On my system, at least, it works perfectly. Still poking it a bit so that happens for everyone.

Emphasis mine.

I might be alone in this, and it might be a minor nitpick, but I really would prefer to keep the manual install. I'd have even liked manually installing Voodoo if the option was given. Installers are bad enough normally, but when you maintain a multitude of different Morrowind for various reasons (playing, modding project folders, MGE testing, MGE XE testing, Voodoo/Gem testing, etc) it is much more comfortable to drop files/folders in manually rather than have an autodetect installing things to the last copy of Morrowind that affected your registry.

[/rant]

Having access to MSDN I decided to grab a copy of visual studio and managed to get it compiled but can't do much from there. I also need to go find more stuff to compile for the heck of it.

Well, the reason I have the core in an installer is two-fold. First, it allows me to simply and easily update it and keep things in a central location. Second, and more importantly, the game hooks don't contain the shader code. They're very simple redirect modules, which use a registry entry to find and load the core. Without an installer, you'd have to manually create the registry stuff. So, the core will (unless there's a major issue) stay in an installer. I can provide an archive as well, but that'll take more manual setup.

As for having Gem in an installer or not, either way works for me, there isn't much difference. It won't be terribly hard to set up some scripts to generate and build both an installer and archive after I compile the code, so I might just make both available.



Actually, no, I hate 2010. I use 2008, with Visual Assist X and ViEmu (2010-style intellisense and Vim key commands).

Anyway, if you have it compiled (did you run into any issues with that, have trouble, anything interesting?), you can test the debug builds on your system. They usually don't work, requiring the Visual C++ debug runtimes (which aren't distributable), but those are in VS. I just pushed the latest code to the Github repo, and both the current and next test versions contain debug binaries and symbols as an optional install. Having someone else capable of testing debug builds would be very helpful, so if you're willing, that'd be great.

You beat my edit, I was looking at the revision changes and saw VS2010 but then I realized that was because I converted the solution file myself :blush:. Still trying to figure out this git and messed up my includes and libs because I was just going to redownload the whole thing and now the compiler is raging about a >LINK : fatal error LNK1104: cannot open file 'Voodoo_Core_d.lib' because I forgot to also redo my lib directory :blush: but it still rages at me after setting up my lib directory.

MSB8012: $(TargetName) ('Voodoo_Core') does not match the Linker's OutputFile property value 'C:\Voodoo\\bin\Voodoo_Core_d.dll' ('Voodoo_Core_d') in project configuration 'Debug|Win32'. This may cause your project to build incorrectly. To correct this, please make sure that $(TargetName) property value matches the value specified in %(Link.OutputFile).

I couldn't compile with 2010 so I got 2008 and still can't compile. Something about Voodoo_Core_d.lib missing. Something along the lines of some earlier file is failing to compile so it's just a train wreck behind it?

You might be trying to link debug Gem against a release Voodoo core. Build Voodoo Core as debug or something.

Just reinstalled MW and I have an older rig {AMD 939 Dual Core/ATI HD4670/Windows 7/64) and I'd love to test for you.
The last few MGE's have been almost impossible for me to get playable frame rates with ANY shader so I'd love to see if your implementation squeezes out any more frames.
I've been playing Modded Elder Scrolls for a long time and while I'm no wizard, I know my way around.

Added some more debugging stuff to the hook, which seems to be the most common point of failure. Changed it so there's one hook type, and it will dynamically load the release or debug stuff, depending on which is present and a special flag (makes testing simpler for me). I don't trust the hook yet, so I'm going to add a bit more error logging before I release the next test version.

I got an automatic Gem installer together, along with the archive version. The installer picks the MW location in your registry and puts the files there, so it only works on one MW install. For multiple installs, the archive is better.
The core, unless I get a lot of complaints, will remain in an archive. I can probably set up a small tool to create the registry stuff and make an archive version, but that's not a priority yet (the installer doesn't conflict with anything).

I cleaned up some of the background stuff, although it's not obvious yet, but it makes shader chains and multipass shaders simpler and more efficient. The RTT setup for shaders appears to work properly, so as soon as the test versions are generally working, I'll start testing that.

Anyway, more stuff being added to log any issues, another test copy out as soon as those get in.



Well, I know part of the dependency chain was off. Gem wasn't set as dependent on the core, so that might have been part of the problem. I updated it last night, not sure if that's been pushed to the repo yet. I commit after I do anything big or a few small things, and try to push it to the repo every night (if I made progress).

You might want to check the log and see if anything failed to compile.

The target name problem I think is an issue between 2008 and 2010. In 08, I didn't see an easy way to change $(TargetName), so I just added the _d to the name in the linker properties. Anyway, it's supposed to do that and making the files have a different name helps with some stuff, so that shouldn't be an issue. I think build order is more important. All the paths should be relative within the solution, because it worked without changing them when I reinstalled XP and changed partitions.

Voodoo is dependent on Boost and nVidia's Cg toolkit at the moment, with some parts needing GLEW and the DirectX SDK. One of the utilities also uses .Net, and I'll be using DevIL and TinyXML before this is all said and done.


Actually, I think that might work. Not entirely sure though. The only connection between Gem and the core is an adapter class and some calls. The adapter is an interface and the calls are all exported. Having them all as debug does have a few benefits though, since exceptions thrown are almost guaranteed to be logged.


I'll add you to the list. I have the same problem with MGE, so...

The slowest part of the MGE is the water shader, four textures and some dependent reads. Turning it off increases performance a lot.