SomaZ

@@AshuraDX Thats so crazy, I will Look at it, when I have some time. Must be something with the renderer then.

@@AshuraDX Are the hard edges split into two separate ones? If I recall correctly, every vertex normal is smoothed for shading. Maybe thats the problem?

Nonono. Reflection intensity is implicitly controlled by the metalness and albedo map. Sharpness of the reflection is controlled by the gloss or roughness map. Shader Code (a little bit simplified): specular.rgb = metal * diffuse.rgb diffuse.rgb *= 1.0 - metal; (metal objects have a black diffuse, but we get the reflection color from the albedo, see the line above) //code that is missing right now: diffuse.rgb += AO * aoStrength; (this is kind of the classical diffuse map) So, the only maps you need for the pbr metal roughness workflow are albedo, normal and a packed texture with grayscale metalness in the red, grayscale roughness in the green and grayscale ao in the blue channel. The specular textures AshuraDX supplied are the packed textures. With that you can build the .mtr { map models/weapons2/clonedummy/body_albedo rgbGen lightingDiffuse } { stage normalmap map models/weapons2/clonedummy/body_normal } { stage specularmap map models/weapons2/clonedummy/body_Specular } I hope that clarifies things a bit.

@@DT85 Sry, to answer the questions for AshuraDX. It should look kind of like this: He used a roughness map. So glossType 2 (Roughness) The albedo map is kind of a diffuse map. Though it lacks every other shading like AO. This is because of the metal rougness workflow. Reflection color is controlled by the albedo map + metalness maps. AO is classicly applied after getting the reflection color from the albedo to get the diffuse color. For this video I used the diffuse instead, since ao map handling is not presend at this moment.

@@DT85 exporting the cubemap works fine. Don't know what's the problem. It saves them in Documents\my games\OpenDF2\base\cubemaps\map_name\. The file extension is wrong though.

@UniqueOne You are a hero. ♥ With these I can possibly add the dlight editor mode, without researching for months. Sure you postprocess them, you use deferred shading right? @@DT85 I'll check that. Better get the conversation back to to right place.

Has someone ever tried J.A.C.K.? http://www.moddb.com/groups/jackhammer-my-favorite-level-editor/downloads Maybe you can rotate a level without loosing uvs? Nevertheless, it looks a lot easier than radiant.

I'll just drop this here.

Funny thing is, that the bsp stores the misc_cubemap and the misc_dlight entities as normal text. At least Notepad++ can show them. Maybe it is possible to save directly to the bsp, or? Is bsp streamed? I need to investigate. @@DT85 I have no idea how to handle UIs in the JK code. Your help would be greatly appreciated. @@Archangel35757 Why? Lights from the game doesn't get stored. It's just about dynamic lights.

Ok, ok. Before anyone starts whining. I have an idea how to edit misc_dlights in the engine itself. Maybe @@DT85 can help me a bit with it. Workflow would be: -> place misc_dlights in radiant -> fire up the game -> r_editMiscDLights 1 -> in the upper corner of the screen some variables appear (some get_closest_misc_dlight function is needed) -> r_setColorCurrentLight 1 1 1 25 (not sure if this works LOL, maybe with quotes) -> engine shows edited misc_dlight -> some save function would be nice For positioning the light, I'd say we can toggle some kind of player attachment. For example: -> r_attachDLight (maybe toggle function so you can easy bind it to a key) -> move around (misc_dlight entity follows relative to players position) Will put it to the todo list...

I don't think that it's our problem though. My idea behind it is, that we attract more people to come up with solutions for this problem. Right now its like 3-5 people interested in writing a renderer, and everyone has his own branch or idea behind it. We can't deal with the complete mapping process on the side, as this is also very complex. We can only make it as simple as possible, or as intuitive as possible for mappers. Adding entity types is kind of simple and intuitive, as every mapper has to use them, no matter if it's for rend2 or not. (and they already get stored in the bsp, which is very nice) I myself just want to provide the tech to make things look great in the engine. Let's say if we ever make it to finish proper PBR rendering and make an awesome video with it, I'm pretty sure we could get a lot of attention. In my best-case scenario, we get some attention by some nice Unity guys, who will write an Unity Map to id3 Map exporter (in .map or .bsp is irrelevant). This could "revive" the JKA modding scene. Bring attention to OpenJK or OpenDF2 and so on. But first, we need to provide the tech. Without it, it's kind of useless to write an unity exporter, as people don't like investing time in things that probably will never be finished. The modding community has always been very creative in finding solutions, why not in this case? @@Archangel35757 A tubelight is not a light that is emitting in one direction (vector), but the emitting source is a tube (that is emitting in every direction). In UE4 it's a pointlight with a radius and a length. I think what you mean with the directional light is something like the sun. Something with parallel light rays, right? @@DT85 I surly will.

