Rend2 - A Modern Renderer

[Xycaleth]

those are some damn deep cavities there, I'd suspect that to be a problem with the automatically generated normal map

@@Xycaleth maybe you could introduce a 1px blur for the normal generation to avoid these overly sharp details

That could be the problem, yeah. @@SomaZ, do you have r_genNormalMaps set to 1? Does it still look grainy when you disable it?

 

 

Shadows have a grainy edge and is more noticable when at a distance or at a lowered shadow resolution. From what I remember though, it's the same in ioquake3.

 

 

EDIT:

 

@@Xycaleth

 

Will the new lightmap generator also allow for custom shadow sizing on certain brushes like q3map2?

I'm going to be experimenting with storing only bounced light. Any shadows or lighting as a result of a light source directly affecting some area won't be stored. That will be up to rend2 to handle in real-time. I don't know how well this will work yet so we'll have to wait to see how it goes.

 

So to answer your question, the shadow resolution will be whatever rend2 is set to use since the shadows aren't stored in the lightmap.

 

If you want Q3Map2 lightmaps (which my lightmapper will be able to produce as well), then yep, you'll be able to pick the lightmap resolution as usual.

[SomaZ]

That could be the problem, yeah. @@SomaZ, do you have r_genNormalMaps set to 1? Does it still look grainy when you disable it?

Yea, r_genNormalMaps 1 and it disapears when disabeling it. As I said, it appeared after the big pause. I also had it enabled with the older version and it never appeared that sharp.

[Szico VII]

Okay I just erased the old openjk.vfg and problem was fixed. Started making something

 

 

[Archangel35757]

Okay I just erased the old openjk.vfg and problem was fixed. Started making something

 

Have you ever used IES light data in alpha channels?

 

http://www.cgarena.com/freestuff/tutorials/max/ieslights/

[Szico VII]

Have you ever used IES light data in alpha channels?

 

http://www.cgarena.com/freestuff/tutorials/max/ieslights/

No, never have - this is just using photoshop

 

 

 

[Guest KENNITHH]

That looks a lot like that benchmark thingy of Frostbite Szico

 

Anyway for that IES light, you can "fake it" by using a black on white image of the light and use it as decal on the wall as I did in my Ziba map

[Archangel35757]

That looks a lot like that benchmark thingy of Frostbite Szico

 

Anyway for that IES light, you can "fake it" by using a black on white image of the light and use it as decal on the wall as I did in my Ziba map

for example:

 

[Xycaleth]

I don't think with faking, that will look correct with real time lights. You're effectively adding a lightmap for the direct lighting which is something I want to move away from as it doesn't take into account other light sources which might not be there at compile time (think Lightsabers, etc).

[Szico VII]

Well the ladder shadow and the grate shadow do have "fake" shadows made with textures and alpha maps (easily removed).

 

But dear god - using dynamic lights adds SO much - i didn't think the spec of bump maps were actually doing much until put lightsaber near them! I faked more with effect (fx_runners) but does lag the framerate

 

 

 

 

[Archangel35757]

I don't think with faking, that will look correct with real time lights. You're effectively adding a lightmap for the direct lighting which is something I want to move away from as it doesn't take into account other light sources which might not be there at compile time (think Lightsabers, etc).

So in your Dynamic lighting calculations can you use the true .ies data file that almost all lighting manufacturers now generate and create for all their lights?

[Xycaleth]

So in your Dynamic lighting calculations can you use the true .ies data file that almost all lighting manufacturers now generate and create for all their lights?

I guess it's possible, but at an additional runtime cost.

[Archangel35757]

@@Xycaleth - how then do you accurately compute the dynamic lighting for a certain type of light? I think light entities should have a editable parameter that would accept an .ies file... which if left blank would do things as you currently do... but given the .ies file I would think it would simplify the computations for a light, no?

 

