As some of you may have caught, I haven't been exactly pleased with the development of MGE lately. The details are rather technical, but it's been getting to the point where I can hardly use it. Considering most of my releases are shaders, that doesn't work so well. A while back I undertook creating a similar system for Neverwinter Nights; that project went quite well and the shader framework there ended up being a good bit more powerful and flexible than MGE's. After that experience and success, and thanks in part to questions from some of the folks that hang around, I decided to bring my new system back to Morrowind. I now have it working enough to post WIP threads.


What is Voodoo?
The Voodoo Shader Framework is a system designed to add special effects and enhanced graphics to a variety of games. It improves the look, and sometimes speed, of old and new games. The goal of Voodoo is to provide a unified, uniform and consistent target for adding shaders to almost any game.

At this time, Voodoo has been internally tested in Morrowind, Oblivion and Neverwinter Nights 2. Screenshots from each can be found toward the end of this post.

The entire Voodoo project, including all game adapters, is open-source. If any programmers or shader artists have questions or comments as to the specifics, please get in touch with me.


What is Voodoo/Gem?

Gem is the adapter for Morrowind. It handles the details of using Voodoo shaders in the game.

At the moment, Gem is set up to use a single shader for testing purposes. Once I’ve made sure everything works properly, a user-configurable list will be used. Gem will also support advanced materials (shaders applied to objects in-game, providing current generation rendering effects).


What features does/will Gem have?

Voodoo and Gem provide a comprehensive system for postprocessing and material shaders, including automatic parameter and texture linking and shader render-to-texture features. In simpler terms, that means fullscreen and per-object effects are possible, as well as shaders using or creating textures used in-game.

Gem will provide a distant land system comparable to MGE’s. If possible, they will use identical files (to make transitioning between the systems easier).

Gem will not break Morrowind’s water shaders and will allow players to keep using them, although it will provide optional enhanced water effects of its own.

Thanks to a few tips from Hrnchamd, Gem will support shadows from distant land and, if all goes well, near objects as well.

Gem will be integrated with MWSE, v0.9.4a or better, to provide script access to the shaders, land, water and other effects. Script commands will, if at all possible, be byte-by-byte identical to MGE’s MWSE commands, so that scripts won’t have to be recompiled. Additional script commands, to handle material shaders, dynamic parameters and textures and other Gem-specific features, will be added.


What’s the difference between MGE and Voodoo/Gem?

MGE was designed as a Morrowind-specific shader system, and has been developed over the course of several years by a number of developers (myself included). While an excellent and innovative project, the code has suffered over time, as most does.

Gem is intended as a faster, more stable and cleaner re-imagining of the MGE concept.

Without MGE, I wouldn’t be involved in this and Voodoo would not exist. It certainly deserves a tip of the hat. :foodndrink:

Voodoo/Gem is faster than MGE. It will be more configurable, and turning a feature off will actually mean it gets turned off and has no FPS hit (something not guaranteed in recent MGE builds).

Gem provides a powerful shader system, taking advantage of the full syntax of the Cg language. MGE uses a subset of the HLSL language (there is no practical difference between Cg and HLSL, except that HLSL is DirectX-specific). Gem does not make use of archaic magic names, like MGE’s “texture thisframe;” and similar; instead it uses proper annotations to allow shaders to reference textures as needed. This allows shaders to access not only Gem’s textures, but to use game-loaded texture or create their own.

Gem will use a two-target rendering system to provide depth information to shaders (the color and depth buffers will be drawn simultaneously by a single shader). MGE caches renders and redraws them, causing a significant speed hit and memory increase. On systems not capable of using multiple render-targets (very old cards), Gem will fall back to a two-pass render method.

Gem uses a shader system spanning multiple games, and even graphics APIs (Voodoo works with both DirectX and OpenGL). A single target is provided to developers and artists; this means any shader written for Voodoo/Gem will function in all Voodoo-supported games. Having more games supports means a bit more work, but it also means more people testing the system and writing shaders for it. There’s no reason for MGE, OBGE and NWShader to all use different systems for the same thing (the Voodoo project was born from the fact that I was fed up with the little incompatibilities).

