create a document for ideas we could implement

[BielBdeLuna]

I propose to create a document with ideas we want to implement, with ideas we have, and with ideas we agreed to implement

we could also add how we think we could implement the ideas

what do you think?

[ghost]

From the top of my head

1. Metric measurement support, for more realistic scaling and ArchVis interest.

The Doom 3 character is roughly over 2 meters in Blender when scaling has been set for Doom 3 modelling, that's a big guy. Setting the scale for Doom editing in Blender sometimes makes it hard to work with the grid. Maybe the exporting add-ons can save out models modelled with the standard grid settings and metric/imperial measurements to the engine by default, so to stop any confusion.

1. Autodetection and automatic script creation for models, mostly for static.

Detection of models placed in the model folders, automatic script creation for the engine to see it, possibly real-time while working in the engine.

1. Developer mode CEGUI screens bound by shortcut keys for editing in-engine/game

Possibly have the engine change the binds for the function keys to open CEGUI screens for editing in the engine.

Material editor: Show previously made materials. Show texture directories and texture previews Assign textures to shader, such as:

Diffuse Gloss Specular Height Normal Occlusion Dirt Reflection Glow Alpha

Have sliders or values to change material layers intensities.

Material flags, such as: Two Sided nonSolid Trigger Hurt etc.

Save material Drag and Drop textures onto level objects or models scaling/mirror/repeat options

Entity Panel Drag and drop models, sounds, particles

Mapping panel Tools for blocking out the level etc. save/load/export/share

Sky settings

Sky generator or skybox assignment

Particle Editor

More possibly

1. Distance based material LOD shaders to lower resource overhead.

Have detailed textures fade in based on distance, fade out to low res versions, cheaper shaders.

1. Sound occlusion flags for indoor, outdoor sounds, sound effects such as muffling behind areas etc.

Have sound volume lower or muffle behind walls, doors, reverb for some indoor, transitions between indoor and outdoor sound.

1. Sky generator possibly with a gradiant type shader, particles for clouds, color settings, day/night cycle.

Generate procedural skies

1. The lighting system Robert is working on as BieldeLuna mentioned on the other thread.

The probe lighting thing

1. Water volumes and possibly fast fourier transform water.

Swimming would be nice and crashing waves, splashes against the edge could be done with particles.

1. Networked editing and asset sharing

Kind of how Tesseracts level editor works for group mapping over the network

1. Cloth physics and Hair particles.

Makes fancy graphics fancier.

[ghost]

The shadows also need some work on bias and clipping distances, I have situations where the shadows get a major offset, looks disconnected. I've played around with many values for the cvars, no luck getting shadows to start at the point of origin.

[motorsep]

Shadows work better in SE2 as we did some modifications to the shadow mapping code.

[damiel]

I would give +1 for the revival of the old doom menu gui to have some more options besides the flash based menu and cegui.

[motorsep]

You might want to check out this fork https://github.com/eXistence/fhDOOM

[BielBdeLuna]

yeah I have seen fhDOOM, it's quite interesting

@damiel I'm currently studying it on how to approach it. https://github.com/OpenTechEngine/Discussions/issues/37

[motorsep]

fhDOOM has no threading and tools, but it seems to have everything else.

[drequivalent]

Here are some ideas I've been kicking around:

1. Subtractive BSP mapping.

This one may be tough, but it will improve accessibility of mapping thousandfold. The idea is, to have support for Unreal-style map editing method, where the map's insides are carved out of the void, without having to manually build walls, which block the view. One example of implementation: https://csclub.uwaterloo.ca/~jmsaunde/editor.html

2. Full SDK with automated workflow.

I'm imagining a package complete with a map editor (may be based on DarkRadiant), IDE that is already set for OTE project files, a compiler for maps, a compiler + dependencies for the game itself, and a lot of importers/exporters/archivers, all integrated into the one solution. Start the SDK, write some code, draw some maps, build the game, build maps, start testing. It also may be good idea for a compiler to be based on LLVM. Also, different language bindings (like Python, Lua) should be nice.

3. Base assets

I see the repository already created for it, and I think we just have to get through with it. Downloading the whole Doom 3 BFG edition just so that the engine works, is just inefficient. The engine needs some base assets, and boilerplate game project so the user could understand the basics of the engine, and start developing.

4. Handbook for development.

Doom 3 BFG edition's way of handling resources and code is pretty different from what we've seen in original Doom 3 release. So a lot of things that are out there are already invalid.

So, here's my quick thoughts.

Final point is, before adding fancy graphical features, the engine should be made usable. There's so many indie projects on Unity, Unreal and even CryEngine not because they are feature-rich, but because they are easy. On the other hand, there was almost none of FOSS projects (aside from DarkMod) based on idTech4, because the barrier to entry is kinda steep. BFG edition makes it even a bit steeper. If the barrier to entry is lowered, the developers will come.

[BielBdeLuna]

no, BFG3 is not different when handling assets, it only lacks ogg and GUI support from the original d3 the rest it's the same.

I agree we have to make something to lower the barrier to entry and I don'0t think dark radiant is a real answer here, I think we should work on an ingame-editor and go the CryEngine way of WYSIWYG

[BielBdeLuna]

basically a "pause" mode where entities and their properties are highly interactuable. and a new brush system for "pause" mode so we can still make brushes and paint surfaces, although in the modern videogames paradigms brushes seem to be more and more irrelevant isn't it?.

[drequivalent]

Don't IdTech 4 maps have to be compiled before they can run? I mean, you have you .map file with brushes in text, and then you build maps with compiler (q3map2 or what have you). Or am I too stuck with iDT1-3 kind of workflow I've seen in Darkplaces and now things are different? Sorry, I just basically built my first idt4 last week, and don't know much yet about it, I just see a huge potential, that's soemhow left unrealized. As for in-game editing. I don't know. I think, it's a nice feature to have, but might be excessive for games distribution. I'd vouch for dedicated editor (or editor integrated with SDK's IDE), just in order to not bloat the engine itself.

[drequivalent]

Oh, one more:

5. TTF font and Unicode support

Hell, Darkplaces has it.

[BielBdeLuna]

don't the engine already support Unicode? bfg has Japanese and Russian support, it can do accents and other symbols from many languages.