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)

[BielBdeLuna]

• can we rename doom_main.script to main.script, so we de-doom the scripting?
• we could have all the scripts that belong to an area in the same folder, so we could have a "ai" folder, a "weapon" folder, a "map" folder, a "util" folder and have only the "main.scirpt" "defs.script" and "events.script" in that folder, we could also have a "map.include" file for all the "includes" for the maps in the game (sort of what already is in doom_main.scirpt) so main.script could be really small, and it would make easy to share a new map and just change the "map.include" file: so in main.script I would have this: '#include "script/map.include"' in map.include I would have this: '#include "script/map/e1m1.script"' and in folder "map" I would have a "e1m1.script" script file in "map.include" then one could have a "//game maps" and a "//test maps" lists of "#includes" and the same with ai, util, and weapon scripts so all scripting would end up pretty organized

[kortemik]

I definitely agree with all of these and have been thinking that we should do it. Changing the default entry point (doom_main.script) should not be too hard. About the shaders and blending and all that kind of beautiful stuff like lights I find my skills lacking.

By the way, the engine likes png textures too, should we keep those in the repo as they are quite compressed? However I don't know if the gpus like them as much they do dds or tga. dds at least is decompressable by the gpu and renderer/DXT has functions to decode it with gpu. png however is decompressed to raw image which is then pumped up later to gpu which might not be the best case for low memory bandwidth gpus.

p.s. I am struggling with a flu so I will be back in the code bit later this or starting of next week.

[BielBdeLuna]

TGA and PNG both are lossless compressors, so I guess we can stick with TGA, maybe PNG is a better compressor and more modern too. but I guess if we switched to PNG, d3 would need more time to load up the assets. but i don't really know with certainty.

do we up the resolution on textures? i mean current hardware isn't the same form 2004, maybe we can standardise 1024x1024 textures (with even 2048x2048 normal maps maybe?) with lights with 512x512 projected textures?

I'm working on a set of 32 framed animated smoke texture, so we can have "moving smoke" as a standard smoke, I'm doing it with the smoke generator of Blender, it will loop so the smoke will continuously change.

[kortemik]

http://www.ogre3d.org/forums/viewtopic.php?f=1&t=80064 here they have quite good discussion about texture formats, i'd go png as it's pretty fast for decoding and lossless, dds is good for lossy even though it needs plugins. Of course it would be best to have original version of assets in different repo using svn so checkout size doesn't get huge. 2048x2048 tgas load quite a while but i haven't tested png with that size.

I would also like to investigate how megatextures work so we could perhaps include them one day, Wolfenstein: The new order had decent version of them working, it was nearly unnoticeable that they loaded but I have also seen the bad side videos on youtube about rage on playstation3.

from here https://github.com/dhewm/dhewm3/blob/master/neo/renderer/MegaTexture.cpp I'd say it uses tga format as base for block generation but i don't see a reason why it could not work with png too.

[RobertBeckebans]

