Jump to content

Rend2 - A Modern Renderer


Xycaleth

Recommended Posts

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.

DT85 and Archangel35757 like this
Link to comment

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.

Link to comment
Guest KENNITHH

That looks a lot like that benchmark thingy of Frostbite Szico :D

 

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

Link to comment

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

Archangel35757 likes this
Link to comment

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

 

 

kDNy08h.jpg

dp1PB9T.jpg

pOBOdOu.jpg

CQ9o3ox.jpg

 

 

Link to comment

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?

Link to comment

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

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

Link to comment

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

 

 

kDNy08h.jpg

dp1PB9T.jpg

pOBOdOu.jpg

CQ9o3ox.jpg

 

 

Dont know how I missed your post. That looks great, Szico! :D 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 :)
Link to comment

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

Dont know how I missed your post. That looks great, Szico! :D 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
oK3SyNLm.jpgxNYqp90m.jpg
1pkfcx5m.jpgaVHk52Sm.jpg
ic2gR1Gm.jpgKsJ6Ny5m.jpg

Circa, Mark Lubbers, Smoo and 4 others like this
Link to comment

@@Xycaleth - did you download that PDF?

Nope! It wasn't there when I quoted you :P 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.

 

oK3SyNLm.jpgxNYqp90m.jpg

1pkfcx5m.jpgaVHk52Sm.jpg

ic2gR1Gm.jpgKsJ6Ny5m.jpg

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

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

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

 

 

kDNy08h.jpg

dp1PB9T.jpg

pOBOdOu.jpg

CQ9o3ox.jpg

 

 

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

Link to comment

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.

Link to comment

Nope! It wasn't there when I quoted you :P 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.

Link to comment

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

 

fnx9Xc3.jpg

 

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.

 

nWoyIQ2.png

 

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.

 

q4R1Hgz.jpg

 

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.

 

uSf0iZH.jpg

 

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!

Archangel35757 likes this
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...