I hope this is a good place for a post like this.

Maybe it's too soon?

I’d like to begin by mentioning that I'm an Id fan and have a huge amount of respect for the people there especially John Carmack for releasing Id Software’s engines to the community, and of course the community here – sure there are some people who don’t make a lick of sense (maybe I'm one of them?) but it’s all about learning and supporting people as they grow. On that note I think as a community it would be great to organize this time in creating something everyone can benefit from together. So if the past is any indication of what will happen we’ll see a lot of different projects spring up, each offering something very useful but not all in one place. So what I’m proposing is to organize everyone who is planning on this from the get-go and build on top of a standard base from which everyone can contribute and benefit from while minimizing the amount of redundancy present is past ID Tech GPL engines (See Quake Family Tree - welcome to Forkville).

In short, a combined community effort to update the engine and tools to something that will benefit everyone who wants to use it now and in the years to come and since the GPL code will have issues regarding the shadow implementation it’s a safe assumption that either a slower solution will be put in before release or just removed outright and left up to the community which will instantly require intervention to solve before anything can even be used. So a standard community maintained Id Tech 4 GPL engine simply makes sense in this regard.

In long:

The following is my wish-list for what I would like to see happen to the GPL Id Tech 4 engine and tools when or even if it’s released. This list is just a start, by no means finished but if there’s interest in this it would be cool to maybe sticky this post and add to it through brainstorming, adding/removing items and that sort of stuff?

The bulk of the modifications are all easier said then done however keep in mind it’s just a wish-list and if something like this becomes a reality I wouldn’t expect everything here to happen – right now it’s just fun to think about.

The goal of this project would be to act as the foundation for any GPL Id Tech 4 based engine for anyone who wants to use it. The modifications should remain as backwards compatible as possible so as to not break compatibility with the existing game (see the Dark Places engine for an example of what I mean by advanced features + backwards compatibility). That is, to allow the new engine to be used to play through Doom3 with some of the additions while supporting new features that mods, tc’s and even new games can take advantage of.

So far there has been some amazing stuff by people in the community like Tr3b, Sikkpin, Denton, Venom, and others – sorry if I didn’t mention you as this was just off the top of my head, I know there are many more but this is just an example. It would be awesome to have you guys collaborate on a common project like this.

RENDERING
Aside from updating the various rendering paths to include more advanced hardware (while maintaining backwards compatibility on lower end specs), the goal is to add as many modern advances while keeping in mind frame rates in actual game-play scenarios (i.e. if ‘feature x’ runs great in an empty room but completely chokes during an actual level it’s probably not going to help anyone).

Lightmaps/Deluxemaps:
I always figured this would be one of the most pipe-dream like items on this wish-list. A massive performance boost is gained while rendering quality can be improved as well, a lightmap compilation utility can either be integrated into the engine and run via console or used externally (in both cases probably some modified version of q3map2). Naturally with this comes a slew of other things like new material keywords for static lighting, multiple uv maps for world surfaces and of course some sort of light grid for models (or else in a static only map models would be black against a lit world) or perhaps a precomputed radiance transfer using spherical harmonics?

Dynamic lights would still exist as we’ve all come to know and love them. They would simply cast over a backdrop of precompiled lighting. Some games simply benefit better from precalculated scenes.

I propose a setting for lights in the editor marked with static to be used as precalculated, editor performance might suck when placing many static lights but its in-game performance we’re worried about and there are many things that can be done to speed up editor performance.

Surfaces would need a lightmap resolution parameter as well as static meshes that would make use of them, unless defined as a global in worldspawn which would be terribly inefficient. A material keyword ‘nolightmaps’ would also be good to tell the compiler of surfaces that don’t need processing allowing further optimization for materials.

Don’t want to use lightmaps? Then don’t, but at least the option is there for projects that would benefit from them.

Deferred Shading: Seems like it would make sense in an engine with heavy uses dynamic lights heavily?

Improved Ambient Lighting: Already achieved to some degree, it would be ideal to have permission of use and further testing on many different hardware configurations to improve any performance and compatibility issues.

Ambient Occlusion: For one would greatly improve the visual quality of scenes and second to give a more natural look which work great in conjunction with soft shadows – this is an option that should be able to be turned off to increase performance on lower end hardware.

Soft Shadows: I would recommend a balance between quality and speed for various hardware configurations, lights would probably need a lot more options for different shadow resolutions. I’m guessing some sort of VSM solution.

HDR: It’s HDR!!! *boner*

Bloom, Depth of Field, Motion Blur and other post processing effects: Again this is also something that already exists in one form or another. Currently however it’s a matter of permission of use, integration, testing and improvement.

It should go without saying that everything needs to be tested on as wide a range of hardware as possible to work out any bugs.

Portal Skies:
This has already been achieved to some degree and it would be nice to have permission of use or even have further contributions for the community effort.

Local Cubemaps/Scene Capture points:
See Source Engine env_cubemap for details. It’s a good cheap way of making reflective surfaces look as though they belong in an area. Surfaces are updated based on the nearest the cubemap location. Under the specular map it could use a keyword that could be used to tell the engine to apply the cubemap which would have to be kept at a lower resolution however an option for size within the entity would be good for flexibility depending on the amount of detail the developer wants to capture.

Improved MegaTexture:
While probably not able to achieve the same level of mega texture found in ID Tech 5 I believe at the very least some sort of reasonable support be brought to the engine through better compression or maybe new tools to allow an easier workflow?

OPTIMIZATION
Possibly one of the most important things to be focused on would be increasing scene detail while maintaining scalable hardware requirements. That is, get more for less :wink:

Level of Detail: LOD is the lifesaver of performance; scenes can have more detail and higher performance with clever use of an LOD system. Being able to have multiple reference meshes that can switch detail based on distance would greatly increase performance and allow more models on screen at once.

LOD for materials: New material fallbacks that can switch materials based on view distances. This would work ideally with surfaces that require heavier processing than a simple static texture – maybe there’s something like this already in there?

Shadow Meshes: Low polygon shadow meshes used for projecting shadow maps would cut down considerably on performance requirements while maintaining a high level of graphical quality. This has already been done through materials and modifying the base reference model. The shadow mesh can be built in with the reference meshes so shadow mesh complexity can be reduced with LOD models.

LOD example in def:

Code:

entityDef mymodel {

…

"model" "models/mymodel/mymodel.xxx"
"model_lod1" "models/mymodel/mymodel_lod1.xxx "
"model_lod2" "models/mymodel/mymodel_lod2.xxx "
"model_lod3" "models/mymodel/mymodel_lod3.xxx "
…
}

TOOLS
The right tools for the job are very important and not counting all the built in stuff that comes with ID Tech 4 here are some ideas for tools or improvements on tools that may help aid developers.

DoomEdit/Radiant:
There are already several custom Radiant versions available, and I can understand the need to use a custom Radiant because of the cross platform functionality however it would be ideal to keep any additions within the built in Radiant since any new rendering features would automatically be reflected in the editor since it shares the same renderer and wouldn’t require twice as much work, however since there will inevitably be another custom Radiant for cross platform functionality (unless this can be added to the internal version – a lot of work) this would need a dedicated person or people to maintain. I’m not against it but this is just my opinion on the matter.

Collada or 3DStudio Max MD5 Tools:
If Something like COLLADA is not an option or if there is a good argument against it then better support for the 3DS Max MD5 Exporter should be looked into. I think Der_ton has done an excellent job however it would be nice to see multiple mesh support with the Max exporter (without the need to attach) since I think next to Blender; Max is the most popular choice of tool for most members of the community here (I’m a Max user myself but I’m trying not to be biased in my wish-list).

Model morphing:
I listed this under tools because it would require a new exporter or format which is tools related, and also because I really couldn’t think where this would fit in. Morph between a number of frames in a reference mesh/multiple reference meshes - used for lip-sync, facial expressions, vehicle/character damage, and more – see Source and UE3 for examples of this.

Morph data would be stored either in multiple reference meshes or in a single reference mesh with each frame representing a unique morph (eye blinking, facial expressions, lip-sync, damage etc…) – it would be best to use the latter. This data would be accessed through scripts for lip-sync.

Model Viewer: Aside from viewing models and animations this tool should also allow reassignment of materials to the ASE and MD5 meshes. It wouldn’t hurt to have a plethora of debugging and statistical information and well

Lipsync Tool: Even if some sort of auto generation is out, having a lipsync tool to create phoneme timesheets would still help greatly over manually editing in a 3D application. JLipSync seems like a good choice however it would be nice to have some input on.

