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.

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

Your .menu files and source code can be licensed differently though. If you use one license for part of your mod, it doesn't mean the entirety of your mod has to use the same license.

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

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.

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

You can only have up to 1000 verts on a single mesh in your model. You can split up your model into multiple meshes, but the fact you have 5500 verts on a saber is kind of suspicious. You should reduce the amount of detail to put it into perspective, the player models in JKA only have about 3000 verts each (for the entire model).

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.

There used to be a problem where all shadows looked grainy but I fixed that. There's an going issue where the edges of the shadows look grainy which I still need to fix but it's generally not noticeable.

Could you post a screenshot? I haven't made changes to rend2 for a while. Where did you download the latest rend2 from?

I lowered the lighting levels to match more closely what it looks like with q3map2 and the graininess will go away as you increase the quality. I didn't have the time to wait for it to remove all the graininess so I settled with what I had Here's another render using @@Circa's map:

I don't know why it's backwards (the door should be on the left) I'll look at fixing that later.

 

Also...the shadows won't be as sharp when they're actually turned into lightmaps. These are literally renders of the map from my program.

I've changed the rendering algorithm I use because I couldn't get my head around the previous one. This one's much simpler, and much easier to tune for quality.

 

 

A duel sized map would be good, or maybe a connected set of duel sized rooms, with some "interesting" lighting and colours? By interesting I mean there should be some structures to cast shadows (e.g light behind a set of jail-like bars), a wall with vibrant colours so I can test colour bleeding. I think best thing to do would be to create the map as if you were going to use shader lights but put point lights in lieu. That way I can use the same map when I add support for shader lights.

Yes but only used shader lighting

I meant I can make a small one quickly with entity lighting for a testbed

Ah! If you wouldn't mind that would be great, thanks

On the WIP shelf along with moonbase I needed a model (statue) to continue with the bioshock one and couldnt find an appropriate one alas

Your Bioshock map was completely indoors right?

What changes to the code did you make? Can you post the code that you've changed?

It was never my intention for rend2 to make JKA look as good as X or Y. It just provides the ability for artists to create something closer to what you can get in these games 90% of what makes a game look good is the art, and i can definitely say I'm not an artist!

For the moment, yeah. Now I think about it, not many maps will have only light entities, but on the off chance, I'm still looking

 

I have my WIP Ilum map that's all indoor and very small still. And extremely dark. If that's of interest.

I'd be interested in that. Could you send the .map over? I don't need the textures for now, if you have any custom ones.

Does anyone have any indoor maps (strictly no skyboxes) that I could use for testing purposes?

3. Use version control for your code changes, and back it up on a remote server (e.g. GitHub).

Now with less grey

Things are looking pretty grey now, but it's getting closer to what I'm aiming for (code-wise):

Here's a fun fact: the majority of the time generating this image is proportional to the number of pixels in the image. For 800x600, that's 480000 pixels. If we say a large BSP map will have maybe 100 lightmaps (this might be an over-estimate), which are 128x128 (because that's how big they are), then that's 1638400 pixels, i.e. roughly 3-4x more pixels. At the moment, a high quality render would probably take me around 30 minutes for 480000 pixels, so for a very large map, that would be less than 2 hours. As far as I know, Q3Map2 can take over a day to run the lighting phase for a large map.

 

These are all very rough numbers, but I'm hoping they're approximately reflect the kind of speed I'll be able to get - and I haven't even made this multithreaded yet. And it's not even making use of GPUs.

I agree with boothand. People don't mind if you compliment them. They only mind if you push negativity towards them.

rend2 doesn't work for SP yet.

Working or release-ready? There's a working version, but I wouldn't consider it ready for release.