[Enhancement] Graphics improvement

[johnyukon]

I see graphics are already being improved, we have better shadows now.

There are many mods created for DOOM 3 that may help in this task because they already have shaders and other stuff:

http://www.moddb.com/mods/sikkmod http://www.moddb.com/mods/perfected-doom-3-version-500 http://www.moddb.com/mods/parallax-mapping-mod-10 http://www.moddb.com/mods/g-t-x-d3 http://doom3.gamebanana.com/gamefiles/3756

There are probably many other mods around but I think that the most famous one is sikkmod. It comes with source code.

Also I don't know if this might help, but the Tesseract engine, based on cube 2 engine, implements some neat graphics effects, like real time global illumination:

http://tesseract.gg

I don't think graphics are the most important aspect of a game but it's needed to compete with proprietary engines and attract developers.

[DanielGibson]

Am 28.07.2014 03:18, schrieb motorsep:

Hmm... Yeah, that's what I am talking about - point finger at me, but in no way look at yourself. What is "social deficits" ? If you mean I don't know how to socialize, I have to disappoint you as I work in a company ~200 employees and I interact with ~50 on daily basis. Haven't had any issues. However, these people don't create situations like people create online. Thus I don't deal with whole a lot of nonsense at work.

Here I see nonsense all the time, especially within Doom 3 community. And I am not going to say nothing when people like you step in and defend the nonsense.

Maybe your social skills just work better in real life. Whatever, I'm not going to discuss that any further, it seems pointless anyway.

You can't probably read clearly as it's quite late in Germany, but I think I made it clear there are/were a few good people in the community.

You obviously don't know my sleeping schedule :-P

Note that you used word "idiots", I didn't. One thing I forgot to mention that "community" consisted of maybe 10 or even less people. The rest were coming in infrequently. But the active members were the ones stirring up shit.

I was not quoting you there, but trying to make the point that it's improbable that everyone else is wrong and only oneself is right.

When I asked for features, you and some other folks labeled me as selfish person who doesn't want to do anything himself. But yet when someone else asks for features that are crazy complex to implement - you say nothing, and even suggest it's what has to be done for some bogus reasons.

Yeah, right.. you must be confusing me with someone else.

You don't have "problem" with people because you don't care. You aren't the one adding features. You don't care for indie game dev. You don't care for commercial indie game dev using GPL engines (as I recall you were against it).

You recall incorrectly, I'm totally for game dev using GPL engines. And I'm especially for collaborative technology development vs everyone developing on his own and after a few years everyone releases his stuff, resulting in several different implementations of the same things.

Let's rewind back to last year. I was suggesting that going BFG is a way to go. Trying to port BFG into idTech 4 was nonsense, etc. You and a few others did the same thing you doing right now - suggesting I was the one with the issue, I didn't know what the hell I was saying, and I should just shut up.

As far as I remember, I was quite enthusiastic about the BFG engine, apart from some things I disliked (and still dislike) like flash menus, missing mod support and missing tools.

Cheers, Daniel

[BielBdeLuna]

you guys are funny, how do we add ambient to the d3bfg engine?

[motorsep]

@BielBdeLuna Can you please post a screenshot showing vanilla Doom 3 level with ambient light working? I am 100% certain vanilla Doom 3 had it broken. "Rebb" fixed it for Doom 3, and I am sure he can fix it for Doom 3 BFG.

[BielBdeLuna]

no, you're right. d3 had it broken, but at least had something. d3bfg doesn't even have it broken. it doesn't show anything, pure black. you can open both levels.

Rebb solved it beautifully for doom3. if we could include his fix into d3bfg it would be great. also the darkmod team had another solution for ambient, but I didn't like it that much though.

Motorsep. just create a test cube map one with a big ambient light around, when you play de map you'll see that the ambient term is missing.

[kortemik]

@BielBdeLuna If I am anywhere near correct, darkmod team uses ARB based solutions with an direct mixing to diffuse map http://wiki.thedarkmod.com/index.php?title=Texture_Creation_-_Basic_Tutorial#Create_your_material_file

