let's all add proposals for the assets

[BielBdeLuna]

I propose:

• all "qer" textures (the textures for the map editor) doesn't need to be distributed I propose to create a "qer" folder outside of the texture folders where all the "qer" textures go, so when distributing the game/mod the developer can erase all those textures from the distributed content easily,
• let's not forget that the engine can tint a gray texture to achieve several coloured variations of the same texture, I distributed a set of "dev" textures with several coloured textures that could be achieved with a single gray texture and tinting via material tokens.
• in the light folder, let's separate the fog textures / falloff textures / projected textures in their respective folder, so it's not a mess
• let's try to achieve parity with names of textures with all the necessary textures following the same name convention
• let's create a base light shader that has the most added effects (the parameters dependant effects) so we can have the most complex light effects capability as a starting point)

[ghost]

I've never used mumble, we usually use teamspeak here in South Africa. i'll give it a try.

[BielBdeLuna]

so it means making the other players audio stream come out of their entities? doesn't seem the most difficult thing to implement, no?

@Wintch great to hear that!

[ghost]

@BielBdeLuna That would be great if the audio came from the entities, I recently checked out a free asset from the Unity asset store that makes use of the webcam code to animate character faces based on what the webcamera detects on the players face. Adding expression to players would add a lot to immersion.

[BielBdeLuna]

There is also the coop code, that would be perfect for my project, and that currently oneofthe8devilz's team is working on in their mod Mars City Security: http://idtechforums.fuzzylogicinc.com/index.php?topic=182.0 it's perfect.

[DanielGibson]

is there any working code available yet?

if so, is it for old doom3 or bfg? GPL or SDK?

[Wintch]

Piece of cake @BielBdeLuna, they have all the code in the page. It's seems to be just copy and paste thing. You will need to connect to each other with mumble client on both sides, enable integration plugin and that's it. You can't hear each other in the game without mumble server between you, since it's only positional plugin

[ghost]

@BielBdeLuna I'm game to test Coop with mumble.

Does the engine render faster if more Static meshes are used instead of bsp for the test map? My reason for this is to use prebaked occlusion and cavity maps. Currently it has nine rooms and a terrain area.

[Wintch]

@DanielGibson Current coop source is not there in any form. It is based on Doom3 SDK and there was sort of snapshot a while ago. I merged that with dhewm3 and it worked almost well https://www.assembla.com/spaces/dhewm3coop/wiki

[DanielGibson]

SDK licensed code can't be mixed with GPL code.. we'd have to get the permission of all authors of that coop code to relicense it under GPL to merge it

[BielBdeLuna]

RobertBeckebans implemented 3d models for maps: instead of func_static, allow 3d models to conform the walls of the maps instead of brushes, his dmap has this feature included but nobody has done anything to test it because we need an exporter from blender to his new format.

I started a Blender exporter for brushes, but I didn't finish it. because I felt that before a exporter an importer was more important so I started a IdTechX -> Blender importer, so we could in the future create maps in Blender

but those projects are in the works at the moment, since I'm figuring out how to read all the IdTechX text data in python ( which is difficult because every different data in IdTechX has it's own rules) so Blender can know what Entities there are, what materials, what models...etc. from a given mod location or a given base location. Basically I'm doing a IdTechX API in python. but it's damn difficult.

http://idtechforums.fuzzylogicinc.com/index.php?topic=209.msg1800#msg1800

At the moment is 100% non-working code

in the near future IdTechX mapping and modding could improve a lot. Blender could become the de-facto IdTechX studio!

[ghost]

@BielBdeLuna That is fantastic news as I only work in Blender and somewhat refuse to touch 3ds Max, Softimage or Maya. So I'm guessing we don't have to about level leaks into the void if the mesh is closed off? I played with the geometry shader earlier in blender that creates quick dirt/cavity maps and gives some control, better than the old technique of creating dirt maps from the vertex painter. Integration into Blender should also help OTE gain interest from other developers as Blender seems to be gaining a lot more users lately. I noticed DarkRadiant also uses python scripting, i'm not sure for what exactly, only switched to DarkRadiant recently. Is IdTechX part of OTE, because it is somewhat confusing me?

