First off excelent critiques! BloodRayne had some excellent points, please don't deter anyone from speaking their mind
Ok, soooo looking at this post, a few things sprang to mind. The first is that your screenshots are showing off nothing. Its one thing to show art when you can't do it, and thats perfectly fine, not everybody is a full time dev work force... but the pics were so small, I can't see anything. Even on the level editor shot, I can't read anything.
So, lets get down to it.
POM - How is it done? Why in the alpha? I know its cheaper, but that means you can't have alpha masking on POM surfaces. How many stagse does this add to the material and whats the overdraw like? What are your parms set up like in the material? Scale, steps, min distance & max distance I presume?
Right now thats based on the alpha channel in the material, but you just brought up that I should have these setup on a per-material basis. I put in alpha of the diffusemap as a hack nasty diffenetly will move into the normalmap(I wanted to save a texture unit there is no reason to have the heightmap as its own texture).
Defered Shading - I can't see anything or tell anything. At all. The screenshots terrible.
Post Processing "Stuff" - Is called a lot of things, LUT, colour grading etc. But whats the interface like? Is it set up per area I imagine? Whats the cross fade between volumes? How many options are there? Standard options I would expect are Bloom contrast, bloom threshold, base intensity, glow intensity, RGB control of shadows, RGB control of highlights, RGB control of midtones, RGB min output, RGB max output, RGB control over saturation levels, RGB control over the tint, and control for loading external .LUT look up files for colour grading. Bog standard stuff there.
Completely agreed this wasn't ment for artists to look at : ), programmer art FTW
Editor - Some of those editor changes are... Stupid. Why remove .lwo/.ase etc support, when those are perfectly fine examples of model formats to work with inside the editor? Just a total step backwards...
FBX is industry standard as other people have said there is no reason to support the other formats, basically just felt like deprecated code.
GUIs - You know why they made the GUI that resolution, don't you? Theres NOTHING stopping anybody from making a GUI with uber resolution that looks pixel sharp on 1080p sets. Not a thing. The reason they made it 640x480 is that its devisable easily, but more importantly its a minimum resolution for the game to look acceptable at. This means that dropping to 640x480 will still render everything correctly on the GUI side. You increased it to 1280x720, which is a totally strange choice because it now means you need to be in 720p quality or else the HUD, GUI and everything else 2d will fuck up. That cuts a HUGE number of players out who run not only in sub HD resolutions for speed, but also 16:10, 4:3 and 5:4 etc etc resolutions. You should have stuck with 640x480, and just created wide screen scalable GUI's that can be positioned based on aspect ratio and user need.
I haven't met a person in years that didn't have a 1080p monitor and odds are anyone atleast playing my game won't be the casual gamer(i.e. Mommy
). so for me its a non issue : ). 640x480 GUIS look nasty and right now in a lot of places in the engine it was hardcoded so that could be the highest res guis possible, I just simply upped it to a widescreen ratio; In my opinion looks better.
I dunno about this moving towards something that people would use thing is even right. The problem with the Doom 3 code isn't that its lacking, its that its messy. People can add stuff as they wish, but at the moment you seem to be adding useless half done features, and removing things at will because it won't fit your project needs, but then saying its something for people to use instead of the actual Doom 3 code base? That doesn't make sense to me, and seems a tad counter productive.
Its moving the codebase to match where the industry is going, which does mean cleaning up the code(and removing deprecated features, and file formats). The editors are nasty and clustered. What I also plan on doing is having per-material GPU shaders(like in Unreal), which would open up the engine for a node based material editor. Its all about streamling the toolset to make it more productive.
So will FBX basically become the modeling standard for your WORLDSTUDIO? With animated FBX models becoming the MD5 equivalent? That might be good not to sure yet. It will just be easier to get models from blender to id tech 4.
No FBX will just be what the engine IMPORTS to convert to MD5(opens up a bunch of other modeling packages besides Maya).
Did your removal of ASE and LWO support have anything to do with the issues relating getting models to work that are exported from blender?
Basically the removal of ASE/LWO came from the fact compared to Unreal or Unity its a pain in the ass to get assets into idTech4, and I just figured that artists know how to export to FBX, which would make the toolset that much more appealing to them. Basically there isn't FBX support in the model loader, all FBX is for CONVERTING to either a skeletal MD5 or a static mesh MD5(NEW format that gets generated from a FBX). The FBX support is only in the toolset, the fbx sdk alone adds like 10megs to the final binary :/.
What I really is a artist to help dev assets, my screenshots depict programmer art which doesn't fully demonstrate what the code is capable of doing.