There are interactionAmbient.pixel and interactionAmbient.vertex under https://github.com/id-Software/DOOM-3-BFG/tree/master/base/renderprogs which might be for the same thing.

If you happen to study those please share.

[BielBdeLuna]

the dark mod has a different solution for ambient light. their ambient light looked more like it was light projected form the camera itself. while Rebb solution was more akin at what we understand as ambient light: lighting up the whole model without any direction. (which I would prefer)

does that mean that all "interactionAmbient" have to be changed? why there are so many of them? are those shaders used in different instances of the game? in vanilla d3 I know there where several ARB shaders that weren't used is it the same thing here?

[motorsep]

yeah, same thing as in Doom 3 - shader fix. All shaders are used in BFG.

[BielBdeLuna]

so if anyone wants to change the ambient light has to change all interactionAmbient ? isn't it?

[BielBdeLuna]

ok, some info from my comparison of vanilla d3 and Rebb ambient fix interaction.vfp, the changes are in the fragment part of the shader. so the changes should go to the pixel shader rather than the vertex shader.

also rebb's fix only contains a interaction.vfp inside his pk4 so there wasn't any c++ changes. I'll keep comparing...

[kortemik]

@BielBdeLuna I hope you find this helpful http://tomdalling.com/blog/modern-opengl/07-more-lighting-ambient-specular-attenuation-gamma/ :)

[nbohr1more]

Rebb broke ambient rendering into it's own dedicated interaction after the TDM 2.0 release. Sikkpin did this as well in his Breadcrumbs project. The "Ambient Light mod" was wasteful because it tests all surfaces and adds overhead every light pass. As I recall the advanced ambient stages (which we modified from Bloodrayne's Hexen Mod versions) only kick-in when dynamic ambient light is used. So, from versions 1.0 to 1.02 we had Rebb's original fix, then in v1.03 to v1.08 we had JC Denton's version of Bloodrayne's ambient texture stage from v1.03 to v1.08, and now we're using Rebb's fix but as a dedicated shader rather than part of the main interaction plus JC Denton's ambient texures in some situations.

[BielBdeLuna]

apparently bfg has the ambient light separated from the integration also. and also apparently it has a different ambient light pixel/vertex shaders for skinned surfaces.

tell me nbohr1more, does JC Denton's differ visually from Rebb's?

how does Sikkpin did it? and Bloodrayne? Bloodrayne called the ambient term from the material shader, or something similar, isn't it?

[BielBdeLuna]

yeah screw rebb's.... i'm looking at the glsl code. in interactionAmbient.pixel why ambient light has a vector "ambientLightVector", it seems wrong.

here is the code in d3bfg: (...) const half3 ambientLightVector = half3( 0.5f, 9.5f - 0.385f, 0.8925f ); half3 lightVector = normalize( ambientLightVector ); (...) half3 lightColor = dot3( lightVector, localNormal ) * lightProj.xyz * lightFalloff.xyz; result.color.xyz = ( diffuseColor + specularColor ) * lightColor * fragment.color.xyz;

this leads me to think that in d3bfg ambient light has a direction: the initial half3 vector wich has a highly vertical projection (9.5f) so ambient light comes from above.

so we might have to change this. maybe we can erase the calculation of a light direction in the result.color.xyz

so I'll try to calculate a new ambient and sum it to diffuse + specular + a new ambient and still use a lightColor but not add the ambient there.

I suspect this lightColor is used "per light" in the scene...

just ideas guys, I'm just still figuring this all out.

[RobertBeckebans]

Simply remove dot3( lightVector, localNormal ) and you have a general ambient light term without the fixed directional lighting.

Result: Crytek Sponza Atrium https://dl.dropboxusercontent.com/u/22890478/RBDOOM-3-BFG/base/screenshots/rbdoom-3-bfg-20140419-151601-001.png