Documentation:
A well documented and maintained Wiki and editing docs, not only organizing existing knowledge but maintaining new features as well would have to be mandatory as there’s nothing worse than out of date information. Modwiki is a great resource, it would be excellent if this projects documentation was hosted there as part of an official ID Tech community engine (if it happens that is).

GAMEPLAY
The real meat of the game is found here, great graphics won’t save you if your game isn't fun. So what can be done to help developers enhance the game play experience, primarily I’m going to target single player but there are certainly things that can be done to MP – I’m just not going to cover that in this wish-list.

Enhanced Physics: ID Tech 4 comes with a complete physics solution however some would argue it’s not that great so I would recommend either extending the existing system or integrating some sort of open source middleware to compensate for the demands of more physical worlds and simulations – suggestions?

Breakable physics objects (Physics):
You have to admit it is fun blowing stuff up and watching pieces fly everywhere. I don’t think I need to go into too much detail but the process would involve creating objects and their fragments which are spawned in their place when the object explodes or breaks. The pieces would be physically simulated and in all probability have their origins modified to spawn in proper place if that’s supported.

Enhanced AI (tethers, teams):
It would be nice to build upon the senses of sight, smell, and hearing for AI to sense dangerous areas, track the player or to give some AI only 1 or a few senses like hearing – not difficult really. Tethers work great to have teams hold down certain areas and teams that can act as one and communicate with each other to challenge players even more would be an amazing toolkit to have for designers. This has already been achieved to some degree and it would be nice to have permission of use or even have further contributions for the community effort.

Water (rendering and physics):
Yes, water has been achieved to some degree however it's a matter of testing and making sure everything is there for what would be considered a full implementation on top of which a way to combine water into a material with both refraction and Fresnel reflection would be a plus as well as water LOD where it can switch to a local cubemap once a certain distance is reached to save on performance.

Along with offering an enhanced way of playing through Doom3 it might be cool to see a special mission pack made that takes advantage of all the new features of this engine to act as both a showcase and as reference material to accompany the documentation. The mission pack would be a great way to involve everyone (non-programmers) from the community.

My question is, does anyone foresee any interest in combining efforts in such a venture or does anyone actually see something like this coming together independently?