First of all, thank you DT for the map. But now, I'm kinda unsatisfied by the way how lights work in the engine. I'd like to add 1-3 new light entities to the render code if thats ok with you guys. Point light, spot light and a tube light to be exact. Parameters would be: - Color (normalized by the renderer, so it doesn't effect the strength of the light) - color temperature - intensity (luminous power) - attenuation radius (like the radius right now with lights and dlights) - radius (size of the emitting light source) - specularScale (how strong specularity is affected by the light) - diffuseScale (how strong diffuse is affected by the light) - orientation (for spot light and tubelight only, for point lights with IES profile) - length (only for tubelights) - optional: IES profile (though this could be hard to implement, have no idea) This could take a bit to implement, but it would be very helpful imo. Seriously. Pbr is shit without proper lights. Stuff on the todo list right now: - update cubemapping code to ioq3's state - add shader parameters for gloss roughness shininess smoothness and remove the corresponding cvars - weather (hell, since I'm no Xycaleth, this could take some time...) - add light entities (see above, name idea: misc_plight, misc_slight, misc_tlight) - realtime shadows code from ioq3 (maybe I need to write a complete new code for the new lights. I have no overview over ioq3s shadow code yet) - (with aboves shadow code: maybe save a lightmap out of it? Then we don't need realtime shadow calculations on static meshes? Just a thought I had right now) - add horrizon fading parameter in shaders for normalmapping (should be easy to implement. see http://marmosetco.tumblr.com/post/81245981087 ) done - add dlight editing mode Btw. @@DT85 You can add radius to the misc_cubemap. It corrects the perspective for the cubemaps. See http://seblagarde.wordpress.com/2012/09/29/image-based-lighting-approaches-and-parallax-corrected-cubemap/

@@DT85 Can you be so kind and give me a map with misc_dlights? Prefereably with the map file. That would be helpfull. Pretty please.

Unfortunatly yes. I will relocate the code to the shaders later, as Dt already suggested (was on my todo list already ). The cvar was very helpfull for testing though.

// specular red is gloss // specular green is metallicness Though you can use gloss as gloss, as smoothness (never heard of it before), as roughness or as shininess (never heard of it too) with r_glossType 0-3; From the shader: #if defined(GLOSS_IS_GLOSS) float roughness = exp2(-3.0 * gloss); #elif defined(GLOSS_IS_SMOOTHNESS) float roughness = 1.0 - gloss; #elif defined(GLOSS_IS_ROUGHNESS) float roughness = gloss; #elif defined(GLOSS_IS_SHININESS) float roughness = pow(2.0 / (8190.0 * gloss + 2.0), 0.25); #endif

So, I made some progress with the pbr code. I think its usable in the current state. It hardly differs from the ioq3 shader. I added a neat little thing to it from Xycaleths code.

No wonder they can't be really seen. It's the same for every engine. Like UE4. The Lightmap doesn't store light positions. It only lighten and darken areas and only applies to stationary light sources. UE4 simply uses the normalmaps for genereating the lightmap. You can do the same thing in GTK Radiant with the material shaders. q3map_normalimage textures/.../aaa_normalmap q3map_lightmapsamplesize 1 There is a tutorial in JKHubs tutorial section. So, on my front: I added the pbr cvar and some other stuff on my repository. Just needs some testing and validating the correctness of the code, but it works. Next thing I want to update is the complete cubemapping code. ioQ3 allows to render cubemaps to files and read them back without rerendering them.

Yea, I tested if I could simply do a 1 on 1 port with the vanilla weather system. I'm positive that this can be worked out. Though a complete new weather system would be nice. But right now, I'm trying to make refraction work like a charm. Learned a lot about the renderer and I have a plan to completely rework the refraction code to fit the overall coding "style". Right now it's unnecessarily redundant and hacky. I also need to find a fix for the force speed effect. My guess is, that a renderfx flag (something with skipping the shadow calculation on the mesh) is unnoticed by the renderer. Just need to find the right place to add the exception. I also noticed that my shader is not doing what it's actually supposed to do.

Actually a nice idea, but the code doesn't differentiate between push and pull. Could look strange if you use pull and the refraction looks like push. One could change that in the game code though. Simply change the models of push and pull from the half-sphere to something cone like.

Nonono, force speed has nothing to do with refraction. I just hated the fact that it looked so bad in rend2 and found an easy fix. Actually I really like the spherical effect. I could add an alternative shading for it, if somebody tells me how it should look like. If you dislike the force push and pull effect, you can easily disable it now. Simply set "r_refraction 0". I think there are only 3 to 4 effects that use refraction now. 3 of them are push, pull and the shield. Can't remember the last one. I guess it was the sniper trail. I doesn't know for sure right now. ?_?

Oh yea, the pause is caused by the way the alpha is calculated. It counts down from like 240 to 10. Should be easy to fix. I guess I can fix that later today.

Progress!

Ok, good news everyone. I got the refraction rendering working in SP. @@DT85 There seems to be a little mistake in your RB_RenderDrawSurfList . I just copied the first part (first line to the part where my code hooks in) from the mp rend2 and it starts to recognise the refractive surfaces. I'll try to figure out what causes the problem. Also the cull type for the refractive surfaces should be CT_BACK_SIDED. I have no idea why, but it works for force push and pull. I guess I'll add the rest of vanilla features and make a pull request on github. So stay tuned.

@@DT85 Oh, the cvar is r_refraction. Maybe this is the problem? After looking briefly at the vanilla code, I'm pretty sure the sp vanilla code handles the refraction/distortion like the mp renderer. I will still look at it when I'm home.

@@DT85 Crazy, eventually SP handles this differently. I'll check that tonight. Can I get a copy of your code to check it?