Voodoo also opens a new family of effects, using the shader-based render-to-texture system. Shaders can create or modify game textures on the fly, making overlays or reactive environments a very real possibility. I’ve only started playing with some of these effects, but they allow for such things as dynamic raindrops on the screen, world textures reacting to the player or scripts, or even letting the player paint a picture ingame.


Screenshots
Most of these are little things so far, just test shaders and patterns to demonstrate the system works. As I get more code together and things more complete, fancier screens will be available.
Morrowind:
A delayed picture-in-picture with a color shift:
http://i4.photobucket.com/albums/y145/peachykeen000/Voodoo/Voodoo_GEM_16.png
http://i4.photobucket.com/albums/y145/peachykeen000/Voodoo/Voodoo_GEM_15.png
Fullscreen:
http://i4.photobucket.com/albums/y145/peachykeen000/Voodoo/CopyofGEM_2.png

Oblivion:
http://i4.photobucket.com/albums/y145/peachykeen000/Voodoo/ScreenShot8.jpg
http://i4.photobucket.com/albums/y145/peachykeen000/Voodoo/ScreenShot15.jpg
http://i4.photobucket.com/albums/y145/peachykeen000/Voodoo/ScreenShot16.jpg

Neverwinter Nights 2:
http://i4.photobucket.com/albums/y145/peachykeen000/Voodoo/nwn2.jpg

(the NWN module isn't ready yet, as it takes a bit more infrastructure)


How can you help?
At this point, I need people willing to help test. You should have a semi-functioning computer and Morrowind. Testing pretty much consists of downloading the latest files, running Morrowind and telling me if anything goes horribly wrong.

Having a variety of systems to test on is important for stability. Everything from Windows 2000 to 64-bit editions of 7 can help make sure there are no nasty little bugs in Voodoo.
I am setting up a bug-tracker and merging my MGE shader forum into a larger forum, both will be used to support Voodoo.

There may be some issues with the Steam releases of Morrowind, I’m unable to test those myself but will be trying to get in touch with the folks at Steam to see what I can find out about their setup.

If you are a code or shader developer with any interest in contributing, or just questions, please get in touch.

If you don’t fall into any of the above, cheering on, suggestions, comments and general encouragement are also welcome.

How come you never mentioned this to me? And I would gladly test this!

One major question though, you said it's faster. Does this mean that even on my crappy system (2GB RAM, single core processor at ~2.2GHz and ~800MB of graphics memory) I could run some pretty good shaders and what not instead of just using it to bump my resolution to 1280x800?

I could test out how it works with steam for you.

I finally buy a PC powerful enough to run MGE and everything i throw at it and then you come up with this - i want to cheer you on but somhow i feel self - deflated

What will this mean for mods like Vurt's grass?

I don't mind testing this. I don't have a 'Morrowind' installation though, just a 'TC' installation...

I'd be up for potentially testing this in the near future, after my work on the mod-pack is done. Does it support, or will it support the features like animated grass? Conditional full screen shaders that are easy to use? i.e. to add things like a drunk effect to the game, or what-have you (that would only be on while drunk and not eat up FPS the rest of the time)?


It does sound pretty brilliant

Emphasis mine. This part very much makes me want to learn how to write shaders... assuming that one could dynamically link shaders to objects through scripts, you could create some pretty neat magic effects. Amongst countless other applications, of course.


Best of luck with this and I'd be happy to help with testing. Projects like MGE XE and Voodoo are rather exciting.

Edit: Double post.

Count me in for testing :drool:

Wow. this will be interesting. how far along are you? For efficiencies sake I hope this comes to completion, my computer will probably run this rather well .

It depends. Shaders do still cause a FPS hit, that's unavoidable. By doing a clean rewrite and knowing where I'm headed from the bottom up, I can optimize things better than MGE (which kind of twisted and turned on the way). My DX8.9 layer has no noticeable performance hit and fixed a few small bugs that may be present in MGE's, so it should run a bit faster. You won't see magical FPS boosts and no drop while running 900 shaders, but speeds will be improved.


Awesome, I'll throw you a test copy as soon as I get release build of that together.



Heh, sorry. As for mods like Vurt's grass, I plan on supporting all major MGE features. The more complex ones will take more time, and I may rework some things to be more efficient (like allowing external data files to define some texture and placement info), but distant land, batched grass and whatnot are all on the list.


That's not an issue, as long as it uses the Morrowind engine relatively unmodified (things like the code patch don't matter).