edit: cleaned up post a bit, added lightmaps (I left it out to avoid the "Oh nos, sum of teh shadows are precalculated.. tis game sux now" conversation which happened anyway so there they are on that note http://pages.cpsc.ucalgary.ca/~bdstephe ... llzone.pdf has some interesting points like on page 6:

Gamer : Oh, Crap! Look at all those bad guys!
Rendering Programmer : Oh, crap! Look at all those dynamic lights!

Mr.Spline wrote:

I hope this is a good place for a post like this.

GAMEPLAY
The real meat of the game is found here, great graphics won’t save you if your game isn't fun. So what can be done to help developers enhance the game play experience, primarily I’m going to target single player but there are certainly things that can be done to MP – I’m just not going to cover that in this wish-list.

A decent MP with 64 player slots and new/optimized netcode will be good. Also a stable CO-OP will help a lot

Edit: And graphically, optional Lightmapping (ala quake 3/source engine). It will improve a lot for static lights (atmosphere) and the dynamic ones just soft edge stencil shadows

I would love to see a combined effort on this when the source is released. I agree with all your points and have a few of my own I'd like to add...

Material Shader Improvements
We need more compositing options for multiple images in a single stage. It's sad that the only way to achieve this now is to bake simple animations that utilize more than one image into ROQ movies.

Transparency needs fixed. We need alpha blended transparency support in the interaction shader. Alphatest isn't good enough. It looks like trash.

Cubemap reflections don't respond to animated normal maps.

I would really love to see a node based tool even if nodes were only representative of the existing and underlying material shader markup as the markup can be expanded to accommodate a more modular approach.

I also would like to see high level shader language support like GLSL. I've never been able to make sense of ARB.

Internal Model Tweaking

We need a way to be able to diagnose and fix problems with models from within the engine. It's not enough to export something, test in it game and tweak ad-nauseam. It would be nice if we could make minor adjustments to a model in engine. Nothing extravagant. Just the ability to adjust vertex normals, check seams, assign materials, and save changes.

Radiant
Broken shaders, entities, etc... shouldn't even show up in the list.

The list of Key/Value pairs should be derived from the engine internally as opposed to pulling editorvars from declarations.

good points, if i've read right, you mean there should be a central project for expandign/tweaking etc the engine but let it be backwards compatible, like everyone now uses the same .exe (mostly) without having 100forks which all implement same features in a different not compatible way, so everyone likes using the engine has a central place?

Id (or most probably some1 else) could maybe create some kind of http://www.id-community-engine.com and release the source there and creates a community around it. That should be setup long before the source is released cause if not the source will spread and have soon multiple placed where its been modified etc. (just thinking of a site where there is a core engine development team which extends, tweaks etc. the engine, a second place with a "patch-repository" with several new things from people like new effects etc which are still not been ported or wont be ported into main trunk, and a third place where people can easy create a project, get an svn and got their tools for everything they need for modding the engine. This will automaticaly create a nice community around that, and a central point for all modders and devs to communicate. Sure, there is this forum. But its not more as a forum, where people write if they have problems or sometimes release something... but you know what i mean.

Just brainstorming.. :-D

Like it or not, comment it or just mark it as trash :-D

On the subject of improved ambient lighting being achieved already, while true it is somewhat performance intensive on lower end systems. Mainly because the calculations are run on all lights, not just ambient lights...but that's a fault of D3 having a single, unified, interaction shader. When the code is released, ambient can be split off from the rest and performance gained.

*support for vertex animation (opens up so many possibilities...)
*fix the sprites
*ability to bake shadows

that's all I can think of...

I'd like to see a couple things:

1. Multicore support.
2. Area-based cube maps
3.Opimized Anti-Aliasing, shit i turn it on 16xAA and i get from 80 fps to like 20 fps instantly.
4.DESTROY THE UNIFIED SHADING ARCHITECHTURE :twisted:

5. I cant think of anything but i put a five down before coming up with something, so im now filling it up with useless info.
6.Dx10/11 or Opengl 3.1/3.2 features implemented? maybe.

That's about all i can think of. Btw we need some hi res textures that look good even when your up close to the damn things..wonder if thats fixable without the gpl being released...hmmm

Why do you guys want light-mapping and baked shadows on idtech4 when you already have that on idtech3 and it is already out? I find it funny wanting old tech in a new engine.

To me the only areas idtech 4 need improvement is:

- A deferred shading render it will enable better ambient lighting and even faking radiosity.
- Soft shadows by using shadow mapping or soft stencil shadows.
- HDR and AO
- A better physics engine Bullet or even Newton (imo no PhysX crap).
- Improving the megatexture stuff.

With this it will be truly next gen engine.

Argoon1981 wrote:

Why do you guys want light-mapping and baked shadows on idtech4 when you already have that on idtech3 and it is already out? I find it funny wanting old tech in a new engine.

I would guess because it looks great and increases performance? It's not that it's old technology and should be discarded, it's a choice by the developers based on the type of game they're making.

If you're doing a horror game where you want to create tension then a unified dynamic lighting system is great because you have everything blending in which Id effectively demonstrated (maybe a bit too much) - granted they still resorted to cheap tricks like monster closets, spawning enemies both in front and behind you and the imp behind the door ready to pounce got old really quick.

The point is, if you're creating a game that won't benefit from a real-time system then why put one in there and waste processing power that could better be used elsewhere? Or toss out light-maps just because it's "old tech".

Argoon1981 wrote:

Why do you guys want light-mapping and baked shadows on idtech4 when you already have that on idtech3 and it is already out? I find it funny wanting old tech in a new engine.

because some times it's better. That's all. I like the option, just like vertex animations. I still want the RT shadows those & unified lighting, love that (if it was gone I'd see no reason to use the engine)

If you want lightmaps, shadow maps, and baked stuff, just use id tech 3 then.

BTW, great topic! Im hoping id annouces the release of id tech 4 as GPL at this year's quakecon. Anyone wanna bet whether they will release megatexture code and quake4 and ETQW's codebases as well?

...oh, and where was water included in a id tech 4 game? Do you people mean that level in the doom3 expansion?

I'd like to take the time to point out that you could, hypothetically, redo physics as-is; I've actually enabled a complete RK4 integrator that was in the source but disabled/unused in the vanilla release. There do appear to be a few bugs (occasionally some collisions will just bring the game to a screeching and immediate HALT) but this may be unrelated. I tossed around the idea of replacing the whole system way back when for my Dentonmod offshoot but ended up deciding against it mostly because I don't consider myself to have an extensive enough background in physics to do a decent job. Though docs are kind of scarce if someone's interested I'd be happy to explain what little I know.

Public enemy number one for me would be adding hardware skinning using geometry shaders (for volume extrusion) and stream-out or whatever the hell the OpenGL equivalent is. You could offload a HUUUGE amount of work onto the GPU. That being said, fuck shadow volumes. They're a piece of shit. We really need to go shadow maps here.

Number 2 would probably be light propagation volumes.

Re: Lit transucents: This is already done. Look at the vagary sac materal. I believe I made some edits to modwiki about this a few months back, actually.

aardwolf wrote:

If you want lightmaps, shadow maps, and baked stuff, just use id tech 3 then.

Because Doom 3 is sooooooo much better for SP.

But then we get in to the "just use engine XXX" then. :p

Quote:

...oh, and where was water included in a id tech 4 game? Do you people mean that level in the doom3 expansion?

I think the only one to do interactive water was ETQW (other had water textures for looks but that's all). The only ones to ever make water that does more then let stuff float is D3W members.

aardwolf wrote:

If you want lightmaps, shadow maps, and baked stuff, just use id tech 3 then.

Why not in id tech 4? (Unreal engine 3/source engine/Id tech 3/...) allows that optionally. If they don't add baked shadows, then it will be a resource hook and another veilfailstein with megalags thanks to processing every useless casted shadows from static lights.
The point is to use both baked stuff and dynamic stuff.

The Happy Friar wrote:

aardwolf wrote:

If you want lightmaps, shadow maps, and baked stuff, just use id tech 3 then.

Because Doom 3 is sooooooo much better for SP.

But then we get in to the "just use engine XXX" then. :p

Quote:

...oh, and where was water included in a id tech 4 game? Do you people mean that level in the doom3 expansion?

I think the only one to do interactive water was ETQW (other had water textures for looks but that's all). The only ones to ever make water that does more then let stuff float is D3W members.

But there are some mods that precisely make quake3 a good engine for SP games. ç

Well, I meant water that you can get into and come out to a different area of the level, like in the q2 dm map the edge. Havent played ETQW so I wouldnt know.

=FF=Sturm wrote:

aardwolf wrote:

If you want lightmaps, shadow maps, and baked stuff, just use id tech 3 then.

Why not in id tech 4? (Unreal engine 3/source engine/Id tech 3/...) allows that optionally. If they don't add baked shadows, then it will be a resource hook and another veilfailstein with megalags thanks to processing every useless casted shadows from static lights.
The point is to use both baked stuff and dynamic stuff.

But wouldnt then id tech 4 look just like id tech 3, with everything predefined ? Wasnt the biggest new feature of id tech 4 its great lighting techniques?

aardwolf wrote:

=FF=Sturm wrote:

aardwolf wrote:

If you want lightmaps, shadow maps, and baked stuff, just use id tech 3 then.

Why not in id tech 4? (Unreal engine 3/source engine/Id tech 3/...) allows that optionally. If they don't add baked shadows, then it will be a resource hook and another veilfailstein with megalags thanks to processing every useless casted shadows from static lights.
The point is to use both baked stuff and dynamic stuff.

But wouldnt then id tech 4 look just like id tech 3, with everything predefined ? Wasnt the biggest new feature of id tech 4 its great lighting techniques?

No, it wouldn't. It's just another feature to it's lighting system.
Please, read all the above post about lightmaps and the posible use of them in id tech 4.
Take a look to this:

Code:

http://i42.tinypic.com/2w6ykpv.jpg
http://i43.tinypic.com/2mdlx6r.jpg
http://www.smokin-guns.net/userpix/19_highres1_1.jpg
http://www.katsbits.com/images/articles/conan/conan_dark_cathedral1.jpg
http://aaronjclifford.com/misc/images/hotdangSecondary.jpg
http://aaronjclifford.com/wip/ga.net_comp%2317_SFAM/screens/scene_wip1_1.jpg

Cheers

TRSGM wrote:

I'd like to take the time to point out that you could, hypothetically, redo physics as-is; I've actually enabled a complete RK4 integrator that was in the source but disabled/unused in the vanilla release. There do appear to be a few bugs (occasionally some collisions will just bring the game to a screeching and immediate HALT) but this may be unrelated. I tossed around the idea of replacing the whole system way back when for my Dentonmod offshoot but ended up deciding against it mostly because I don't consider myself to have an extensive enough background in physics to do a decent job. Though docs are kind of scarce if someone's interested I'd be happy to explain what little I know.

Cool, makes you wonder what other stuff will be buried in the code but disabled. If you are up to it, it might be cool to dump any information you wish to share here that can be archived for later reference? Just a thought.

aardwolf wrote:

But wouldnt then id tech 4 look just like id tech 3, with everything predefined ? Wasnt the biggest new feature of id tech 4 its great lighting techniques?

It doesn't mean everything, it means most or some. In the end though it was just a tool for the type of game they were making and it seems some people got confused and thought from that point on every game had to use nothing but dynamic lights because doom3 was doing it and anything Id does everyone else must do.

Id does exactly what they need to do to survive (see ZeniMax) and for the most part it involved experimentation with new technology. With Id Tech 4 it's dynamic lights, with 5 it's MegaTexture, 6 it's apparently voxels - it's neat stuff but it doesn't mean everyone else is forced to copy that from now on.

edit: came across as a condescending prick

Mr.Spline wrote:

Cool, makes you wonder what other stuff will be buried in the code but disabled. If you are up to it, it might be cool to dump any information you wish to share here that can be archived for later reference? Just a thought.

I know func_springs work pretty well, IF you treat them like rubber bands vs springs.

aardwolf wrote:

But there are some mods that precisely make quake3 a good engine for SP games.

I'm only aware of 1 mod for Q3A that had an actual SP component & not just tier-based combat. Outpost

I hope this is a good place for a post like this.

Maybe it's too soon?

I’d like to begin by mentioning that I'm an Id fan and have a huge amount of respect for the people there especially John Carmack for releasing Id Software’s engines to the community, and of course the community here – sure there are some people who don’t make a lick of sense (maybe I'm one of them?) but it’s all about learning and supporting people as they grow. On that note I think as a community it would be great to organize this time in creating something everyone can benefit from together. So if the past is any indication of what will happen we’ll see a lot of different projects spring up, each offering something very useful but not all in one place. So what I’m proposing is to organize everyone who is planning on this from the get-go and build on top of a standard base from which everyone can contribute and benefit from while minimizing the amount of redundancy present is past ID Tech GPL engines (See Quake Family Tree - welcome to Forkville).

In short, a combined community effort to update the engine and tools to something that will benefit everyone who wants to use it now and in the years to come and since the GPL code will have issues regarding the shadow implementation it’s a safe assumption that either a slower solution will be put in before release or just removed outright and left up to the community which will instantly require intervention to solve before anything can even be used. So a standard community maintained Id Tech 4 GPL engine simply makes sense in this regard.

In long:

The following is my wish-list for what I would like to see happen to the GPL Id Tech 4 engine and tools when or even if it’s released. This list is just a start, by no means finished but if there’s interest in this it would be cool to maybe sticky this post and add to it through brainstorming, adding/removing items and that sort of stuff?

The bulk of the modifications are all easier said then done however keep in mind it’s just a wish-list and if something like this becomes a reality I wouldn’t expect everything here to happen – right now it’s just fun to think about.

The goal of this project would be to act as the foundation for any GPL Id Tech 4 based engine for anyone who wants to use it. The modifications should remain as backwards compatible as possible so as to not break compatibility with the existing game (see the Dark Places engine for an example of what I mean by advanced features + backwards compatibility). That is, to allow the new engine to be used to play through Doom3 with some of the additions while supporting new features that mods, tc’s and even new games can take advantage of.

So far there has been some amazing stuff by people in the community like Tr3b, Sikkpin, Denton, Venom, and others – sorry if I didn’t mention you as this was just off the top of my head, I know there are many more but this is just an example. It would be awesome to have you guys collaborate on a common project like this.

RENDERING
Aside from updating the various rendering paths to include more advanced hardware (while maintaining backwards compatibility on lower end specs), the goal is to add as many modern advances while keeping in mind frame rates in actual game-play scenarios (i.e. if ‘feature x’ runs great in an empty room but completely chokes during an actual level it’s probably not going to help anyone).

Lightmaps/Deluxemaps:
I always figured this would be one of the most pipe-dream like items on this wish-list. A massive performance boost is gained while rendering quality can be improved as well, a lightmap compilation utility can either be integrated into the engine and run via console or used externally (in both cases probably some modified version of q3map2). Naturally with this comes a slew of other things like new material keywords for static lighting, multiple uv maps for world surfaces and of course some sort of light grid for models (or else in a static only map models would be black against a lit world) or perhaps a precomputed radiance transfer using spherical harmonics?

Dynamic lights would still exist as we’ve all come to know and love them. They would simply cast over a backdrop of precompiled lighting. Some games simply benefit better from precalculated scenes.

I propose a setting for lights in the editor marked with static to be used as precalculated, editor performance might suck when placing many static lights but its in-game performance we’re worried about and there are many things that can be done to speed up editor performance.

Surfaces would need a lightmap resolution parameter as well as static meshes that would make use of them, unless defined as a global in worldspawn which would be terribly inefficient. A material keyword ‘nolightmaps’ would also be good to tell the compiler of surfaces that don’t need processing allowing further optimization for materials.

Don’t want to use lightmaps? Then don’t, but at least the option is there for projects that would benefit from them.

Deferred Shading: Seems like it would make sense in an engine with heavy uses dynamic lights heavily?

Improved Ambient Lighting: Already achieved to some degree, it would be ideal to have permission of use and further testing on many different hardware configurations to improve any performance and compatibility issues.

Ambient Occlusion: For one would greatly improve the visual quality of scenes and second to give a more natural look which work great in conjunction with soft shadows – this is an option that should be able to be turned off to increase performance on lower end hardware.

Soft Shadows: I would recommend a balance between quality and speed for various hardware configurations, lights would probably need a lot more options for different shadow resolutions. I’m guessing some sort of VSM solution.

HDR: It’s HDR!!! *boner*

Bloom, Depth of Field, Motion Blur and other post processing effects: Again this is also something that already exists in one form or another. Currently however it’s a matter of permission of use, integration, testing and improvement.

It should go without saying that everything needs to be tested on as wide a range of hardware as possible to work out any bugs.

Portal Skies:
This has already been achieved to some degree and it would be nice to have permission of use or even have further contributions for the community effort.

Local Cubemaps/Scene Capture points:
See Source Engine env_cubemap for details. It’s a good cheap way of making reflective surfaces look as though they belong in an area. Surfaces are updated based on the nearest the cubemap location. Under the specular map it could use a keyword that could be used to tell the engine to apply the cubemap which would have to be kept at a lower resolution however an option for size within the entity would be good for flexibility depending on the amount of detail the developer wants to capture.

Improved MegaTexture:
While probably not able to achieve the same level of mega texture found in ID Tech 5 I believe at the very least some sort of reasonable support be brought to the engine through better compression or maybe new tools to allow an easier workflow?

OPTIMIZATION
Possibly one of the most important things to be focused on would be increasing scene detail while maintaining scalable hardware requirements. That is, get more for less :wink:

Level of Detail: LOD is the lifesaver of performance; scenes can have more detail and higher performance with clever use of an LOD system. Being able to have multiple reference meshes that can switch detail based on distance would greatly increase performance and allow more models on screen at once.

LOD for materials: New material fallbacks that can switch materials based on view distances. This would work ideally with surfaces that require heavier processing than a simple static texture – maybe there’s something like this already in there?

Shadow Meshes: Low polygon shadow meshes used for projecting shadow maps would cut down considerably on performance requirements while maintaining a high level of graphical quality. This has already been done through materials and modifying the base reference model. The shadow mesh can be built in with the reference meshes so shadow mesh complexity can be reduced with LOD models.

LOD example in def:

Code:

entityDef mymodel {

…

"model" "models/mymodel/mymodel.xxx"
"model_lod1" "models/mymodel/mymodel_lod1.xxx "
"model_lod2" "models/mymodel/mymodel_lod2.xxx "
"model_lod3" "models/mymodel/mymodel_lod3.xxx "
…
}

TOOLS
The right tools for the job are very important and not counting all the built in stuff that comes with ID Tech 4 here are some ideas for tools or improvements on tools that may help aid developers.

DoomEdit/Radiant:
There are already several custom Radiant versions available, and I can understand the need to use a custom Radiant because of the cross platform functionality however it would be ideal to keep any additions within the built in Radiant since any new rendering features would automatically be reflected in the editor since it shares the same renderer and wouldn’t require twice as much work, however since there will inevitably be another custom Radiant for cross platform functionality (unless this can be added to the internal version – a lot of work) this would need a dedicated person or people to maintain. I’m not against it but this is just my opinion on the matter.

Collada or 3DStudio Max MD5 Tools:
If Something like COLLADA is not an option or if there is a good argument against it then better support for the 3DS Max MD5 Exporter should be looked into. I think Der_ton has done an excellent job however it would be nice to see multiple mesh support with the Max exporter (without the need to attach) since I think next to Blender; Max is the most popular choice of tool for most members of the community here (I’m a Max user myself but I’m trying not to be biased in my wish-list).

Model morphing:
I listed this under tools because it would require a new exporter or format which is tools related, and also because I really couldn’t think where this would fit in. Morph between a number of frames in a reference mesh/multiple reference meshes - used for lip-sync, facial expressions, vehicle/character damage, and more – see Source and UE3 for examples of this.

Morph data would be stored either in multiple reference meshes or in a single reference mesh with each frame representing a unique morph (eye blinking, facial expressions, lip-sync, damage etc…) – it would be best to use the latter. This data would be accessed through scripts for lip-sync.

Model Viewer: Aside from viewing models and animations this tool should also allow reassignment of materials to the ASE and MD5 meshes. It wouldn’t hurt to have a plethora of debugging and statistical information and well

Lipsync Tool: Even if some sort of auto generation is out, having a lipsync tool to create phoneme timesheets would still help greatly over manually editing in a 3D application. JLipSync seems like a good choice however it would be nice to have some input on.

Documentation:
A well documented and maintained Wiki and editing docs, not only organizing existing knowledge but maintaining new features as well would have to be mandatory as there’s nothing worse than out of date information. Modwiki is a great resource, it would be excellent if this projects documentation was hosted there as part of an official ID Tech community engine (if it happens that is).

GAMEPLAY
The real meat of the game is found here, great graphics won’t save you if your game isn't fun. So what can be done to help developers enhance the game play experience, primarily I’m going to target single player but there are certainly things that can be done to MP – I’m just not going to cover that in this wish-list.

Enhanced Physics: ID Tech 4 comes with a complete physics solution however some would argue it’s not that great so I would recommend either extending the existing system or integrating some sort of open source middleware to compensate for the demands of more physical worlds and simulations – suggestions?

Breakable physics objects (Physics):
You have to admit it is fun blowing stuff up and watching pieces fly everywhere. I don’t think I need to go into too much detail but the process would involve creating objects and their fragments which are spawned in their place when the object explodes or breaks. The pieces would be physically simulated and in all probability have their origins modified to spawn in proper place if that’s supported.

Enhanced AI (tethers, teams):
It would be nice to build upon the senses of sight, smell, and hearing for AI to sense dangerous areas, track the player or to give some AI only 1 or a few senses like hearing – not difficult really. Tethers work great to have teams hold down certain areas and teams that can act as one and communicate with each other to challenge players even more would be an amazing toolkit to have for designers. This has already been achieved to some degree and it would be nice to have permission of use or even have further contributions for the community effort.

Water (rendering and physics):
Yes, water has been achieved to some degree however it's a matter of testing and making sure everything is there for what would be considered a full implementation on top of which a way to combine water into a material with both refraction and Fresnel reflection would be a plus as well as water LOD where it can switch to a local cubemap once a certain distance is reached to save on performance.

Along with offering an enhanced way of playing through Doom3 it might be cool to see a special mission pack made that takes advantage of all the new features of this engine to act as both a showcase and as reference material to accompany the documentation. The mission pack would be a great way to involve everyone (non-programmers) from the community.

My question is, does anyone foresee any interest in combining efforts in such a venture or does anyone actually see something like this coming together independently?

edit: cleaned up post a bit, added lightmaps (I left it out to avoid the "Oh nos, sum of teh shadows are precalculated.. tis game sux now" conversation which happened anyway so there they are on that note http://pages.cpsc.ucalgary.ca/~bdstephe ... llzone.pdf has some interesting points like on page 6:

Gamer : Oh, Crap! Look at all those bad guys!
Rendering Programmer : Oh, crap! Look at all those dynamic lights!

Mr.Spline wrote:

I hope this is a good place for a post like this.

GAMEPLAY
The real meat of the game is found here, great graphics won’t save you if your game isn't fun. So what can be done to help developers enhance the game play experience, primarily I’m going to target single player but there are certainly things that can be done to MP – I’m just not going to cover that in this wish-list.

A decent MP with 64 player slots and new/optimized netcode will be good. Also a stable CO-OP will help a lot

Edit: And graphically, optional Lightmapping (ala quake 3/source engine). It will improve a lot for static lights (atmosphere) and the dynamic ones just soft edge stencil shadows

I would love to see a combined effort on this when the source is released. I agree with all your points and have a few of my own I'd like to add...

Material Shader Improvements
We need more compositing options for multiple images in a single stage. It's sad that the only way to achieve this now is to bake simple animations that utilize more than one image into ROQ movies.

Transparency needs fixed. We need alpha blended transparency support in the interaction shader. Alphatest isn't good enough. It looks like trash.

Cubemap reflections don't respond to animated normal maps.

I would really love to see a node based tool even if nodes were only representative of the existing and underlying material shader markup as the markup can be expanded to accommodate a more modular approach.

I also would like to see high level shader language support like GLSL. I've never been able to make sense of ARB.

Internal Model Tweaking

We need a way to be able to diagnose and fix problems with models from within the engine. It's not enough to export something, test in it game and tweak ad-nauseam. It would be nice if we could make minor adjustments to a model in engine. Nothing extravagant. Just the ability to adjust vertex normals, check seams, assign materials, and save changes.

Radiant
Broken shaders, entities, etc... shouldn't even show up in the list.

The list of Key/Value pairs should be derived from the engine internally as opposed to pulling editorvars from declarations.

good points, if i've read right, you mean there should be a central project for expandign/tweaking etc the engine but let it be backwards compatible, like everyone now uses the same .exe (mostly) without having 100forks which all implement same features in a different not compatible way, so everyone likes using the engine has a central place?

Id (or most probably some1 else) could maybe create some kind of http://www.id-community-engine.com and release the source there and creates a community around it. That should be setup long before the source is released cause if not the source will spread and have soon multiple placed where its been modified etc. (just thinking of a site where there is a core engine development team which extends, tweaks etc. the engine, a second place with a "patch-repository" with several new things from people like new effects etc which are still not been ported or wont be ported into main trunk, and a third place where people can easy create a project, get an svn and got their tools for everything they need for modding the engine. This will automaticaly create a nice community around that, and a central point for all modders and devs to communicate. Sure, there is this forum. But its not more as a forum, where people write if they have problems or sometimes release something... but you know what i mean.

Just brainstorming.. :-D

Like it or not, comment it or just mark it as trash :-D

On the subject of improved ambient lighting being achieved already, while true it is somewhat performance intensive on lower end systems. Mainly because the calculations are run on all lights, not just ambient lights...but that's a fault of D3 having a single, unified, interaction shader. When the code is released, ambient can be split off from the rest and performance gained.

*support for vertex animation (opens up so many possibilities...)
*fix the sprites
*ability to bake shadows

that's all I can think of...

I'd like to see a couple things:

1. Multicore support.
2. Area-based cube maps
3.Opimized Anti-Aliasing, shit i turn it on 16xAA and i get from 80 fps to like 20 fps instantly.
4.DESTROY THE UNIFIED SHADING ARCHITECHTURE :twisted:

5. I cant think of anything but i put a five down before coming up with something, so im now filling it up with useless info.
6.Dx10/11 or Opengl 3.1/3.2 features implemented? maybe.

That's about all i can think of. Btw we need some hi res textures that look good even when your up close to the damn things..wonder if thats fixable without the gpl being released...hmmm

Why do you guys want light-mapping and baked shadows on idtech4 when you already have that on idtech3 and it is already out? I find it funny wanting old tech in a new engine.

To me the only areas idtech 4 need improvement is:

- A deferred shading render it will enable better ambient lighting and even faking radiosity.
- Soft shadows by using shadow mapping or soft stencil shadows.
- HDR and AO
- A better physics engine Bullet or even Newton (imo no PhysX crap).
- Improving the megatexture stuff.

With this it will be truly next gen engine.

Argoon1981 wrote:

Why do you guys want light-mapping and baked shadows on idtech4 when you already have that on idtech3 and it is already out? I find it funny wanting old tech in a new engine.

I would guess because it looks great and increases performance? It's not that it's old technology and should be discarded, it's a choice by the developers based on the type of game they're making.

If you're doing a horror game where you want to create tension then a unified dynamic lighting system is great because you have everything blending in which Id effectively demonstrated (maybe a bit too much) - granted they still resorted to cheap tricks like monster closets, spawning enemies both in front and behind you and the imp behind the door ready to pounce got old really quick.

The point is, if you're creating a game that won't benefit from a real-time system then why put one in there and waste processing power that could better be used elsewhere? Or toss out light-maps just because it's "old tech".

Argoon1981 wrote:

Why do you guys want light-mapping and baked shadows on idtech4 when you already have that on idtech3 and it is already out? I find it funny wanting old tech in a new engine.

because some times it's better. That's all. I like the option, just like vertex animations. I still want the RT shadows those & unified lighting, love that (if it was gone I'd see no reason to use the engine)

If you want lightmaps, shadow maps, and baked stuff, just use id tech 3 then.

BTW, great topic! Im hoping id annouces the release of id tech 4 as GPL at this year's quakecon. Anyone wanna bet whether they will release megatexture code and quake4 and ETQW's codebases as well?

...oh, and where was water included in a id tech 4 game? Do you people mean that level in the doom3 expansion?

I'd like to take the time to point out that you could, hypothetically, redo physics as-is; I've actually enabled a complete RK4 integrator that was in the source but disabled/unused in the vanilla release. There do appear to be a few bugs (occasionally some collisions will just bring the game to a screeching and immediate HALT) but this may be unrelated. I tossed around the idea of replacing the whole system way back when for my Dentonmod offshoot but ended up deciding against it mostly because I don't consider myself to have an extensive enough background in physics to do a decent job. Though docs are kind of scarce if someone's interested I'd be happy to explain what little I know.

Public enemy number one for me would be adding hardware skinning using geometry shaders (for volume extrusion) and stream-out or whatever the hell the OpenGL equivalent is. You could offload a HUUUGE amount of work onto the GPU. That being said, fuck shadow volumes. They're a piece of shit. We really need to go shadow maps here.

Number 2 would probably be light propagation volumes.

Re: Lit transucents: This is already done. Look at the vagary sac materal. I believe I made some edits to modwiki about this a few months back, actually.

aardwolf wrote:

If you want lightmaps, shadow maps, and baked stuff, just use id tech 3 then.

Because Doom 3 is sooooooo much better for SP.

But then we get in to the "just use engine XXX" then. :p

Quote:

...oh, and where was water included in a id tech 4 game? Do you people mean that level in the doom3 expansion?

I think the only one to do interactive water was ETQW (other had water textures for looks but that's all). The only ones to ever make water that does more then let stuff float is D3W members.

aardwolf wrote:

If you want lightmaps, shadow maps, and baked stuff, just use id tech 3 then.

Why not in id tech 4? (Unreal engine 3/source engine/Id tech 3/...) allows that optionally. If they don't add baked shadows, then it will be a resource hook and another veilfailstein with megalags thanks to processing every useless casted shadows from static lights.
The point is to use both baked stuff and dynamic stuff.

The Happy Friar wrote:

aardwolf wrote:

If you want lightmaps, shadow maps, and baked stuff, just use id tech 3 then.

Because Doom 3 is sooooooo much better for SP.

But then we get in to the "just use engine XXX" then. :p

Quote:

...oh, and where was water included in a id tech 4 game? Do you people mean that level in the doom3 expansion?

I think the only one to do interactive water was ETQW (other had water textures for looks but that's all). The only ones to ever make water that does more then let stuff float is D3W members.

But there are some mods that precisely make quake3 a good engine for SP games. ç

Well, I meant water that you can get into and come out to a different area of the level, like in the q2 dm map the edge. Havent played ETQW so I wouldnt know.

=FF=Sturm wrote:

aardwolf wrote:

If you want lightmaps, shadow maps, and baked stuff, just use id tech 3 then.

Why not in id tech 4? (Unreal engine 3/source engine/Id tech 3/...) allows that optionally. If they don't add baked shadows, then it will be a resource hook and another veilfailstein with megalags thanks to processing every useless casted shadows from static lights.
The point is to use both baked stuff and dynamic stuff.

But wouldnt then id tech 4 look just like id tech 3, with everything predefined ? Wasnt the biggest new feature of id tech 4 its great lighting techniques?

aardwolf wrote:

=FF=Sturm wrote:

aardwolf wrote:

If you want lightmaps, shadow maps, and baked stuff, just use id tech 3 then.

Why not in id tech 4? (Unreal engine 3/source engine/Id tech 3/...) allows that optionally. If they don't add baked shadows, then it will be a resource hook and another veilfailstein with megalags thanks to processing every useless casted shadows from static lights.
The point is to use both baked stuff and dynamic stuff.

But wouldnt then id tech 4 look just like id tech 3, with everything predefined ? Wasnt the biggest new feature of id tech 4 its great lighting techniques?

No, it wouldn't. It's just another feature to it's lighting system.
Please, read all the above post about lightmaps and the posible use of them in id tech 4.
Take a look to this:

Code:

http://i42.tinypic.com/2w6ykpv.jpg
http://i43.tinypic.com/2mdlx6r.jpg
http://www.smokin-guns.net/userpix/19_highres1_1.jpg
http://www.katsbits.com/images/articles/conan/conan_dark_cathedral1.jpg
http://aaronjclifford.com/misc/images/hotdangSecondary.jpg
http://aaronjclifford.com/wip/ga.net_comp%2317_SFAM/screens/scene_wip1_1.jpg

Cheers

TRSGM wrote:

I'd like to take the time to point out that you could, hypothetically, redo physics as-is; I've actually enabled a complete RK4 integrator that was in the source but disabled/unused in the vanilla release. There do appear to be a few bugs (occasionally some collisions will just bring the game to a screeching and immediate HALT) but this may be unrelated. I tossed around the idea of replacing the whole system way back when for my Dentonmod offshoot but ended up deciding against it mostly because I don't consider myself to have an extensive enough background in physics to do a decent job. Though docs are kind of scarce if someone's interested I'd be happy to explain what little I know.

Cool, makes you wonder what other stuff will be buried in the code but disabled. If you are up to it, it might be cool to dump any information you wish to share here that can be archived for later reference? Just a thought.

aardwolf wrote:

But wouldnt then id tech 4 look just like id tech 3, with everything predefined ? Wasnt the biggest new feature of id tech 4 its great lighting techniques?

It doesn't mean everything, it means most or some. In the end though it was just a tool for the type of game they were making and it seems some people got confused and thought from that point on every game had to use nothing but dynamic lights because doom3 was doing it and anything Id does everyone else must do.

Id does exactly what they need to do to survive (see ZeniMax) and for the most part it involved experimentation with new technology. With Id Tech 4 it's dynamic lights, with 5 it's MegaTexture, 6 it's apparently voxels - it's neat stuff but it doesn't mean everyone else is forced to copy that from now on.

edit: came across as a condescending prick

Mr.Spline wrote:

Cool, makes you wonder what other stuff will be buried in the code but disabled. If you are up to it, it might be cool to dump any information you wish to share here that can be archived for later reference? Just a thought.

I know func_springs work pretty well, IF you treat them like rubber bands vs springs.

aardwolf wrote:

But there are some mods that precisely make quake3 a good engine for SP games.

I'm only aware of 1 mod for Q3A that had an actual SP component & not just tier-based combat. Outpost

I hope this is a good place for a post like this.

Maybe it's too soon?

I’d like to begin by mentioning that I'm an Id fan and have a huge amount of respect for the people there especially John Carmack for releasing Id Software’s engines to the community, and of course the community here – sure there are some people who don’t make a lick of sense (maybe I'm one of them?) but it’s all about learning and supporting people as they grow. On that note I think as a community it would be great to organize this time in creating something everyone can benefit from together. So if the past is any indication of what will happen we’ll see a lot of different projects spring up, each offering something very useful but not all in one place. So what I’m proposing is to organize everyone who is planning on this from the get-go and build on top of a standard base from which everyone can contribute and benefit from while minimizing the amount of redundancy present is past ID Tech GPL engines (See Quake Family Tree - welcome to Forkville).

In short, a combined community effort to update the engine and tools to something that will benefit everyone who wants to use it now and in the years to come and since the GPL code will have issues regarding the shadow implementation it’s a safe assumption that either a slower solution will be put in before release or just removed outright and left up to the community which will instantly require intervention to solve before anything can even be used. So a standard community maintained Id Tech 4 GPL engine simply makes sense in this regard.

In long:

The following is my wish-list for what I would like to see happen to the GPL Id Tech 4 engine and tools when or even if it’s released. This list is just a start, by no means finished but if there’s interest in this it would be cool to maybe sticky this post and add to it through brainstorming, adding/removing items and that sort of stuff?

The bulk of the modifications are all easier said then done however keep in mind it’s just a wish-list and if something like this becomes a reality I wouldn’t expect everything here to happen – right now it’s just fun to think about.

The goal of this project would be to act as the foundation for any GPL Id Tech 4 based engine for anyone who wants to use it. The modifications should remain as backwards compatible as possible so as to not break compatibility with the existing game (see the Dark Places engine for an example of what I mean by advanced features + backwards compatibility). That is, to allow the new engine to be used to play through Doom3 with some of the additions while supporting new features that mods, tc’s and even new games can take advantage of.

So far there has been some amazing stuff by people in the community like Tr3b, Sikkpin, Denton, Venom, and others – sorry if I didn’t mention you as this was just off the top of my head, I know there are many more but this is just an example. It would be awesome to have you guys collaborate on a common project like this.

RENDERING
Aside from updating the various rendering paths to include more advanced hardware (while maintaining backwards compatibility on lower end specs), the goal is to add as many modern advances while keeping in mind frame rates in actual game-play scenarios (i.e. if ‘feature x’ runs great in an empty room but completely chokes during an actual level it’s probably not going to help anyone).

Lightmaps/Deluxemaps:
I always figured this would be one of the most pipe-dream like items on this wish-list. A massive performance boost is gained while rendering quality can be improved as well, a lightmap compilation utility can either be integrated into the engine and run via console or used externally (in both cases probably some modified version of q3map2). Naturally with this comes a slew of other things like new material keywords for static lighting, multiple uv maps for world surfaces and of course some sort of light grid for models (or else in a static only map models would be black against a lit world) or perhaps a precomputed radiance transfer using spherical harmonics?

Dynamic lights would still exist as we’ve all come to know and love them. They would simply cast over a backdrop of precompiled lighting. Some games simply benefit better from precalculated scenes.

I propose a setting for lights in the editor marked with static to be used as precalculated, editor performance might suck when placing many static lights but its in-game performance we’re worried about and there are many things that can be done to speed up editor performance.

Surfaces would need a lightmap resolution parameter as well as static meshes that would make use of them, unless defined as a global in worldspawn which would be terribly inefficient. A material keyword ‘nolightmaps’ would also be good to tell the compiler of surfaces that don’t need processing allowing further optimization for materials.

Don’t want to use lightmaps? Then don’t, but at least the option is there for projects that would benefit from them.

Deferred Shading: Seems like it would make sense in an engine with heavy uses dynamic lights heavily?

Improved Ambient Lighting: Already achieved to some degree, it would be ideal to have permission of use and further testing on many different hardware configurations to improve any performance and compatibility issues.

Ambient Occlusion: For one would greatly improve the visual quality of scenes and second to give a more natural look which work great in conjunction with soft shadows – this is an option that should be able to be turned off to increase performance on lower end hardware.

Soft Shadows: I would recommend a balance between quality and speed for various hardware configurations, lights would probably need a lot more options for different shadow resolutions. I’m guessing some sort of VSM solution.

HDR: It’s HDR!!! *boner*

Bloom, Depth of Field, Motion Blur and other post processing effects: Again this is also something that already exists in one form or another. Currently however it’s a matter of permission of use, integration, testing and improvement.

It should go without saying that everything needs to be tested on as wide a range of hardware as possible to work out any bugs.

Portal Skies:
This has already been achieved to some degree and it would be nice to have permission of use or even have further contributions for the community effort.

Local Cubemaps/Scene Capture points:
See Source Engine env_cubemap for details. It’s a good cheap way of making reflective surfaces look as though they belong in an area. Surfaces are updated based on the nearest the cubemap location. Under the specular map it could use a keyword that could be used to tell the engine to apply the cubemap which would have to be kept at a lower resolution however an option for size within the entity would be good for flexibility depending on the amount of detail the developer wants to capture.

Improved MegaTexture:
While probably not able to achieve the same level of mega texture found in ID Tech 5 I believe at the very least some sort of reasonable support be brought to the engine through better compression or maybe new tools to allow an easier workflow?

OPTIMIZATION
Possibly one of the most important things to be focused on would be increasing scene detail while maintaining scalable hardware requirements. That is, get more for less :wink:

Level of Detail: LOD is the lifesaver of performance; scenes can have more detail and higher performance with clever use of an LOD system. Being able to have multiple reference meshes that can switch detail based on distance would greatly increase performance and allow more models on screen at once.

LOD for materials: New material fallbacks that can switch materials based on view distances. This would work ideally with surfaces that require heavier processing than a simple static texture – maybe there’s something like this already in there?

Shadow Meshes: Low polygon shadow meshes used for projecting shadow maps would cut down considerably on performance requirements while maintaining a high level of graphical quality. This has already been done through materials and modifying the base reference model. The shadow mesh can be built in with the reference meshes so shadow mesh complexity can be reduced with LOD models.

LOD example in def:

Code:

entityDef mymodel {

…

"model" "models/mymodel/mymodel.xxx"
"model_lod1" "models/mymodel/mymodel_lod1.xxx "
"model_lod2" "models/mymodel/mymodel_lod2.xxx "
"model_lod3" "models/mymodel/mymodel_lod3.xxx "
…
}

TOOLS
The right tools for the job are very important and not counting all the built in stuff that comes with ID Tech 4 here are some ideas for tools or improvements on tools that may help aid developers.

DoomEdit/Radiant:
There are already several custom Radiant versions available, and I can understand the need to use a custom Radiant because of the cross platform functionality however it would be ideal to keep any additions within the built in Radiant since any new rendering features would automatically be reflected in the editor since it shares the same renderer and wouldn’t require twice as much work, however since there will inevitably be another custom Radiant for cross platform functionality (unless this can be added to the internal version – a lot of work) this would need a dedicated person or people to maintain. I’m not against it but this is just my opinion on the matter.

Collada or 3DStudio Max MD5 Tools:
If Something like COLLADA is not an option or if there is a good argument against it then better support for the 3DS Max MD5 Exporter should be looked into. I think Der_ton has done an excellent job however it would be nice to see multiple mesh support with the Max exporter (without the need to attach) since I think next to Blender; Max is the most popular choice of tool for most members of the community here (I’m a Max user myself but I’m trying not to be biased in my wish-list).

Model morphing:
I listed this under tools because it would require a new exporter or format which is tools related, and also because I really couldn’t think where this would fit in. Morph between a number of frames in a reference mesh/multiple reference meshes - used for lip-sync, facial expressions, vehicle/character damage, and more – see Source and UE3 for examples of this.

Morph data would be stored either in multiple reference meshes or in a single reference mesh with each frame representing a unique morph (eye blinking, facial expressions, lip-sync, damage etc…) – it would be best to use the latter. This data would be accessed through scripts for lip-sync.

Model Viewer: Aside from viewing models and animations this tool should also allow reassignment of materials to the ASE and MD5 meshes. It wouldn’t hurt to have a plethora of debugging and statistical information and well

Lipsync Tool: Even if some sort of auto generation is out, having a lipsync tool to create phoneme timesheets would still help greatly over manually editing in a 3D application. JLipSync seems like a good choice however it would be nice to have some input on.

Documentation:
A well documented and maintained Wiki and editing docs, not only organizing existing knowledge but maintaining new features as well would have to be mandatory as there’s nothing worse than out of date information. Modwiki is a great resource, it would be excellent if this projects documentation was hosted there as part of an official ID Tech community engine (if it happens that is).

GAMEPLAY
The real meat of the game is found here, great graphics won’t save you if your game isn't fun. So what can be done to help developers enhance the game play experience, primarily I’m going to target single player but there are certainly things that can be done to MP – I’m just not going to cover that in this wish-list.

Enhanced Physics: ID Tech 4 comes with a complete physics solution however some would argue it’s not that great so I would recommend either extending the existing system or integrating some sort of open source middleware to compensate for the demands of more physical worlds and simulations – suggestions?

Breakable physics objects (Physics):
You have to admit it is fun blowing stuff up and watching pieces fly everywhere. I don’t think I need to go into too much detail but the process would involve creating objects and their fragments which are spawned in their place when the object explodes or breaks. The pieces would be physically simulated and in all probability have their origins modified to spawn in proper place if that’s supported.

Enhanced AI (tethers, teams):
It would be nice to build upon the senses of sight, smell, and hearing for AI to sense dangerous areas, track the player or to give some AI only 1 or a few senses like hearing – not difficult really. Tethers work great to have teams hold down certain areas and teams that can act as one and communicate with each other to challenge players even more would be an amazing toolkit to have for designers. This has already been achieved to some degree and it would be nice to have permission of use or even have further contributions for the community effort.

Water (rendering and physics):
Yes, water has been achieved to some degree however it's a matter of testing and making sure everything is there for what would be considered a full implementation on top of which a way to combine water into a material with both refraction and Fresnel reflection would be a plus as well as water LOD where it can switch to a local cubemap once a certain distance is reached to save on performance.

Along with offering an enhanced way of playing through Doom3 it might be cool to see a special mission pack made that takes advantage of all the new features of this engine to act as both a showcase and as reference material to accompany the documentation. The mission pack would be a great way to involve everyone (non-programmers) from the community.

My question is, does anyone foresee any interest in combining efforts in such a venture or does anyone actually see something like this coming together independently?

edit: cleaned up post a bit, added lightmaps (I left it out to avoid the "Oh nos, sum of teh shadows are precalculated.. tis game sux now" conversation which happened anyway so there they are on that note http://pages.cpsc.ucalgary.ca/~bdstephe ... llzone.pdf has some interesting points like on page 6:

Gamer : Oh, Crap! Look at all those bad guys!
Rendering Programmer : Oh, crap! Look at all those dynamic lights!

Mr.Spline wrote:

I hope this is a good place for a post like this.

GAMEPLAY
The real meat of the game is found here, great graphics won’t save you if your game isn't fun. So what can be done to help developers enhance the game play experience, primarily I’m going to target single player but there are certainly things that can be done to MP – I’m just not going to cover that in this wish-list.

A decent MP with 64 player slots and new/optimized netcode will be good. Also a stable CO-OP will help a lot

Edit: And graphically, optional Lightmapping (ala quake 3/source engine). It will improve a lot for static lights (atmosphere) and the dynamic ones just soft edge stencil shadows

I would love to see a combined effort on this when the source is released. I agree with all your points and have a few of my own I'd like to add...

Material Shader Improvements
We need more compositing options for multiple images in a single stage. It's sad that the only way to achieve this now is to bake simple animations that utilize more than one image into ROQ movies.

Transparency needs fixed. We need alpha blended transparency support in the interaction shader. Alphatest isn't good enough. It looks like trash.

Cubemap reflections don't respond to animated normal maps.

I would really love to see a node based tool even if nodes were only representative of the existing and underlying material shader markup as the markup can be expanded to accommodate a more modular approach.

I also would like to see high level shader language support like GLSL. I've never been able to make sense of ARB.

Internal Model Tweaking

We need a way to be able to diagnose and fix problems with models from within the engine. It's not enough to export something, test in it game and tweak ad-nauseam. It would be nice if we could make minor adjustments to a model in engine. Nothing extravagant. Just the ability to adjust vertex normals, check seams, assign materials, and save changes.

Radiant
Broken shaders, entities, etc... shouldn't even show up in the list.

The list of Key/Value pairs should be derived from the engine internally as opposed to pulling editorvars from declarations.

good points, if i've read right, you mean there should be a central project for expandign/tweaking etc the engine but let it be backwards compatible, like everyone now uses the same .exe (mostly) without having 100forks which all implement same features in a different not compatible way, so everyone likes using the engine has a central place?

Id (or most probably some1 else) could maybe create some kind of http://www.id-community-engine.com and release the source there and creates a community around it. That should be setup long before the source is released cause if not the source will spread and have soon multiple placed where its been modified etc. (just thinking of a site where there is a core engine development team which extends, tweaks etc. the engine, a second place with a "patch-repository" with several new things from people like new effects etc which are still not been ported or wont be ported into main trunk, and a third place where people can easy create a project, get an svn and got their tools for everything they need for modding the engine. This will automaticaly create a nice community around that, and a central point for all modders and devs to communicate. Sure, there is this forum. But its not more as a forum, where people write if they have problems or sometimes release something... but you know what i mean.

Just brainstorming.. :-D

Like it or not, comment it or just mark it as trash :-D

On the subject of improved ambient lighting being achieved already, while true it is somewhat performance intensive on lower end systems. Mainly because the calculations are run on all lights, not just ambient lights...but that's a fault of D3 having a single, unified, interaction shader. When the code is released, ambient can be split off from the rest and performance gained.

*support for vertex animation (opens up so many possibilities...)
*fix the sprites
*ability to bake shadows

that's all I can think of...

I'd like to see a couple things:

1. Multicore support.
2. Area-based cube maps
3.Opimized Anti-Aliasing, shit i turn it on 16xAA and i get from 80 fps to like 20 fps instantly.
4.DESTROY THE UNIFIED SHADING ARCHITECHTURE :twisted:

5. I cant think of anything but i put a five down before coming up with something, so im now filling it up with useless info.
6.Dx10/11 or Opengl 3.1/3.2 features implemented? maybe.

That's about all i can think of. Btw we need some hi res textures that look good even when your up close to the damn things..wonder if thats fixable without the gpl being released...hmmm

Why do you guys want light-mapping and baked shadows on idtech4 when you already have that on idtech3 and it is already out? I find it funny wanting old tech in a new engine.

To me the only areas idtech 4 need improvement is:

- A deferred shading render it will enable better ambient lighting and even faking radiosity.
- Soft shadows by using shadow mapping or soft stencil shadows.
- HDR and AO
- A better physics engine Bullet or even Newton (imo no PhysX crap).
- Improving the megatexture stuff.

With this it will be truly next gen engine.

Argoon1981 wrote:

Why do you guys want light-mapping and baked shadows on idtech4 when you already have that on idtech3 and it is already out? I find it funny wanting old tech in a new engine.

I would guess because it looks great and increases performance? It's not that it's old technology and should be discarded, it's a choice by the developers based on the type of game they're making.

If you're doing a horror game where you want to create tension then a unified dynamic lighting system is great because you have everything blending in which Id effectively demonstrated (maybe a bit too much) - granted they still resorted to cheap tricks like monster closets, spawning enemies both in front and behind you and the imp behind the door ready to pounce got old really quick.

The point is, if you're creating a game that won't benefit from a real-time system then why put one in there and waste processing power that could better be used elsewhere? Or toss out light-maps just because it's "old tech".

Argoon1981 wrote:

Why do you guys want light-mapping and baked shadows on idtech4 when you already have that on idtech3 and it is already out? I find it funny wanting old tech in a new engine.

because some times it's better. That's all. I like the option, just like vertex animations. I still want the RT shadows those & unified lighting, love that (if it was gone I'd see no reason to use the engine)

If you want lightmaps, shadow maps, and baked stuff, just use id tech 3 then.

BTW, great topic! Im hoping id annouces the release of id tech 4 as GPL at this year's quakecon. Anyone wanna bet whether they will release megatexture code and quake4 and ETQW's codebases as well?

...oh, and where was water included in a id tech 4 game? Do you people mean that level in the doom3 expansion?

I'd like to take the time to point out that you could, hypothetically, redo physics as-is; I've actually enabled a complete RK4 integrator that was in the source but disabled/unused in the vanilla release. There do appear to be a few bugs (occasionally some collisions will just bring the game to a screeching and immediate HALT) but this may be unrelated. I tossed around the idea of replacing the whole system way back when for my Dentonmod offshoot but ended up deciding against it mostly because I don't consider myself to have an extensive enough background in physics to do a decent job. Though docs are kind of scarce if someone's interested I'd be happy to explain what little I know.

Public enemy number one for me would be adding hardware skinning using geometry shaders (for volume extrusion) and stream-out or whatever the hell the OpenGL equivalent is. You could offload a HUUUGE amount of work onto the GPU. That being said, fuck shadow volumes. They're a piece of shit. We really need to go shadow maps here.

Number 2 would probably be light propagation volumes.

Re: Lit transucents: This is already done. Look at the vagary sac materal. I believe I made some edits to modwiki about this a few months back, actually.

aardwolf wrote:

If you want lightmaps, shadow maps, and baked stuff, just use id tech 3 then.

Because Doom 3 is sooooooo much better for SP.

But then we get in to the "just use engine XXX" then. :p

Quote:

...oh, and where was water included in a id tech 4 game? Do you people mean that level in the doom3 expansion?

I think the only one to do interactive water was ETQW (other had water textures for looks but that's all). The only ones to ever make water that does more then let stuff float is D3W members.

aardwolf wrote:

If you want lightmaps, shadow maps, and baked stuff, just use id tech 3 then.

Why not in id tech 4? (Unreal engine 3/source engine/Id tech 3/...) allows that optionally. If they don't add baked shadows, then it will be a resource hook and another veilfailstein with megalags thanks to processing every useless casted shadows from static lights.
The point is to use both baked stuff and dynamic stuff.

The Happy Friar wrote:

aardwolf wrote:

If you want lightmaps, shadow maps, and baked stuff, just use id tech 3 then.

Because Doom 3 is sooooooo much better for SP.

But then we get in to the "just use engine XXX" then. :p

Quote:

...oh, and where was water included in a id tech 4 game? Do you people mean that level in the doom3 expansion?

I think the only one to do interactive water was ETQW (other had water textures for looks but that's all). The only ones to ever make water that does more then let stuff float is D3W members.

But there are some mods that precisely make quake3 a good engine for SP games. ç

Well, I meant water that you can get into and come out to a different area of the level, like in the q2 dm map the edge. Havent played ETQW so I wouldnt know.

=FF=Sturm wrote:

aardwolf wrote:

If you want lightmaps, shadow maps, and baked stuff, just use id tech 3 then.

Why not in id tech 4? (Unreal engine 3/source engine/Id tech 3/...) allows that optionally. If they don't add baked shadows, then it will be a resource hook and another veilfailstein with megalags thanks to processing every useless casted shadows from static lights.
The point is to use both baked stuff and dynamic stuff.

But wouldnt then id tech 4 look just like id tech 3, with everything predefined ? Wasnt the biggest new feature of id tech 4 its great lighting techniques?

aardwolf wrote:

=FF=Sturm wrote:

aardwolf wrote:

If you want lightmaps, shadow maps, and baked stuff, just use id tech 3 then.

Why not in id tech 4? (Unreal engine 3/source engine/Id tech 3/...) allows that optionally. If they don't add baked shadows, then it will be a resource hook and another veilfailstein with megalags thanks to processing every useless casted shadows from static lights.
The point is to use both baked stuff and dynamic stuff.

But wouldnt then id tech 4 look just like id tech 3, with everything predefined ? Wasnt the biggest new feature of id tech 4 its great lighting techniques?

No, it wouldn't. It's just another feature to it's lighting system.
Please, read all the above post about lightmaps and the posible use of them in id tech 4.
Take a look to this:

Code:

http://i42.tinypic.com/2w6ykpv.jpg
http://i43.tinypic.com/2mdlx6r.jpg
http://www.smokin-guns.net/userpix/19_highres1_1.jpg
http://www.katsbits.com/images/articles/conan/conan_dark_cathedral1.jpg
http://aaronjclifford.com/misc/images/hotdangSecondary.jpg
http://aaronjclifford.com/wip/ga.net_comp%2317_SFAM/screens/scene_wip1_1.jpg

Cheers

TRSGM wrote:

I'd like to take the time to point out that you could, hypothetically, redo physics as-is; I've actually enabled a complete RK4 integrator that was in the source but disabled/unused in the vanilla release. There do appear to be a few bugs (occasionally some collisions will just bring the game to a screeching and immediate HALT) but this may be unrelated. I tossed around the idea of replacing the whole system way back when for my Dentonmod offshoot but ended up deciding against it mostly because I don't consider myself to have an extensive enough background in physics to do a decent job. Though docs are kind of scarce if someone's interested I'd be happy to explain what little I know.

Cool, makes you wonder what other stuff will be buried in the code but disabled. If you are up to it, it might be cool to dump any information you wish to share here that can be archived for later reference? Just a thought.

aardwolf wrote:

But wouldnt then id tech 4 look just like id tech 3, with everything predefined ? Wasnt the biggest new feature of id tech 4 its great lighting techniques?

It doesn't mean everything, it means most or some. In the end though it was just a tool for the type of game they were making and it seems some people got confused and thought from that point on every game had to use nothing but dynamic lights because doom3 was doing it and anything Id does everyone else must do.

Id does exactly what they need to do to survive (see ZeniMax) and for the most part it involved experimentation with new technology. With Id Tech 4 it's dynamic lights, with 5 it's MegaTexture, 6 it's apparently voxels - it's neat stuff but it doesn't mean everyone else is forced to copy that from now on.

edit: came across as a condescending prick

Mr.Spline wrote:

Cool, makes you wonder what other stuff will be buried in the code but disabled. If you are up to it, it might be cool to dump any information you wish to share here that can be archived for later reference? Just a thought.

I know func_springs work pretty well, IF you treat them like rubber bands vs springs.

aardwolf wrote:

But there are some mods that precisely make quake3 a good engine for SP games.

I'm only aware of 1 mod for Q3A that had an actual SP component & not just tier-based combat. Outpost