2014-07-28 23:05 GMT+02:00 Biel Bestué de Luna notifications@github.com:

yeah screw rebb's.... i'm looking at the glsl code. in interactionAmbient.pixel why ambient light has a vector "ambientLightVector", it seems wrong.

here is the code in d3bfg: (...) const half3 ambientLightVector = half3( 0.5f, 9.5f - 0.385f, 0.8925f ); half3 lightVector = normalize( ambientLightVector ); (...) half3 lightColor = dot3( lightVector, localNormal ) * lightProj.xyz * lightFalloff.xyz;

result.color.xyz = ( diffuseColor + specularColor ) * lightColor * fragment.color.xyz;

this leads me to think that in d3bfg ambient light has a direction: the initial half3 vector wich has a highly vertical projection (9.5f) so ambient light comes from above.

so we might have to change this. maybe we can erase the calculation of a light direction in the result.color.xyz

so I'll try to calculate a new ambient and sum it to diffuse + specular + a new ambient and still use a lightColor but not add the ambient there.

I suspect this lightColor is used "per light" in the scene...

just ideas guys, I'm just still figuring this all out.

— Reply to this email directly or view it on GitHub https://github.com/RobertBeckebans/RBDOOM-3-BFG/issues/145#issuecomment-50400683 .

[BielBdeLuna]

kortemik I find your page very useful but I've fount that pixel/vertex implementations rely heavily on what the c++ code give to them. so what seems logical from a point of view it might not work on the code already programmed in. in that page there is this:

` vec3 ambient = light.ambientCoefficient surfaceColor.rgb light.intensities; `

this is the color of the ambient, because it's a vec3 (a vector of 3 values: R,G,B), and it actually says: ` color of ambient term = amount of ambient light color of the surface color of the ambient light `

but how we define amount of ambient light? by using a structure (that I guess gets his variables feed up by the engine) this "struc" is defined above with the following code:

` uniform struct Light { vec3 position; vec3 intensities; //a.k.a the color of the light float attenuation; float ambientCoefficient; } light; `

this "light" at the end is the name of the structure. and it serves for all lights. in the case of an ambient ligvht we get the two variables that then we use: --> ambientCoefficient (amount of ambient light) it's a float (a value in-between 1.0f and 0.0f ) --> intensities ( colour of the light) it's a vec3 again (again R,G,B)

now d3 does all of this differently, still this is very informative on the matter, and I'm thankful for the link

[BielBdeLuna]

Cool RobertBeckebans!

[BielBdeLuna]

yes! solved! well at least I hope my research served to someone... :P

[BielBdeLuna]

I wonder. could we add a new sampler2D register for a " roughness" texture? so we could have both the possibility of the current half-lambertian term and something like a oren-nayar-like diffuse term

the oren-nayar-like could be used for stones, in order to get the less plastic look even for skin (skin without sub-surface)

[BielBdeLuna]

I have this hlsl oren-nayar implementation http://content.gpwiki.org/index.php/D3DBook:%28Lighting%29_Oren-Nayar

[BielBdeLuna]