[BielBdeLuna]

I call collectively the engines forked from BFG as IdTechX (as I remember to read it somewhere in the c++ code as it was refereed as such), it's not IdTech4 nor IdTech5, is something else, if we also include GPL stuff then we make deviate it even further more form IdTech4/IdTech5 dichotomy, so I think we could call it IdTechX to specifically separate it from the original IdTech4

IdTechX is IdTech4 + some multi-core improvements from Quake4 + some multi-core tech form IdTech5 + a OpenGL3.0+ renderer, so it's a Frankenstein engine, I guess the X rather than the Roman numeral for 10 is more like "estrange" :)

[BielBdeLuna]

The problem with Darkradiant is that the current two maintainers of the code seems to have stopped working on it, in fact there hasn't been any new pulls in their github repos for months now, and also I currently can't compile it successfully, and with my intel GPU I have strange geometry errors since they ported it to WXWidgets, so Darkradiant has stopped being an option for me.

[ghost]

@BielBdeLuna Ok now I understand why you refer to it as IdTechX. I thought Intel sorted out their gpu's by now. Maybe a in game editor would help, kind of like they are doing with Tesseract from the Sauerbraten fork, quite a nice little game.

[ghost]

Trying out Dota 2 Reborn now, the difference in fps is staggering compared to the old render engine, Valve also switched over to SDL and other Open Source libraries for Source 2.

[BielBdeLuna]

no, but the really good news on Dota 2 Reborn and Source 2 is Vulkan, the replacement of OpenGL, which when it's specification gets released sometime in Fall, RobertBeckebans has already stated that he is looking forward to include it in RBDoom3BFG, that's the real improvement, with it the engine will be able to be multi-plataform easily.

[ghost]

That would be great, looking forwards to it. I'm already amped for what AMD has planned with FM2+.

[Wintch]

@BielBdeLuna Darkradiant is a great tool. Just don't really know how they would improve it. The feature i personally miss the most (and it's not there), is the building of the map online. With another "player" joining you inside the editor itself. I remember qradiant or some other tool for quake 3 map editing had that feature back then. I would really love to experience that again, that was really advanced for the time. Something like Tesseract is doing: https://youtu.be/3fOpHRrOBJQ?t=45s

[ghost]

@Wintch Tesseract has that feature.

[Wintch]

Yeah, just found the link :) thanks! Some earlier qradiant had that also....well similar, not so 2.0

[BielBdeLuna]

yes, but I'm in a more basic stage, where I cannot edit with the current build (or old builds) so I need to react to that, and pushing the IdTechX API towards Blender seems like the most future proof solution at the moment. Anyways, it is a pet project of mine, I have too much things going one, I have my ideas for the GPL AI (that's my fourth attempt at creating a credible AI for doom3 like games) it always ends in unrealisable features with the damn scripting limitations. And many features in c++ game code, And there is also my GPL games I want to do some day.

Of all of them the API seems like the most social benefiting of the tasks, as it should allow other people to create their content as well as collaborate in it's improvement.

[kortemik]

I see you have scooped quite good ideas here. To recap them all this list is what I find from previous discussion.

Assets:

• Licensing
• Models
• Defs
• Scripts
• Demonstration map
• Fonts
• Packaging, PK4

GUI:

• Get CEGUI to work like the old one
• New graphics for CEGUI
• Console Improvements

Graphics:

• Physically-Based Rendering (PBR)
• ClipTextures/Atlasses AssasinsCreed2 analysis
• MegaTextures

Multiplayer:

• Central Servers
• Number of clients
• Connectivity issues
• Cooperative play SDK based solution

Editors:

• Tesseract-like in-game editor
• DarkRadiant issues
• RobertBeckeban's new map format
• Blender idTech format API