It will support animated grass and trees, as part of the "all MGE features" goal. Conditional shaders will be usable through a flags setup or by scripting them to turn on/off.


I'm not sure how well linking shaders to objects through scripts will work, but it should be possible (not something I'd considered before, actually). Linking shaders to objects before-hand and then manipulating the shader settings through scripts is certainly possible.

That also opens some of the simple things we can't do at the moment, like normal/parallax maps, velvet and fur effects, typical shaders.


I have an internal (meaning unstable and prone to change) test copy. The core appears to be stable and is certainly functional. The Morrowind bindings have been working (on and off ), the Oblivion bindings seem to be working but I'm getting in touch with the OBGE devs, and the NWN2 bindings appear to be working but are still a WIP. Very little done with NWN1 bindings, and the Anachronox and Bloodrayne bindings are still on the drawing board.
The screens I posted are from test copies, so they show shaders running in-game just fine. I held the announcement off until I had visible progress.

Ok, on my PC Knu's SSAO shader drops my FPS from 60 to 3, and truebloom g6_i6drops it down to like 8, so with Gem could I run either of those? (when i run all of the shaders you packed into the file on the shader library i get 0.12 fps)

Best of luck with this :goodjob:
And because we were allowed to make suggestions...
Could you implement proper horizons? http://en.wikipedia.org/wiki/Horizon

As an optional thing of course. :cookie:

Sounds awesome

Could it possibly support KOTOR1/2/Jade Empire in the future (same engine as NWN i believe?)

Best of luck to you.

I knew you were working on something for NWN 1 but I wasn't expecting you'd head toward something like this. It sounds great. Good luck to you!

I'll definitely help test this baby out, and I can't wait to see what you have cooked up. I really need to buckle down and learn programming so I can help with stuff like this. I recently tried learning some c++ (but got svcked back into morrowind), the biggest problem I had with trying to learn programming was the language that was used to explain some of the most basic of processes in coding was way over my head and I got the impression that the guide I was reading was written for people who were already fluent in C or some other language. I would very much like to find a guide that has the technical explanation, followed by the same explanation in caveman speak.

Anyway I've gotten way off track here, keep up the good work, and I wish I could do more to help.

This is great stuff and will help this game last all that much longer.(Sometimes it strikes me that this game will last for so long we will have holodeck technology before itgoes away.)

I will ask the most difficult question now. What kind of time frame can we expect on this if you were to continue working at your present speed. I by no means expect a solid time table but a rough estimate would be great.

Anyway you could make it support billboards for distant land?

I'm studying computer science and took some c++ and I thought that getting started was the hardest part. Once you first get the basics down I thought it was much easier after that so just stick to it and hopefully you'll get it.

So how do the velvet fur effects work? Does it apply across everything or can you make it work on only specific meshes/textures? Obviously am thinking of cloth in the game.

Both those effects are very, very expensive in terms of per-pixel computations. From my tests at this point, FPS will increase, but you won't magically get all of the speed back. Gem will still have a speed hit, and it will vary based on features and shaders. Hardware will have some effect, since some of my optimizations require features MGE doesn't use. These are usually present, and I'll provide fall-back paths when they aren't, but the fallback will be slower.