http://www.cescg.org/CESCG-2013/papers/Krochmal-Real_time_prototyping_of_physical_lighting_based_on_goniometric_light_sources.pdf

[Xycaleth]

@@Xycaleth - how then do you accurately compute the dynamic lighting for a certain type of light? I think light entities should have a editable parameter that would accept an .ies file... which if left blank would do things as you currently do... but given the .ies file I would think it would simplify the computations for a light, no?

Lighting is traditionally done by estimating how much light is emitted from an easy to define shape such as a sphere or, even simpler, a point light source. These have analytical solutions so you can take a light source and position to estimate lighting for, and calculate the lighting with a single equation. And doing math operations is cheap.

 

Real lights don't follow any analytical shape (at least, not any simple ones) so the IES profile data provides this shape. But you then need to read this data for every pixel that is lit, and reading from memory is much slower.

Well the ladder shadow and the grate shadow do have "fake" shadows made with textures and alpha maps (easily removed).

 

But dear god - using dynamic lights adds SO much - i didn't think the spec of bump maps were actually doing much until put lightsaber near them! I faked more with effect (fx_runners) but does lag the framerate

 

 

 

 

Dont know how I missed your post. That looks great, Szico! something that irks me about q3map2 is that it doesn't bleed the colours from textures on to surrounding surfaces. You would expect some of the red and green on the pipes and walls to show up on the floor and walls but it doesn't. I guess it saves on having to compile the map every time you change the textures but it would look so much better if it could do that

[Archangel35757]

@@Xycaleth - did you download that PDF?

[Szico VII]

@@Xycaleth - Map is finished, if it has what you need for testing.
 

Dont know how I missed your post. That looks great, Szico! something that irks me about q3map2 is that it doesn't bleed the colours from textures on to surrounding surfaces. You would expect some of the red and green on the pipes and walls to show up on the floor and walls but it doesn't. I guess it saves on having to compile the map every time you change the textures but it would look so much better if it could do that

Yeah, isn't that called subsurface scattering?

http://www.youtube.com/watch?v=Jaqqwk2UaC0

[Xycaleth]

@@Xycaleth - did you download that PDF?

Nope! It wasn't there when I quoted you I had a quick skim and it's like I said, it will incur extra costs. They don't mention how many lights they're rendering in the paper but it doesn't look like there's that many (maybe 3 or 4) but the drop in frame rate is quite a lot. I can have an experiment (i.e. it will go to the end of my todo list) but I don't think it'll be something I add.

 

@@Xycaleth - Map is finished, if it has what you need for testing.

 

Yes, that looks perfect! Could you PM me a link please? Or post it here if you don't mind others using it.

[Szico VII]

Yeah here it is - played with r_hdr 1 and r_parallaxmapping 1. You can remove the effect lighting (fx_runners) and recompile if you wish). Everything else is entity lit.

 

http://www.filedropper.com/theedgecorridoralphav01

[Xycaleth]

Yeah, isn't that called subsurface scattering?

Subsurface scattering is something else (where light bounces around underneath the surface of something, e.g. skin). What I'm describing is just how light reflects off the top of a surface. Imagine a single beam of white light bouncing off a red surface. The surface looks red because it has absorbed the green and blue light, and reflected only the red light - so it follows that light bounced off of this surface will be red, and make things near it red as well.

[Szico VII]

Well thats just plain old reflection isnt it?

[Smoo]

Well the ladder shadow and the grate shadow do have "fake" shadows made with textures and alpha maps (easily removed).

 

But dear god - using dynamic lights adds SO much - i didn't think the spec of bump maps were actually doing much until put lightsaber near them! I faked more with effect (fx_runners) but does lag the framerate

 

 

 

 

Wow so beautiful Good to see you're still active here Szico VII

[SomaZ]

Yeah here it is - played with r_hdr 1 and r_parallaxmapping 1. You can remove the effect lighting (fx_runners) and recompile if you wish). Everything else is entity lit.

 