Sound:

• OGG support
• EFX
• Positional Mumble Audio

Resources:

• FuzzyLogicInc Forums
• Doom3World.org OpenTechEngine projects archives
• ModWiki OpenTechEngine projects archives

[kortemik]

Correct me if I mis-colleceted something from the discussion.

I see all of those things need quite a little bit work. My point of view is that everything of them is implementable in OpenTechEngine and should be worked on.

Not to say any of those is of a lesser value but the order of implementing those is important, as we of course want to be able to test and use the feature once accomplished. I am fairly sure everyone agrees with that, at least if I make an example that why to focus first multiplayer when we don't even get a map online nicely yet.

That's why we need to agree on the order how to get there to have the desired features in.

My approach (which would have been a scrum process on Jira, not handling bug/issue tickets) is that: First we should focus on assets to get the demo online, there we can get most other features implemented.

First step: 0) get running the cegui_layout branch of ours, it's up to date now. 1) Licensing docs to our wiki 2) basic defs, if not already there, i think for ugly map they are already there, but for fancy no. 3) scripts, nothing really exists 4) requirements for demo.map should be there, now the map and the models

0 is for all of us. BielBdeLuna already opened #42 so comment there for problems 0.5 rebase assets branch on cegui_layout @kortemik 1 @DanielGibson is best to create some short example 2 I would like to get your comments @Wintch if you can work on these, I mean mostly the basic defs needed to implement different types of lights, weapons and such simple things 3 @BielBdeLuna would you be happy to? It's nothing tremendous, but something like rotations, walk/run animations would be nice to have in the first phase 4 @Yetta1 you should be communicating to sync with 2 and 3 if something is missing, if the task is ok for you

I think 2,3,4 can go in parallel less or more, just remember to pull request as often as you can.

After that is done, let's agree what we get there next as we have then the factory up. Not that I wouldn't have an amount of comment and personal likings and some ideas but that's not part of phase 1.

I don't mind using issues as a chat, it's better actually here so I can recap easily.

[ghost]

@kortemik Thank you for putting the list together, I agree that some features should get top priority over others, for now i'll focus on getting test assets finished using what is currently available. I'll leave the programming priorities to you guys to discuss. The editor and graphics I feel should be lower priority.

[ghost]

I'll be baking ambient/reflection/emission cubemaps for the test map.

[BielBdeLuna]

ok, I propose another milestone form scripting

I propose:

• a script for the player
• a script for a weapon
• a scipt for a NPC
• a script for a Enemy

every one of those points an issue, and keep completing them

[BielBdeLuna]

@Yetta1 I ported a cubemap generator from Dhewm3 to RBDoom3BFG some time ago, try "envshot" in the console you also have: "makeAmbientMap" and some transformers "envToSky" and "skyToEnv" it's a it quirky but it can make the job.

makeAmbientMap is a long process though.

[ghost]

@BielBdeLuna Sweet will try it when the map is done.

[ghost]

Do you guys want a full body player model, so if the player looks down they'll see the torso, legs and feet?

@BielBdeLuna Is the basename the .resource file name for the cubemap generator?

[BielBdeLuna]

the full player body would be great

envshot creates tga pictures, in the env folder iirc (I ported that code some time ago)

[ghost]

@BielBdeLuna Another proposal regarding PBS is to add image based lighting IBL with possible .HDR/.EXR image support for the world background.

[BielBdeLuna]

Technically this isn't PBR, this is more related to HDR rendering, because it needs a change in the procession of the calculus, and the precision on the handling the images used for the rendering, If we need to add this I would vote for the actual HDR rendering, even maybe an approximation like Sikkpin's, before adding any of this.

For this we could study Sikkpin's code as well as his ARB shader code (which isn't a trivial thing)

[kortemik]

issue label-group renamed then :8ball:

also i rebased the assets branch on the cegui_layout as cegui_assets. i think we need at least to rename the default map to demo.map to have the menus hard coded "new game" to work atm. Of course I will be happy to write dynamic scanning and such things for a maps but first things first.