I'll have to figure out exactly how I'll be rendering distant land, but I expect working a formula like that into the far fog distance would be relatively simple (particularly with my current concept).




In theory, yes. It's designed to work with as many games as possible. I already have quite a list I plan to support, ones I enjoy or would like to play with.

Current games with planned support (and % chance of it happening):
Morrowind (100%)
Oblivion (100%)
Fallout 3 (99%)
Neverwinter Nights 1 (100%)
NWN2 (100%)
Anachronox (I think a MW-like DX8.9 system would work, so 80%/probable)
BloodRayne 1 & 2 (80%/probable)

I'm open to suggestions for any other games. If I don't have them, I may be able to pick up a copy, if not, I'd have to do what I can and rely on testers. In my opinion, the more games supported, the more value the entire system has and the more people it will benefit, so I'll be dedicating more time and effort to improving it.


Aye, the success of the NWN 1 version surprised me, and I'd been having occasional multigame system requests for some time. Once I found a good way to do it, I started in and here we are.



If I continue at my current speed and don't run into any major issues, I'll be sending out a basic test copy of the Gem module to Morrowind testers within a week. I ran into a slight bug with Windows a minute ago, so that timeframe is very flexible. I don't get paid for this, so I can't dedicate all my time (need to search for work on the side ), but I do enjoy it and spend as much time working on it as I can.

The core module is in a working and apparently stable state at this point, and the shader linker is functional and has most of its features, although not entirely complete.
The MW module appears to be working in the basics, I need to iron out an issue with the hook and do some quick internal testing before I start alpha testing.


Yes, that is possible.


Definitely. Some things seem crazy complicated at first, but eventually you make sense of them and once it sticks, you can start putting them together in some fun ways.


How I have the material system set up at the moment, it is connected to texture name.

When the game starts, my code checks a folder of material definitions. Any properly formed XML files it finds are loaded and added to the material map, ordered by name. When the game loads a texture with the same name, my code loads a shader. Whenever the game uses the texture, I jump in and make it use that shader as well.

To set up cloth in-game, you'd just find a shader (let's say it does a velvet effect and is called velvet.cgfx) and add a little file to the material definition folder like so:

Now, you can tweak the shader by changing parameters, so you could use one shader for many velvet colors, or include all the materials for your mod in one file. Anyway, that's the basics of it. Like everything (almost ) else about this project, I'd love suggestions from you all. You'll be the ones using it, after all. I made this so that, as a shader designer, I could have everything I wanted in a system. I'm not a fan of using restrictive setups, so any feedback is absolutely welcome.

Edit: I also have a velvet shader already set up and working in CgFX, so for this particular situation, that code snippet is literally all you'd have to do to set it up. I've tested the system a bit in my NWN project and it works pretty easily. I'm upgrading it for this one, but hopefully it'll be as easy to use. It also doesn't get in the way if you don't use my setup, like MGE's rarely-used hook system.

And a post I missed:


You're probably right, but once you get the hang of what the patterns are and how they fit together, things start falling into place beautifully. You're welcome to take a peak at my code, of course, and toss over any questions. No promises it'll be easy to understand, some of this can be messy stuff, but I try to document it decently.

Sending PMs with a basic alpha version to a few folks now for testing. If it works for most of them, then I'll post it here or PM it to everyone who offered to test. It works great on my system, but that's no guarantee of anything, so we'll have to see.

Don't forget me PK.

Guess i'm not cool enough :frog:

Can't wait till you finish this. Is porting to other games difficult? It seems like sprucing up some older games and replaying them could be a lot of fun.

Nah, nothing like that. I'd just like to make sure it works for a few people before sending it out to everyone and getting 35 identical error reports for some little thing I missed. Especially since some of the testers have been having problems getting it set up.

As for porting to other games, it really depends on the game. DirectX games tend to be much simpler than OpenGL. I already have generic setups for DX8 and 9, so it just takes copying those and tweaking them a little for the game's specifics. Being able to port it around for many games is my goal, just have to get the basics working solidly.