it would be cool to use the ambient light for the black places in the model, the normal lambertian term for the metallic parts of the model, the half-lambertian term for the skin (if we don't have a sss shader) and the oren-nayar for rock and cloth. even a Fresnel term for some cloth and for the water effects. this would make the engine look more advanced. we could make these shaders selectable via the material with a new command.

[cs121]

oren-nayar adapted from http://www.aoc.nrao.edu/~krowe/cooling_talk/bin/VCG/MeshLab/shaders/Oren-Nayar.frag idk if its correct, but it seems to work.

... // RB end localNormal.z = sqrt( abs( dot( localNormal.xy, localNormal.xy ) - 0.25 ) ); localNormal = normalize( localNormal );

float roughness = 0.21f;
half specularPower = (1.01f-roughness) * 100.0f;
float specularIntensity = 1.1f;
float diffuseIntensity = 1.0f;

float roughnessSquared;
half hDotN = dot3( normalize( fragment.texcoord6.xyz ), localNormal );

vec3 L = normalize (lightVector);
vec3 V = normalize (-fragment.texcoord9.xyz);
vec3 N = normalize (localNormal);

float vdotN = dot3(V, N);
float ldotN = dot3(L, N);
float irradiance = max(0.0, ldotN);

if defined(USE_HALF_LAMBERT)

// RB: http://developer.valvesoftware.com/wiki/Half_Lambert
half halfLdotN = dot3( localNormal, lightVector ) \* 0.5 + 0.5;
halfLdotN *= halfLdotN;
half lambert = halfLdotN;

else

half lambert = ldotN;

endif

//oren-nayar shading model

float A = 1.0 - (0.5 * roughnessSquared) / (roughnessSquared + 0.33);
float B = (0.45 * roughnessSquared) / (roughnessSquared + 0.09);    

float angleViewNormal  = acos(vdotN);
float angleLightNormal = acos(ldotN);
float angleDiff = max(0.0, dot(normalize(V - N * vdotN), normalize(L - N * ldotN)));

float alpha = max(angleViewNormal, angleLightNormal);
float beta  = min(angleViewNormal, angleLightNormal);
float orennayar = irradiance * (A + B * angleDiff * sin(alpha) * tan(beta));

// RB: added abs
half3 specularContribution = _half3( pow( abs( hDotN ), specularPower ) );
half3 diffuseColor = diffuseMap * diffuseIntensity * rpDiffuseModifier.xyz;
half3 specularColor = specMap.xyz * specularContribution * specularIntensity * rpSpecularModifier.xyz;
half3 lightColor = lightProj.xyz * lightFalloff.xyz;

//
// shadow mapping
//

... result.color.xyz = ( diffuseColor + specularColor) * orennayar * lightColor * fragment.color.rgb * shadow;// + rimColor;

[BielBdeLuna]

interesting. but oren-nayar is another "diffuse" term you're using both oren-nayar and half-lambert which both are diffuse terms isn't it?

maybe we could de-itegrate the interaction shader with the different sterms... so it would be a lambert.pixel and .vertex and a specular.pixel and .vertex. and then in the gameplay apply them sequentially phong-wise? that way we could select what shader use in the diffuse term and so on in the material definition.

[BielBdeLuna]

done pull request for ambient fix

[BielBdeLuna]

here is a glsl fresnel term: a fast method and a "very fast method" it would be cool to have the specular loose intensity when looking to the surface in an angle close to parallel to the normal while getting the full specular reflection when seeing the surface from an angle close to perpendicular to the normal of the surface, the the materials could have an IOR (index of reflection) that defined how much the specular looses intensity or gains it.

here's the link, note though that whatever glsl code has to be adapted to doom3 http://www.geeks3d.com/20101008/shader-library-chromatic-aberration-demo-glsl/

[kortemik]

I'd love to see neat plasma effect using this one :dango:

[BielBdeLuna]

but the point is not the chromatic aberration but the fact that in there there are two methods by which we could achieve a fresnel term.

[motorsep]

alright, let me jump on board of the dream train too :)

http://youtu.be/UXeH9OqygzI?t=1m45s << how is this done (light / particles interaction) ? Since RBDoom 3 has shadows map, is it already possible ?

What about particles casting shadows? https://www.youtube.com/watch?v=NW0mjo0sDZI

[BielBdeLuna]

Sikkpin already created "feathered particles" or soft particles, this should be doable.