Mind trying out @BielBdeLuna how it works, no recompile should be needed just placing the base next to the engine binary should do it. and having the map in maps/demo.map and dmap of course first.

[ghost]

@BielBdeLuna If that's the case, then it's a better choice to go with the HDR as it gives a better result than PBS or at least from personal experience with PBS in Unity 5 and UE4. Float values seem to be handled a lot better with HDR, especially when it comes to white/brighter values affected by strong light sources. Do you mean the SSIL used in Sikkpins mod? I'm having issues with Sikkmod with SSIL enabled, a lot of the features I have to leave disabled as it throws garbage across the screen, it may possibly be an issue with Nvidia drivers as it has worked for me in the past on older drivers. I also seem to get a weird effect with some of the options enabled which draws small grid-like spots across the screen, similar to OpenGL coded under dos.

@Kortemik Some of the assets i'm creating for the map as GUI elements, i'll rename the map i'm making to demo.map for you.

I've extracted BFG with Motorsep's mod launcher as RBDoom3 for some strange reason didn't extract the resource files from console, not sure why. Is there a plugin for Gimp which can import the .bimage format? I've looked on the XenTax forums, some have managed to access the format for Rage content through scripts, not sure how it works though. All I know is it is similar to DDS, found this PDF on Nvidia from Id Software explaining the compression, http://www.nvidia.com/object/real-time-ycocg-dxt-compression.html

[kortemik]

@Yetta1 the gui things are CEED, CEGUI editor specific. Don't worry about them yet. Original version was SWF so it's not usable.

There is the branch there which should be more or less runable, at least was 10months ago when I last looked, but it's bit messy and needs stuff to be added back. Like portal sky related material definitions and some debug code changes removed, but that's a start still.

I am quite far from a PC which is able to start anything OpenGL3 so either next friday or I peek-poke help you as blind :-/

[ghost]

@kortemik It's ok, the models only has seperated elements for where the GUI area is displayed, similar to how the models worked in Vanilla Doom 3, i'm still learning about all the changes that was made in BFG. I downloaded CEED and CEGUI, but that's far beyond my level of understanding, i'll have to get a document describing how the graphical elements should be designed.

I was wondering if it would be possible add access to Blenders logic bricks system in OTE for people like me that are terrible when it comes to programming, it's been a lot easier for me to prototype through the logic bricks.

Would be cool to have a shader that mimics the cloaking effect of Motoko from the scene in your profile pic.

[BielBdeLuna]

@kortemik why remove the protalsky?! I already said you guys can change the license and release however you see fit!

@Yetta1 incorporating the logic bricks could be a really complicated work. it could be done by analysing the logic bricks and create functions based on thems, and with those compose a script file for the entities. It's doable but maybe not at the moment, as it would include a lot of work.

[kortemik]

@BielBdeLuna only the def file was removed due to some stupid debug. It's not removed from the master branch and never will be. Don't worry. Also please contact me on google talk via gmail so we can get over this faster. kordex youdefinitelydon'tknowwhatsigngoeshere gmail.com

[BielBdeLuna]

what? what is this? XDD

[kortemik]

@Yetta1 I think that kind of shader is doable, I am looking forward to see one of that kind at least. As I said at the recap, I have quite many ideas and comments what I'd like to see but we will eventually get to them!

Don't worry about the GUI yet, it's in the making, not ready but works for map start and quit atm and is ugly.

I don't know how the blender logic blocks are made, bridging in between them is always possible but without further investigation it at least sounds like bit too much for the current state of our work. In future perhaps, at least I would assume them to be some kind of python scripts that configure something.

@BielBdeLuna what? :D

[ghost]

@kortemik As far as I know the Blender Game logic API is seperate from the rest of Blender, there are talks from the Blender Game development community that they want to integrate the game logic into Blender properly, though that discussion has been on for some time. The logic bricks makes use of Python scripts but I think the source itself is done in C++. Where can I download the map you guys are working with?