The BFG renderer converts automatically all images to the .bimage format which is similar to .dds and uses DXT compression formats. TGA and PNG are only loaded if the appropiate generated/*.bimage file does not exist.

2014-09-17 9:53 GMT+02:00 Mikko Kortelainen notifications@github.com:

http://www.ogre3d.org/forums/viewtopic.php?f=1&t=80064 here they have quite good discussion about texture formats, i'd go png as it's pretty fast for decoding and lossless, dds is good for lossy even though it needs plugins. Of course it would be best to have original version of assets in different repo using svn so checkout size doesn't get huge. 2048x2048 tgas load quite a while but i haven't tested png with that size.

— Reply to this email directly or view it on GitHub https://github.com/OpenTechEngine/OpenTechBFG/issues/17#issuecomment-55860596 .

[DanielGibson]

Yeah, so let's use png for source images, it's lossless and has the best compression. The engine should convert it to .bimage on first use and afterwards loading the texture is fast anyway.

(I do however think we should distribute .png and not .bimage, in case we or other people people feel like modifying the .bimage format - and in the end it doesn't matter with the few textures the base assets need to provide)

I guess it would be nice to add support for water at some point and distribute a corresponding example material with the base assets.

[BielBdeLuna]

TGA is lossless too, dds it's not. the newest implementation of Opengl (4 or 4.5, I can't remember now) include a new codec for textures, in order to replace the dds crap (which it's DirectX, therefore proprietary)

there was a mega-texture mod for d3 I used it once and it worked well (for planar continuous surfaces ) somewhat more closer to whatever is in Quake Wars than whatever is in Rage.

more than the actual loading and displaying the megatexture, the key to that tech is the actual authoring of the megatexture.

one thing I want to add is vertex weight(color/n-colours), so we could paint plants and forests, a la Crysis.

I and Motorsep once tried to add the water system from the dark mod (the only current implementation that is GPL that is that doesn't use the SDK files), back to dhewm3, I couldn't get it to compile, I sill have this thorn stuck, some day I'll port it successfully.

another thing I do have working though is the code for player footsteps and monster footsteps adapting to water depth, player was no problem, that is the classical implementation but monster needed some additional code. I have it for dhewm3, I'll try to add it to idtech4x, monsters and players now can have a left/right separated sound per leg. and the added benefit of water splashes. as well as other surfaces.

there is water in d3 although non working (once the player steps on the ground, it's like he is on the surface, and there is no jumpout pushing force, you can't die in water as there is no drowning mechanic. and the most difficult part, there is no water physics, so there still a lot of work, and it's even a work just to copy whatever is relevant from the dark mod. it's no trivial task, at least for me.

[kortemik]

I see where you are getting at. The CEGUI system uses similar atlas type approach and calls them imagesets.

Adding them into the engine shouldn't be bad job either and I don't' see any reason why not to support it. One just needs to hack the Material definition code to support additional imageset parameters for the Material meaning cordinates in the png.

I think there is something like this already in the engine for FX, so check that out. I recall seeing plasmagun projectile strips or something like that.

On Sat, Jun 27, 2015 at 4:48 AM, Yetta1 notifications@github.com wrote:

I was in the process of moving my project over to Unity from the original Doom 3, however I didn't feel like recreating my maps on Unity or converting C++ to C#, so I'm sticking to idTech 4. I was reading this posted and want to get your thoughts on a technique I started to use in Unity. What I did was by modelling tileable objects in Blender, then baked them as an atlas in a grid using the orthographic camera to resolutions of 8192x8192, 4096x4096, 2048x2048, 1024x1024 in the png, tga formats with linear color space instead of gamma corrected.

I used these textures to be applied to an object using a texture offset to select the part of the atlas I wanted to use. This method lowered the texture file count as well as the overall hard drive space used as the png files after compression from Gimp 2.8 gave file sizes of 2.5mb for atlases containing a texture grid of 16 textures at 2.5mb per file. I also tried this with Gimp 2.9 beta which has support for converting images up to 64-bit floating point linear and gamma space, unfortunately the export seems broken.

Maybe a fork of Radiant targetted at the BFG code with support for texture atlases could help release games with smaller file sizes as there are less textures. The main reason i'm looking at this is because I reinstalled Rage on steam, and the download took me over week as I live in a developing nation with a slow connection. I don't want to release a game that takes forever to download.

— Reply to this email directly or view it on GitHub https://github.com/OpenTechEngine/OpenTechBFG/issues/17#issuecomment-115852851 .

[ghost]

@kortemik Sorry i deleted that previous post because I wanted to do some research first. I'll have to extract the textures to see if the engine used strips for the plasma and fx, I haven't really ever looked at the fx back in my DoomEdit days. I do however remember Doom 3 made use of a strip for the font in the gui, might be able to use that code.

I'm currently composing a proposal document for features for OTE based on the little knowledge I have of the engine, i've also started to create graphical elements for the GUI that you guys could maybe slice up for cegui. It might take me a few days to finish the document as i'm juggling other tasks. I'm planning on making a test map with new static models and textures as well as a atlas texture set for experimenting, the test map will be aimed at testing and showcasing the development of OTE. Let me know if there are any specific artwork assets you are looking for.

[kortemik]

@Yetta1 It would have been nice to keep the post for future references.

What becomes to OTE assets, we basically lack a demo map demoing all the features of the engine. Also the GUI is work in progress. I haven't been able to participate to that matter due to some exhausting personal affairs taking place last 5 months.

On Mon, Jun 29, 2015 at 12:52 PM, Yetta1 notifications@github.com wrote:

@kortemik https://github.com/kortemik Sorry i deleted that previous post because I wanted to do some research first. I'll have to extract the textures to see if the engine used strips for the plasma and fx, I haven't really ever looked at the fx back in my DoomEdit days. I do however remember Doom 3 made use of a strip for the font in the gui, might be able to use that code.

I'm currently composing a proposal document for features for OTE based on the little knowledge I have of the engine, i've also started to create graphical elements for the GUI that you guys could maybe slice up for cegui. It might take me a few days to finish the document as i'm juggling other tasks. I'm planning on making a test map with new static models and textures as well as a atlas texture set for experimenting, the test map will be aimed at testing and showcasing the development of OTE. Let me know if there are any specific artwork assets you are looking for.

— Reply to this email directly or view it on GitHub https://github.com/OpenTechEngine/OpenTechBFG/issues/17#issuecomment-116421181 .

[BielBdeLuna]

you guys are talking about animated particles (2D aniamted i mean) all the frames are lined up as a long continuous image, and the material using the time stamp, moves the image ( after it being scaled to keep the original frame occupying all the surface) so it keeps moving the image forward so all you see is a 2D animation,

çthis is usually done with fire images, where a bunch of looped fire frames are all packed up in a single image file in that way, so you end up with a looping fire animation

[BielBdeLuna]

you can use this to hold several textures for single surfaces in a single image, but this only works on a per single surface basis, if you enlarge the surface but don't enlarge the uv coordinates (you don't "fit" the texture to the surface in radiant) you would end up with the trick showing up

now if we could clip a texture out of the image and keep it repeating from the clipping point, acting as a normal texture, that would be great.

I think Brink used this method, instead of going the megatexture route (that SplashDamage used in Enemy Territory) they instead compiled all the textures of a level in a single huge texture, and using clip textures they could use the textures as normal textures while uploading a single huge file to the GPU

this is how they did huge cities of assasin's creed texture-wise: http://web.archive.org/web/20130211015056/http://www.mapcore.org/content/features/_/articles/technical-breakdown-assassins-creed-ii-r24

[kortemik]

I think we should create a milestone of a first release, define it and create issues of what is needed to do in order to get there.

I also requested an Atlassian Jira instance for our use in case you find it better than githubs milestoning process. In regards of scrum etc development workflow bs. Just vote on it and we close this and start using it. It imports all github issue feature things nicely.

Only thing I have been working on is the GUI system but that won't get us too near of a full release with maps and such and now that we have some new members, hopefully, on board I'd like to see things assigned and get the water wheels rolling again.

@BielBdeLuna would you be willing to define the tasks needed for the milestone? I can do that too of course, starting from models, lights, sounds, scripts etc. But I think you have done already a mod or something with idTech as you have more knowledge of what needs to be done.

After that comes the hardest part of who will do the work but at least then we have the wreck yard ready to work with.

On Tue, Jun 30, 2015 at 1:58 AM, Biel Bestué de Luna < notifications@github.com> wrote:

you can use this to hold several textures for single surfaces in a single image, but this only works on a per single surface basis, if you enlarge the surface but don't enlarge the uv coordinates (you don't "fit" the texture to the surface in radiant) you would end up with the trick showing up

now if we could clip a texture out of the image and keep it repeating from the clipping point, acting as a normal texture, that would be great.

I think Brink used this method, instead of going the megatexture route (that SplashDamage used in Enemy Territory) they instead compiled all the textures of a level in a single huge texture, and using clip textures they could use the textures as normal textures while uploading a single huge file to the GPU

this is how they did huge cities of assasin's creed texture-wise: https://www.mapcore.org/content/features/_/articles/technical-breakdown-assassins-creed-ii-r24

— Reply to this email directly or view it on GitHub https://github.com/OpenTechEngine/OpenTechBFG/issues/17#issuecomment-116761208 .

[ghost]

//Repost of the deleted message

I was in the process of moving my project over to Unity from the original Doom 3, however I didn't feel like recreating my maps on Unity or converting C++ to C#, so I'm sticking to idTech 4. I was reading this posted and want to get your thoughts on a technique I started to use in Unity. What I did was by modelling tileable objects in Blender, then baked them as an atlas in a grid using the orthographic camera to resolutions of 8192x8192, 4096x4096, 2048x2048, 1024x1024 in the png, tga formats with linear color space instead of gamma corrected.

I used these textures to be applied to an object using a texture offset to select the part of the atlas I wanted to use. This method lowered the texture file count as well as the overall hard drive space used as the png files after compression from Gimp 2.8 gave file sizes of 2.5mb for atlases containing a texture grid of 16 textures at 2.5mb per file. I also tried this with Gimp 2.9 beta which has support for converting images up to 64-bit floating point linear and gamma space, unfortunately the export seems broken.

Maybe a fork of Radiant targetted at the BFG code with support for texture atlases could help release games with smaller file sizes as there are less textures. The main reason i'm looking at this is because I reinstalled Rage on steam, and the download took me over week as I live in a developing nation with a slow connection. I don't want to release a game that takes forever to download.

//

[ghost]

Quick mockup done in Inkscape, thinking of doing a tech panel design in 3D. The mockup image design space is around 1920x1080, so it should be easy to slice it in photoshop with its web tools.

I'm busy with a remodel of the Doom 3 imp to clean up the forms as the original model had 1,346 triangles resulting in jagged shapes, i'm aiming at a result of 7000 faces, details will be baked to a normal map from a hi-res sculpt, I will include a derivative map as well. I will be using the animation files from the game for now in the test model until a new rig is completed making use of a muscle system.

[BielBdeLuna]

@Yetta1 I would like to propose the "IdTechX" name instead of "Doom3" so we could de-doomify opentech

as well as use a different font in case we get a copyright notice or something similar.

I would also like to propose a "single" button instead of a "play" button.

[BielBdeLuna]

@kortemik how do I create a milestone for opentech in Github?

[kortemik]

I think from issues you can do it

https://help.github.com/articles/creating-and-editing-milestones-for-issues-and-pull-requests/

On Tue, Jun 30, 2015 at 10:17 PM, Biel Bestué de Luna < notifications@github.com> wrote:

@kortemik https://github.com/kortemik how do I create a milestone for opentech in Github?

— Reply to this email directly or view it on GitHub https://github.com/OpenTechEngine/OpenTechBFG/issues/17#issuecomment-117177903 .

[ghost]

@BielBdeLuna I'm removing the AmazDoom font used in the design, the other font used was called Motion Control made by JapanYoshi which comes with a Open Font license. Here are his contact details. (japanyoshi.deviantart.com) (born2bsporty.tumblr.com) (www.behance.net/japanyoshi) (japanyoshi@gmail.com)

[ghost]

Should I replace the imp model remake with a custom enemy model for testing?

[DanielGibson]

which imp model remake?

[ghost]

@DanielGibson I've started a remodel of the imp for testing. The remodel is being done from scratch, so far the torso is done, but i'm considering making a new enemy character design to avoid legal issues. My main reasons for a custom model is to test performance with higher poly enemies and animations based on a custom rig i'm working which contains a muscle system to provide a more realistic looking body animation.

[DanielGibson]

if it doesn't look too much like the original imp it probably doesn't matter (even then I'm not sure, if it's built from scratch).

Either way, a test enemy model that we could bundle with opentech to demonstrate how to integrate enemies would be cool :-)

same for weapons actually (one club/axe/crowbar-like weapon and a gun-like weapon probably would be enough to demonstrate the common use cases).

I'm in favour of defining milestones with tickets for those milestones.

But let's use the github issue tracker for that, not Jira. Using the github issue tracker integrates well with pull requests and makes it easier for other people to report bugs (if I wanted to report a bug for a project on github and it'd redirect me to Jira, I'd just go away).
Also, he github thing is enough for us: You can define milestones, assign them to developers and attach arbitrary labels, we shouldn't need any more. In fact, it even seems good enough for Valve's Linux bugreport management, and they have have a lot more users and projects than we ever will.

[ghost]

@DanielGibson I'm working on a sci-fi horror survival shooter with multiplayer, which I aim on releasing on the Indie market. I currently have the storyline, 18 map layouts , 4 guns, 1 melee and some static models. I also have a website for it which currently has no content on it, just a e-mail link to me. So if you guys are interested we could work on the game together to showcase OTE and profit from it commercially.

[DanielGibson]

For OTE I'm currently mostly interested in dummy content that we can put under public domain "license", that's just to show how to use OTE - and a starting point for people to build their own content (thus public domain license, so they don't have to worry about the contents license if they're building something commercial). It doesn't even have to look great..

Of course, having projects (with content under whatever license) that show what OTE can do is very useful, too. First, they will show us what needs to be improved in OTE, second, it might attract other developers to try OTE if they see something cool using it.

[ghost]

@DanielGibson I'll create some weapons and enemies under public domain for OTE and provide the source files created in Blender format. I'm currently modelling in Blender 2.74, however I have to switch to Blender 2.49 to export to MD5 because i'm having issues with the exporters for Blender 2.6. I don't know how to write plugins, but it would be nice to have a updated exporter for any new features. I'll upload the weapons and enemy by next week.

[DanielGibson]

Cool, thank you! :-)

There is no rush, it's not like OTE is under very heavy development currently.. I hope to do more in the next weekends, though.

I guess for a first milestone we could set

• importing the assets from https://github.com/DanielGibson/d3-base-assets
• a simple box-like level (I think the assets even include one)
• a rudimentary main menu that at least lets you start that level and quits the game
• properly working console (either original one or based on cegui)
• all this must work without any original doom3(bfg) assets (except for the shaders which thankfully were GPL'ed with the game source).

So we'd have a minimal standalone game/demo/thing

The second milestone could include simple weapons (besides the model part those need scripts and we need to write those from scratch, as the doom3/d3bfg scripts were not GPL'ed).

[ghost]

@DanielGibson I'll upload the assets to the link you provided. I'm already in the process of making a test map for OTE which included rooms for weapons, enemy AI, lighting, FX, physics, animations and materials. After completion of the map, I will create a multiplayer test map.

I would like know if there will be any implementation of Physically based shading through GLSL and other features such as screen space directional occlusion, global illumination, refraction and reflections.

[BielBdeLuna]

@Yetta1 idtech shaders include a way to change the gloss size, we should find a way to connect it on a per surface scope via maetrial keyword, with either a number per surface or an actual texture that did it per pixel, or a way to gather a number if there is no texture present in the map, even als we could stipulate some specific gloss size numbers per surface type so, if no gloss-number is present or no gloss-texture is present then at least make it so that kin d of surface is an specified number.

if neither of this is present (like for example a new surface-type) let's keep using the current gloss number in the shader

[BielBdeLuna]

ok added a milestone, now let me add that milestone you guys summed up above,

---> done <--- what I don't get is how the milestones know the percentage done...

[BielBdeLuna]

@Yetta1 on the menu mockup, what about putting a "title" and below it a "subtitle" instead of "OpenTech Engine" so people can edit it and put their own as easily as they can

also what about a "continue" button on top of the single/multiplayer/options/mods so we could create a method to continue the game from the last saved game, like modern games.

also maybe between "options" and "mods" there should be a "credits" button?

[Wintch]

You could use D.R.A.P. assets also: https://github.com/Wintch/d3-base-assets They are basic, but i have almost everything in MP rewritten already (md5 animations are from original Doom3). Licence is still WTFPL, 2 maps, some guns...what else do you need?

[DanielGibson]

interesting.

are really all assets WTFPL? https://github.com/Wintch/d3-base-assets/blob/master/COPYING.txt says that some "ARE or CAN be still covered by original Doom3 EULA" (which is really unspecific) and then "Some of these files were made by bladeghost" ... "Still can be considered public domain" - why can they be considered public domain? Has the original author agreed to that?

and then there is the stuff in def/, especially entity definitions - seems like my (incomplete) definitions were overwritten with the original doom3 files, which are still under doom3 EULA.

[ghost]

@BielBdeLuna I'm uncertain by what you mean with the gloss number as specularity levels seems to be controlled by the values in the specular maps, unless it has changed in BFG, as i'm still working with files from vanilla Doom 3 instead of extracting from the resource files from BFG. By physically based shaders I meant having support for real-time reflections and global illumination so it affects materials based on its surroundings. Not sure if the mirror from Doom 3 can be used in the materials for real-time reflections.

[ghost]

@BielBdeLuna I just downloaded CEED, i'll remake the layout in that and write in the title area "Title goes here"

EDIT: Nevermind it involves coding. -_-

[Wintch]

You have the list attached in the text file Daniel. Glprogs is not used in BFG, fonts are easy to rewrite, most md5 models needs to be replaced (still if you guys start from scratch). Finally i asked bladeghost, and you have a link where he agreed to share those assets (i have them rewritten already, just machinegun is still from it's mod). Some def/script files needs rework, gui is plain text only. But it is working, just consider it. Thanks!

[DanielGibson]

Yeah, I just wanna make sure we don't accidentally include any assets that are not under a very liberal license (preferable WTFPL/public domain or similar)

[Wintch]

I just forked your assets, Daniel some time ago and started from there. I also had to copy some basic scripts over to make it work. But all the assets themselves (textures, materials, sounds, and so on) were written from scratch. Well....maybe i have one texture (machinegun fire) from Doom3, but really no more than that. Inside the engine few minor changes were made. It is a fork from dhewm3, so it is easy to track'em

[ghost]

The assets i'm making can be used by the public any way they please without giving credit to me, though it may be nice. But I must ask what the general theme is, because the content i'm creating is sci-fi themed. I don't want the artwork to clash in any way. So please let me know what you guys need in the art direction.

EDIT: I already have a material ball to showcase materials, 1 pistol, 1 melee, player arms, I just need to UV unwrap, texture, animate and finish the scripts.

[BielBdeLuna]

@Yetta1 but physically based render doesn't include GI or reflections, the most important addition is the roughness of the specular reflection (this is the size of the reflection)

in d3 there is already a way to control it within the arb shader (in fact d3 uses a hard-coded value in the arb shaders) and this is still the same in the current implementation of RBDoom3BFG, and you can check it if you do the following in interaction.pixel:

- let's start RBDoom3BFG and let's start any map ( preferentially a detailed metallic environment map where we have a strong light so we see it's specular reflection easily as we move around the room)
    the map should look like always

- first let's deactivate diffuse:
    the penultimate line adds specular and diffuse:
        result.color.xyz = ( diffuseColor + specularColor ) * lambert * lightColor * fragment.color.rgb;// + rimColor;
     lets comment it out with "//" and lets add a new line after:
        result.color.xyz = specularColor * lambert * lightColor * fragment.color.rgb;

- now if we type "reloadShaders" in the console we will end up with diffuse-less rendered frames, we will only see the specular on the walls and weapons, and none of it's diffuse term

- then let's increase or decrease the roughness of the surface
    search for a line that says: const half specularPower = 10.0f;
        change this number for 1.0f or 5000.0f or any number you like
        and "reloadShaders"

- when finished revert all changes to the original state

now take a look that "const half specularPower = 10.0f;" is a constant, if we could control this number as per material basis, or even as a per pixel basis, IdTechX would look much more modern as current engines do.

imagine a glass window which in the transparent parts the glass is 5000.0f roughness and in the dirty parts the roughness is 8.0f, all of this info provided by a "roughness texture" a grey-scale texture, where white is rough and black is slick or the inverse.

in order to implement this we could first add a r_specularPowerScale, a float value that matched the "half specularPower" in the shaders an informed it on it's value.

secondly we could implement a "roughness" material keyword, that could be inform the roughness on the whole surface this material is upon in a per material basis.

eventually we could implement a "roughnessMap" material keyword that pointed to a grayscale image so the roughness could be on a per pixel basis

and then the implementation would be as following: if there is a "roughnessMap" texture, we ignore both "roughness" value as well as "r_specularPowerScale" value, if we don't have a "roughnessMap" then we use the "roughness" and in case of missing that too, we would fall back to "r_specularPowerScale", in case of not having that one setup in the cfg, then we would fall back to the default value for "r_specularPowerScale".

so we would always have some sort of roughness in the renderer, just like classic doom3 has.

[ghost]

@BielBdeLuna Thank you for clarifying that for me, i'm quite a noob when it comes to the programmers side of graphics. I see now that it uses float values which is good for images pushing beyond white values, for example HDR images.

I know that GI and reflections are added on top through vertex and fragment shaders, my wording seems to have been incorrect. I'd like to reflections on materials and for light sources, whether it be from static, dynamic lights or some emission/glow maps from textures to affect it as well.

[ghost]

Do any of guys know the webmaster that ran Doom3World.org? It seems it died a while back due to a Ddos attack. Need some of those tutorials.

[BielBdeLuna]

@Yetta1 do you know this?

http://idtechforums.fuzzylogicinc.com/index.php

[BielBdeLuna]

what do you guys think do we create a milestone for PBR ?

[kortemik]

@BielBdeLuna Sure we can do that, but one then would need to create issues what needs to be done to get it supported.

@DanielGibson I agree with you, let's stick with github.

About CEGUI stuff, my branch over here https://github.com/kortemik/OpenTechBFG/commits/cegui_layout has working menu. It can start and quit. It uses cegui default gui elements and looks like something but not pretty.

@DanielGibson you made a question about how to use CEGUI so it doesn't crash. The answer is to compile it with proper settings, at least on fedora it works fine after defining all the default renderers and seeing that the python links properly with them. Be sure to uninstall any instances of OS provided versions. The Windows build of cegui is out dated and shouldn't be used.

As a side note, I am currently in time-zone of UTC+9 so if you can please reply whenever possible so we would be able to work these out in a faster manner.

[DanielGibson]

I think a milestone for PBR doesn't make much sense, unless someone is actively developing it and has a rough idea, when it'll be done. A "bugreport" for the task however makes sense.

Generally I'd see milestones as a bundle of features/tasks (=> github issues in the end) that are planned to be done in the near future with about the same priority.
So for us it probably makes sense to define the next milestone with reachable goals (like the stuff I suggested for milestone1) and maybe a "sometime in the future" milestone with all other issues/tasks, that get prioritized and maybe assigned to a proper milestone when the first one is done. (Or maybe we could plan two milestones in the future.. but not too much, it's not like we can really plan 5 milestones ahead and know exactly what feature we'll develop when, if at all).
I see PBR as something that would be nice to have in the future, but I have no idea if and when it's gonna happen, so it makes no sense to put it into a specific milestone, IMHO.

So we already have a milestone defined in https://github.com/OpenTechEngine/OpenTechBFG/milestones/first%20batch%20of%20common%20assets and we should add an issue for all the mentioned tasks (or, if issues or pullrequests already exist, apply the milestone to them).

reg. CEED: yeah, the question is what "proper settings" are and which dependencies are needed. When I last tried I didn't have any cegui packages from the linux distro installed, just the stuff I compiled myself from the latest cegui release (or even git). I could compile cegui and ceed and ceed kinda worked, but was really unstable. As cegui supports multiple different libs to satisfy each needed feature (image loading, xml parsing, python integration, ...), maybe I just used badly supported libs or something. So I wonder which ones should be used for things to work.

[kortemik]

@DanielGibson see #28 for that CEED thing, let's keep tool-related issues out of features

[kortemik]

@Wintch about the fonts, we currently have one based on Bitstream Vera Sans in the assets already.

There are also other git repositories mirrored by us which have the necessary font creation tools. Not that I can say it was fun or that they would run on anything else than Windows. But that's not an issue for now.

I would love to see your assets in OpenTechEngine, we just need to collaborate which ones and how to make most of what we already have done.

BFG versus original has some slight changes but nothing major. Our current assets are partly based on the ones DanielGibson made for D3 but have been modified to support startup of the engine on BFG code. Others have been dug with search for references from the code.

I have made tests with our current assets and with a little work character animations can be made to work with them no problem. So I guess with little testing it shouldn't be that painful to get things running.

Please try to run the engine and open a new issue if there is something compilcated that needs thinking so I will be able to write instructions. Me testing doesn't provide any good instructions as all the pitfalls are not so familiar as I have dangled on the rope too many times to get it running.

[BielBdeLuna]

@DanielGibson what do you think of the proposal for PBR that I made some posts above? I proposed the necessary steps for using the PBR features already existing in the shaders.

@kortemik once the milestone is created, how de we relate it to existing issues?

@Yetta1 for reflections we could use screen space reflections like the ones done here: https://www.youtube.com/watch?v=sVxekuLmnRM or here https://www.youtube.com/watch?v=2Tuo76YQZGg

but maybe we need a deferred renderer to do so?

[kortemik]

@BielBdeLuna On the right side of the issue, like you are viewing at the moment should be milestone and labels and assignee.. There one can do it!