code FEATURE: OpenGL 3 Renderer

[DT.]

Q3map can bake in normal maps but it looks quite shit so I fixed misc_dlight instead. Check my commits for a pic.

 

Yeah I saw that they use dds as well. I tried bringing it in but failed. Perhaps just use tga instead to save the cubemaps?

 

I'm very interested in the pshadows code though. Even though it's not finished in ioq3, it's getting there. Currently has dynamic blob shadows for every model whether it be a weapon, item or player.

 

Be sure to merge in my updates to misc_dlight and flare shader.

[SomaZ]

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.

 

 

[minilogoguy18]

Hopefully it won't be abused like the env map is by newbies, making everything look like a glazed doughnut lol.

[DT.]

PBR won't look good unless you have the assets for it.

 

@@AshuraDX please good sir, would you like to whip up a test for us using your clone perhaps? I'll sort out the shader, just need the model + textures.

[AshuraDX]

PBR won't look good unless you have the assets for it.

 

@@AshuraDX please good sir, would you like to whip up a test for us using your clone perhaps? I'll sort out the shader, just need the model + textures.

I'll see what I can do, I have a static version of my updated clone ingame for use on my turntable if that's enough for now. Otherwise I could weight it and skip LODs for now to get you a quick test mesh.

 

@@minilogoguy18 Everything looks like a glazed Donut there because it lacks a roughness/gloss map.

 

@@SomaZ which maps does the shader require/support? Does it use metal/roughness or spec/gloss?

[SomaZ]

I'll see what I can do, I have a static version of my updated clone ingame for use on my turntable if that's enough for now. Otherwise I could weight it and skip LODs for now to get you a quick test mesh.

 

@@minilogoguy18 Everything looks like a glazed Donut there because it lacks a roughness/gloss map.

 

@@SomaZ which maps does the shader require/support? Does it use metal/roughness or spec/gloss?

// 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

[DT.]

I'll see what I can do, I have a static version of my updated clone ingame for use on my turntable if that's enough for now. Otherwise I could weight it and skip LODs for now to get you a quick test mesh.

 

@@minilogoguy18 Everything looks like a glazed Donut there because it lacks a roughness/gloss map.

 

@@SomaZ which maps does the shader require/support? Does it use metal/roughness or spec/gloss?

Just make an MD3 model out of it, i'll load it with misc_model_static. Use the latest MD3 exporter from Archangel to preserve normals.

[AshuraDX]

@@SomaZ

That gloss definition is not defined by the material per surface but globally by a console command?

[DT.]

Pretty sure that's how it is in ioq3's GL2. Would be better to move it to shaders though.

[SomaZ]

@@SomaZ

That gloss definition is not defined by the material per surface but globally by a console command?

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.

[SomaZ]

@@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.

[DT.]

Will do.

[minilogoguy18]

So excited that this is creeping forward, I hope that it can be fully implemented.

[DT.]

Still get the odd crash when loading a map and doing vid_restart too many times, but other than that it works.

[SomaZ]

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/

[Xycaleth]

Since it looks like this is ramping up a bit, I'll ask some questions which I've asked myself and didn't really like the answer. Making maps is already a long process. Adding more advanced tech on top of that like cube maps, pbr, realtime lighting adds an extra complexity to the process and requires more attention by the mapper. How can you make this easier? The main example I have in my head is how big is the area influenced by the cube map? Like SomaZ already mentioned, you could add a radius to the misc_cubemap to restrict the area that is affected, but there's no easy way to are this area in Radiant. You can support dynamic lights but there's no good way to preview and adjust these without a long compilation time every single time you want to change it a bit. For PBR materials, its not so much of an issue because you generally need the right tools to make them in the first place.

 

The only answer I can come up with that integrates well with the engine, is to build them into the engine. Make it possible for dynamic lights to be positioned when you're running around in the map. Draw where the cube maps are and show their radii and allow them to be moved around and resized. Maybe I'm wrong, but I think people will get frustrated with not having at least some realtime feedback.

 

The alternative is to change radiant but that I think is a much bigger task.

[DT.]

Sure it sucks that you can't preview them in radiant, but it's the same sort of thing when placing any lights. I wouldn't say creating them in-game would be a good idea but more editing the properties in-game. Speaking of lights, light styles is broken in rend2 SP and possibly rend2 MP.

 

For dynamic lights usage - Need a light to pulse (go from one color/brightness to another), stay a constant color/brightness or be switchable? use misc_dlight. If you need something with a little more personality like say flickering light from a candle or fire, use the light property in EFX files. EFX light can be distance culled, misc_dlight cannot. I'm hoping I can just rig up triggers to turn areas on/off as you enter/leave them.

 

 

@@SomaZ, knock yourself out.

 

ioq3's shadow maps code is still broken, but has made progress. Currently, all you get with cg_shadows 4 is a dynamic blob shadow.

[DT.]

@@SomaZ, be sure to grab my latest commit.

[Archangel35757]

@@SomaZ

...add light entities (see above, name idea: misc_plight, misc_slight, misc_tlight)

Isn't the term "directional light" the industry venacular for your "tubelight"?

 

dlight is already used for dynamic lights, but since we are talking a direction, which is a vector...

 

I would call it misc_vlight (for a directonal vector light entity).

 

@@Xycaleth - An in-game light editor (for position, orientation, & property changes) is an awesome idea. Sounds like you are describing this editor:

 

http://wiki.reflexfiles.com/index.php?title=Reflex%27s_Level_Editor

 

Do any open source editors have light editors?

[SomaZ]

Since it looks like this is ramping up a bit, I'll ask some questions which I've asked myself and didn't really like the answer. Making maps is already a long process. Adding more advanced tech on top of that like cube maps, pbr, realtime lighting adds an extra complexity to the process and requires more attention by the mapper. How can you make this easier? The main example I have in my head is how big is the area influenced by the cube map? Like SomaZ already mentioned, you could add a radius to the misc_cubemap to restrict the area that is affected, but there's no easy way to are this area in Radiant. You can support dynamic lights but there's no good way to preview and adjust these without a long compilation time every single time you want to change it a bit. For PBR materials, its not so much of an issue because you generally need the right tools to make them in the first place.

 

The only answer I can come up with that integrates well with the engine, is to build them into the engine. Make it possible for dynamic lights to be positioned when you're running around in the map. Draw where the cube maps are and show their radii and allow them to be moved around and resized. Maybe I'm wrong, but I think people will get frustrated with not having at least some realtime feedback.

 

The alternative is to change radiant but that I think is a much bigger task.

 

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.

[DT.]

Do any open source editors have light editors?

 

Doom 3 is open source, and has radiant built-in. I can't manage to compile GTKRadiant or any other of the radiants or even q3map2. :\

 

I much prefer the placement of the light ents in radiant, and then adjusting values on the fly in-game.

[Archangel35757]

but the ability to tweak the light position/orientation in-game using some new light editor would be much welcomed.

[SomaZ]

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...

[DT.]

Could spawn a ui box full of the dlight properties. If you choose this method, let me know as I can do up menu files. As it is, I need to do up a GL2 menu.

 

Anyhow, a big issue would be how to save. Could save the updated info back into the .map file OR create a .dlights file which would just store all dlight ent properties. The code would load this file after loading the BSP.

[Archangel35757]

@@SomaZ - I think a feature like editing lights should only be available to a "special" light compile build and not available for the final compiled map... not sure if that is possible.