[ghost]

Is there a polygon budget for the renderer?

[BielBdeLuna]

no, you can have really high res models polygon wise and the engine will work, it's is more the amount of lights that interact in-between (it's not the shadows, but the way the shaders interact per light) than the amount of polygons.

you can have many lights (if you want with shadows), you can have a lot of complex geometry, as long as lights don't touch other lights, it's fine.

this is the reason there is this option in dmap to "optimize" the level geometry to the lights, so big surfaces are cut to the lights limits, making those surface shaders less prone to multiple lights interactions.

[ghost]

@BielBdeLuna Most of the models i'm working on are low poly, except for the terrain model which is hitting close to 150,000 polys.

[BielBdeLuna]

@yetta1 how do you plan to occlude this terrain? the way to handle terrain depends especially from the technique of how to occlude it.

[ghost]

@BielBdeLuna I'm splitting the mesh up into different models (around 32) as I need to paint the textures on the seperate elements to retain texture quality. I read on Xentax that some radiant version had terrain tools for enemy territory, Dark radiant doesn't have it, only the patch system, evenso I think sculpted terrain from Blender gives a better result. Here is the current terrain at 145,161 faces.

[BielBdeLuna]

can this terrain be done via height-map? are there caves?

maybe we could devise a per-zone system where the closest zone is high-res and the surrounding zones get lower-res (maybe even halving the resolution) as the system goes further away from the player position, and keep updating the zones every-time the player moves on the terrain. We could use even points of view on the terrain in order to occlude the non-visible parts behind mountains, Or devise a way to simplify the polygons that are too far and too inline with the point of view, in order to minimize the the renderer polygons.

In Alan Wake they used voxels octrees in order to draw only the parts of the terrain that were visible due to the trees; the idea would be to put the whole terrain in a single voxel, and keep subdividing it, forgetting those voxels under the terrain, and only keeping the ones above the terrain, until a given level in the octree is met, if you relate levels of detail tot he octree levels you could use this info, and also devising a way to traverse the octree spatially you could guess what gets seen from where, and what is the minimum LOD visible from that point.

with octrees a lower-than-player-size size could be met, therefore you could put your static models in the system in order to make the trees occlude the terrain too.

but this is a lot of tech to work with

[ghost]

@BielBdeLuna The splits can be used as per-zone. I was thinking of making holes to add caves and some extrusion to give more definition to rocky cliffs, I most likely will do that. I still need to finish sculpting the river flow, not sure if we could turn it into an island with a surrounding ocean. I can use Blenders decimate modifier to divide the geometry so we could create LOD models. Blender has a modifier called remesh which I think is voxel based, however I think my system will crash Blender if I attempt to remesh the terrain, so conversion of the mesh to voxel will have to be done in OTE.

[BielBdeLuna]

the problems with cutting the terrain in parts, might occur in the cuts, they could show up, or even the normals in the cuts could be distorted and show the cuts with the lighting

I guess developing a model format, specific for terrain, with some kind of special methods for automatic mesh simplification, and being able to make holes to the polygon mesh would also be great.

[ghost]

@BielBdeLuna I understand what you mean, as the models might have a slight offset on the grid space, as for the normals issues, I tend to manually fix the baked normals within gimp by eliminating any seam issues by hand by either offsetting a seamless texture or by layout out layers next to each other.

A model format aimed at terrains or possibly procedural planetscaping would be great, especially one that handles caverns well. Possibly sculptable voxels or something like the Atomontage engine. What was nice about the Atomontage tech demo was how the terrain voxels were altered by objects, for example when a truck drives over sand, it would dig away the sand. From what I understand they converted mesh into that voxel structure.

https://www.youtube.com/watch?v=_CCZIBDt1uM

It will be best for you to decide what to do as you have more knowledge about the computational side of things. Just guide me in the direction of what is best for the development.