http://www.filedropper.com/theedgecorridoralphav01

Damn, with parallax my fps drops so hard. The game tells me I have like 35 but it feels super choppy (got a gtx980ti). Nevertheless it looks great. Good work man. I started my own map for rend2 testing purposes but I've no experience with mapping for JKA. Learned the basics I guess, but I never looked into scripting and the fx stuff.

[Archangel35757]

Nope! It wasn't there when I quoted you I had a quick skim and it's like I said, it will incur extra costs. They don't mention how many lights they're rendering in the paper but it doesn't look like there's that many (maybe 3 or 4) but the drop in frame rate is quite a lot. I can have an experiment (i.e. it will go to the end of my todo list)...

Thanks! If you made it a new keyword option on light entities then folks could choose themselves to use it or not...

 

According to that paper the performance hit is minimal:

 

Performance of this model is very close to the point lights rendered with Phong shading. The only additional overheads are the computation of texture coordinates and the LDT texture lookup. For the sample scene containing 103379 triangles the frame rate is 56 frames per second for point lights and 50 frames per second for our approach. The test was conducted with ATI Mobility Radeon HD 4670 graphics card, Intel Core2 Duo T6600 2.20 GHz processor and Hyundai DDR3-1066 4096 MB RAM memory.

[Xycaleth]

That's a pretty big performance hit for a small handful of lights.

[Archangel35757]

That's a pretty big performance hit for a small handful of lights.

Well, I look forward to your experiment results.

[skew]

(Excuse the giant images!)

 

SSAO seems to have an odd screen door effect, almost as if the direction vectors around each normal were following a strong pattern rather than being pseudo-random.

 

Below is a screenshot of the latest rend2 branch from yesterday.

 

 

When I visualized the random function from the ssao fragment shader( using the fragment coordinates in screen space as the seed just as rend2 at runtime), there is a clear non-randomness to it, similar to the vertical striations from the screenshot.

 

 

I tried increasing the random vectors per fragment from 3 to 9 to see if it could smoothen out the pattern but it didn't help as much as I wanted.

 

 

Ultimately I went back to the source referenced by the shader to see if it was an implementation issue. Looks like the random function was done per the source originally but then changed to what is now.  

// Input: It uses texture coords as the random number seed.
// Output: Random number: [0,1), that is between 0.0 and 0.999999... inclusive.
// Author: Michael Pohoreski
// Copyright: Copyleft 2012 :-)
// Source: http://stackoverflow.com/questions/5149544/can-i-generate-a-random-number-inside-a-pixel-shader

float random( const vec2 p )
{
  // We need irrationals for pseudo randomness.
  // Most (all?) known transcendental numbers will (generally) work.
  const vec2 r = vec2(
    23.1406926327792690,  // e^pi (Gelfond's constant)
     2.6651441426902251); // 2^sqrt(2) (Gelfond-Schneider constant)
  //return fract( cos( mod( 123456789., 1e-7 + 256. * dot(p,r) ) ) );
  return mod( 123456789., 1e-7 + 256. * dot(p,r) );   // adnan - this gives a strange screendoor effect because the random numbers have vertical banding
}

Here is what it looks like if I change it back to the original method ( fract( cos( mod( 123456789., 1e-7 + 256. * dot(p,r) ) ) ) ) and with 9 vectors per fragment.  Looks much better.

 

 

This method is obviously more compute intensive only because I've got it doing the 9 vectors per fragment, but seems to work decently on my machine.

 

I'm going to look at doing what Nvidia mention in some of their papers, which was to interleave the selection of vectors from a larger predefined Poisson distribution to get something closer to random, by using the same random number generator to pick vector indices from the set of 9 predefined ones and see if that improves the screendoor effect even further.  Others also did a blur to the resulting values to get it to look smoother, so may explore that too.

 

If it ends up working out, I'll update it in my fork of rend2 and will probably post a pull request!