Xycaleth

Hey skew. It's great to see you're trying out rend2 I don't think you'll get the results you want with a plain Gaussian blur. You will end up blurring across edges which ruins the effect. What you want is a depth-aware Gaussian blur which only takes samples across areas of continuity (i.e. not across edges). If have to say though, it's really difficult to notice the SSAO - I feel like something is wrong with it.

This seems like a bad idea to me. What problem does it solve? You will still need CI. How else can you tell if the code compiles and that there are no missing files? You obviously don't want to find out when the players are starting to compile the code on their machines.Why waste the player's time compiling code, then they could download a precompiled version and run it?How does the player being able to compile the code, enable these features? It would be possible to do if the player downloaded a .exeSame as above - they can download the latest version manually, or through some automated check for new buildsYou then have the issue of people using the master branch which is, for the most part, unstable. None of our weekly builds are stable; they just happen to be built on a Monday to give people something to use. We don't have a stable branch currently. On top of that, the player now has to download an additional few hundreds of MBs of programs to compile the code. If the problem you're trying to solve here is to keep everyone up to date, then have a launcher which downloads precompiled builds and keeps the user up to date.

JA Enhanced is also the name of an existing mod

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

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.

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

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

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

That could be the problem, yeah. @@SomaZ, do you have r_genNormalMaps set to 1? Does it still look grainy when you disable it? 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.

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

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