also from hl2 there is this idea of influencing the colour as well as lightness of the particle with either the ambient lights as well as diffuse lightning in which the particle stands on (it's origin). it should be calculable with not much effort what colour from lightning that point has.

also there is the idea of deforming the normals of the vertices of the particles seem reasonable it would fool the light system giving the particle (a plane) a rounder form in terms of light direction

also as explained in the making of shadows of the colossus, it seems that they were using gouraud shading with the particles (I don't know if gouraud shading uses the normals at the vertex to calculate the colour gradients) but they used the resulting gouraud gradient to tint the particle texture giving it some novel light direction to a bland cloud texture, this seems doable too, I think gouraud shading can be achieved with vertex programs.

[motorsep]

I don't think what you are talking about has to do with transparent surfaces casting shadows and light interacting with particles :/

@RobertBeckebans does having shadow maps automatically enable renderer to cast shadows from translucent surfaces ? (I assume some work has to be done, but is it renderer overhaul type of work or just minor tweaks)

[BielBdeLuna]

no, Motorsep. I talked about options for rendering a more realistic than the stock method, at least that that I knew about and that I could see a way to implement, in a doable way.

[BielBdeLuna]

I'm toying with the idea of having a Fresnel term, we could include the function in globals.inc or have it in it's own inc, it's quite simple:

float projection_factor ( vec3 vpos, vec3 normal ) {
    float a = dot ( normal, vpos );
    return 1.0 - a;
}

float schlick_fresnel ( vec3 vpos, vec3 normal, vec3 fresnelValues ) {
    float bias, power, scale, result;
    bias = fresnelValues.x;
    power = fresnelValues.y;
    scale = 1.0 - bias;
    result = bias + pow ( projection_factor ( vpos, normal ), power ) * scale;
    return fresnel;
}

it derives from a paper by Christophe Schlick and it's an approximation for the Fresnel term: http://www.cs.virginia.edu/~jdl/bib/appearance/analytic%20models/schlick94b.pdf

Schlick formula is the following: R(t) = Ro + (1 - Ro) * ( 1 - cos(t) )^5 and Ro = ( ( n1 - n2 ) / ( n1 + n2 ) )^2 where: R = reflection coeficient Ro = reflection coeficient for light incoming parallel to the normal (i.e. when ŧ = 0 or minimal reflection) t = angle between the viewing direction and the half-angle direction, which is halfway between the incident light direction and the viewing direction n1 = indices of refraction of the two medias at the interface n2 = indices of refraction of the two medias at the interface

I think at the moment we could use this with two separate specular terms, one of value 10.0f (like the normal) and another with a value of around 3.0f (almost like the diffuse term ) and the Fresnel term would influence both. so when looking at something from a point of view closer to the normal of the surface, it would use the regular specular term, while if looking at the same surface from a point of view almost perpendicular to the normal of the surface (almost parallel to the surface) then we would use the "diffuse-specular" (so to sum up, things would become more diffuse on the edges)

now Fresnel can be used for several things, you only need to calculate once and you can reuse for several stages. or you can have several Fresnel terms and play with the Fresnel values. what do you think?

[darkhemic]

Alright. This is my first post. I'm going to start off I haven't done much in the way of Doom3 and going off knowledge that I know from reading some forums and haven't coded anything that wasn't Unreal script or Unreal Blueprint scripting in a long while. I'm looking at this as an Engine vs Engine artist view that each game engine brings it's own feel to the game. I loved the feel of all Id Tech engines. With the current state of everyone's great work I only see one thing that is missing besides megatextures is tessellation for a graphic feature. Could this be coded in as a shader type without breaking anything while playing the normal doom 3 BFG? The engine already has soft shadows and the rest of everything everyone has already done, this engine already looks really nice.

[BielBdeLuna]

it seems it's quite work to be done.

[BielBdeLuna]

I found this:

https://github.com/NVIDIAGameWorks/OpenGLSamples/tree/master/samples

[darkhemic]

@BielBdeLuna I was finally able to read over the Nvidia sample. It does indeed seem like a lot of work. I was just looking at it from a Game Artist Perspective and little programming experience. I know enough programming to be able to talk to all you wonderful programmers without being completely confused about designing assets using features to optimize the performance of a game engine. Again I love all the work that every here is doing to the hybrid Id Tech 4/5 engine here, but the polygon count used on static meshes is the only thing I see graphically that doesn't look as nice as some other engines. --on a side note, while I am using a different game engine currently (in college my final year) for portfolio pieces just because of the ease of use, I'd love to make assets if everyone decides to expand this project into a standalone replacement to show off all the great features everyone has been working on here.

[BielBdeLuna]

Darkhemic. that would be great, it would be great to have collage people working on this. there is a project that also is working in this direction which is a fork from RobertBeckebans's wich aims to do something more akin to a asset replacement. take a look here: https://github.com/OpenTechEngine/OpenTechBFG

On the static mesh triangles and tessellation issue. I would say a middle ground in-between what we have now and tessellation could be to have a LOD system, and that could be the LOD system from the DarkMod https://www.youtube.com/watch?v=xJyHbaVkbwI which already seems pretty difficult work to me (adapting the code from d3linux to d3bfg can prove a difficult task even for simple code, well, at least for me, an inexperienced programmer, and in itself already it's might be lot of work)

it seems the next closes thing to get that more increased triangle count in meshes as well as the more simple thing rather than implementing a tessellation algorithm. But maybe even if more difficult to implement a tessellation algorithm proves more useful on the long run?

I'm puzzled though. how does one author models for a tessellated engine? one does the highest poly count mesh and then the computer, on the fly, breaks the mesh to whatever triangle count it sees fit?

[darkhemic]

To create tessellation on the gpu is a shader, because it's a shader it also requires a texture to work properly. It works similar to the tessellation that is used in the doom3 engine LOD. The artist can create a high poly and low poly model and bake a texture the high to low poly model. It creates a black and white texture, black moving into the low poly model and white moving away with 50/50 gray just giving a smoothing effect. I said it's similar because in many of the game engines it works on a LOD system so the tessellation only happens as you move closer to the object. In UDK, an artist who doesn't know any better or is learning can make the mistake of just applying tessellation to a model without including the correct effects to include it in the LOD system. For tessellation to be useful, think about ET:QW map, large outdoor world. FAR FAR off in the distance you see a statue and id tech 4 is using it's LOD system. As you move closer more triangles are drawn and rendered still using the default LOD system. Then you reach the point at which the model is completely rendered as the artist created it and is included in the game assets. This point could be moved back just a couple of "feet" and the tessellation shader gets turned on. Meaning now as you move closer to the statue the model is rendered as it was with the high polygon model in modeling program. UDK and Unreal 4 allow you to also control in the shader the maximum number of extra divisions the tessellation causes on the polygons to help the performance. You don't need it to divide 1 polygon 100 times for a game and some models could require more tessellation than others so adjusting that value gives better artistic control and optimization. But unlike the doom 3 LOD tessellation system the texture moves the vertexes in and out from the original model like a terrain heightmap and doesn't just smooth the surface of the mesh.

And I will definitely look at OpenTechBFG.

[BielBdeLuna]

d3 doesn't use a LOD system, not even the quake 3 LOD system, even the NURBs use a LOD system. so a basic LOD system has to be reintroduced if we want to show a lot of models in-game, that's the reason I was talking about the dark mod LOD system. they added a LOD system in vanilla doom3. and now we could bring it to d3bfg. this all as a first step for further improvements.

so tessellation is nothing more than a higher quality parallax mapping which actually creates new vertices on the fly instead of textures displacement trickery. thought it was used differently more akin to a global LOD system. rather than the last stage in a LOD system.

[darkhemic]

I thought the vanilla doom 3 code had a lod system on the models with the older tessellation system, my mistake. And gpu tessellation could be used as a global LOD system but it from what I've seen using other engines it make more sense for performance to apply and adjust tessellation to models and leave things like bsp brushes alone and use parallax mapping on them. You would have to divide a brush up so many times to get the effect that parallax mapping can fake without as much of a performance hit.

[motorsep]

Seriously?!

http://en.wikipedia.org/wiki/Tessellation_(computer_graphics) http://www.nvidia.com/object/tessellation.html

I've yet to see a game where tessellation was used for lower iterations of LOD. It's mostly used to generate more detailed mesh from existing one. DX11 hardware is required (mostly higher spectrum of modern GPUs), which significantly cuts down your userbase.

POM taxes your system badly, I am not sure where "without as much of a performance hit" comes from.

Are you guys all with 4+ core CPUs and latest GPUs with 256+ bit VRAM bus?

[darkhemic]

I'm running a AMD FX CPU, Firepro GPU and 16gb of ram for content creation. When that being said I know gaming performance is not as good as a radeon or geforce GPU, the firepro was cheaper and performed better for what I could afford to fix problems in the maya and mudbox viewports, as I'm back in college. I do have another computer for playing my games which has a geforce gtx 550ti. If you attempt to apply tessellation to something like a BSP brush, which for 1 plane say the ground, you have 1 polygon surface which is 2 tris. When you break that up in tessellation can cause cracks in the surface, in order to fix those gaps and give a better visual look to the surface you'd have to break it up even more or apply addition code fixes to minimize the cracks and make the surface whole, which greatly lowers the performance compared to just applying a parallax map. Yes both do affect the performance but it's about weighting which one is the greater of the 2 evils on performance for the geometry and quality you are looking for.

Here is an article taking about tessellation performance and cracks in unreal which happens in both udk and unreal 4. http://udn.epicgames.com/Three/TessellationDX11.html

Here is an article taking about dx11 features in the crytek engine and reason Also another link talking differences in tessellation methods and cracks. I haven't used or experimented much with the crytek engine so I'm not sure how they are doing the LOD tessellation on surfaces like the water.

http://www.behardware.com/art/imprimer/838/ http://docs.cryengine.com/display/SDKDOC2/Tessellation+and+Displacement

[motorsep]

lol.. How about checking Steam hardware survey and understanding what majority of people game on?

Tessellation was not designed for brushes, it was designed for polygonal models. And displacement is != POM. Displacement deforms actual tessellated geometry. POM is fake (can be a good one, depending on implementation), but also performance taxing.

[darkhemic]

I understand what the majority of people currently use as a gaming system. Console commands could be added placed to switch between a opengl3 and opengl4(dx11) mode or turn off tessellation. I brought up tessellation as a possible feature. BielBdeLuna and I were discussing the applications of tessellation and the differences. The term brush may have been a wrong choice of word, any large polygon surface can have problems with tessellation.

[BielBdeLuna]

nevermind tesellations for the moment, we have to find a way to convert the models into somewhat brushes, discard so many func_static, and use those entity slots for actual entities that do something other than be there.

if we could separate the model that the game displays as "the map" and the actual map (the polygons that actually are used to calculate the portals, and visibility), and even use several models for different portal sections of the map and somewhat bind those models to the portals, then we could do some LOD processing to the actual map models not the func_static ones. with this separation we could have also vertex painting effects on the "brushes/models", this and instancing would be really neat in order to do bigger cities using a lot of repetition of the assets.

[darkhemic]

Would that require the creation of a different map file format for the reading of two different map types?

[BielBdeLuna]

yes, the development of a next gen map format. that would be an evolution of what already it's there but with some more info for the engine to play with. I think of it more like how AAS info is not visible but it's there. and it's fairly independent of the triangles that you generate via brushes, although it's generated from the same brushes that were used for creating those same triangles. well why not add a new layer of information which controls what we see, and so with it we add a link to the LOD system, that is when we have one there.

[RobertBeckebans]

I implemented a PBR approach in https://github.com/RobertBeckebans/RBDOOM-3-BFG/commit/e9e0fd3c0860ada0aa508d9d7f278295010bbbde

[RobertBeckebans]

The PBR mostly affects the specular lighting as the diffuse lighting is still Lambert or the optional Half-Lambert. It is not really physically correct with r_lightScale 3 as the default setting which is passed to the diffuse and specular modifier. However it is a start for people who want to create new content and want to see how PBR can be implemented with Doom 3.

[BielBdeLuna]

interesting

[BielBdeLuna]

how does it work. how do we use it?