Jump to content

FEATURE: OpenGL 3 Renderer


Recommended Posts

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

Link to comment

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? :D 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?

Link to comment

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
Link to comment

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.

Link to comment

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/

Tempust85 and minilogoguy18 like this
Link to comment

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.

AshuraDX and Archangel35757 like this
Link to comment

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

minilogoguy18 likes this
Link to comment

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

Link to comment

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

Link to comment

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.

Link to comment

Ok, ok. Before anyone starts whining. :P 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...

Link to comment

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.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...