[icecoldduke]

I did some quick lighting in E1L1 to make another video to show the deferred lighting. Light color and range are hooked up now.

[Spiker]

Stop teasing me! just stop!

[MusicallyInspired]

Lookin good.

[HiPolyBash]

Oh baby

[Micky C]

How does that scene compare to polymer in terms of framerate?

[icecoldduke]

Micky C, on 12 June 2016 - 04:52 PM, said:

How does that scene compare to polymer in terms of framerate?

Right now I can't get lights to show up in regular Polymer, but in PolymerNG in my "ngzoo" as I'm calling my E1L1 modification; I have 11 lights(I have no light culling yet so they all render at once), and it hovers around 6-7ms(~130fps), this is too slow. The amount of lights isn't the current issue right now, its I'm just doing stupid shit right now(like using a RGBA 32bit float for screen vertex positions, when I could be using the depth buffer to reconstruct the vertex position), once I get this optimized it should be under 2ms if that.

When I did a side by side I realized my fov is too low compared to Polymer, so I increased the FOV.




The bottom line is the lighting code is too slow, I'm going to get it down using depth recontruction, tile based lighting, etc etc. I should be able to support 128 lights(non normal mapping, non shadowed) in view at once and have the lighting hover around 6ms on a NVIDIA 570 using LIGHT INDEXED DEFERRED RENDERING

A question for you guys, I realized when I increased the FOV I got more sector popping bullshit happening, I think it might be because the FOV with the Polymost occlusion system differs from the FOV I'm rendering at. Does anyone know how to increase the FOV in Polymost?

EDIT:
I'll upload a video later on, image upload sites are down resing the images :/.

[Mark]

I can hardly wait to try our new E1L1 remake that is absolutely loaded with lights and models. Disclaimer: We are not responsible for overheated video cards.

[TON]

http://wiki.eduke32.com/wiki/Setaspect

[icecoldduke]

TON, on 13 June 2016 - 09:58 AM, said:

http://wiki.eduke32.com/wiki/Setaspect

There is a bug in the perspective calculation that I discovered last night, I plan on fixing it this weekend.

[Hendricks266]

You should implement rotatesprite's widescreen awareness so your screenshots don't have a stretched HUD.

[Micky C]

A thought; polymost kind of stretches the screen when you look up and down to the limit. Would this have an effect on things?

[icecoldduke]

Micky C, on 14 June 2016 - 02:39 AM, said:

A thought; polymost kind of stretches the screen when you look up and down to the limit. Would this have an effect on things?

That might cause some of the occlusion errors(the flickering geo), but nothing else. I found a bug were the screen resolution that was going into some of the perspective code was incorrect. I've fixed that. Anyway I spent an hour or two yesterday working on point light shadows, and here is the results so far.

[Micky C]

Is it just me or is the light lighting up the pistol?

[icecoldduke]

Micky C, on 16 June 2016 - 02:44 AM, said:

Is it just me or is the light lighting up the pistol?

There is no lighting on the pistol sprite .

[TerminX]

I'm guessing your rotatesprite implementation doesn't handle shade yet.

[icecoldduke]

TerminX, on 16 June 2016 - 09:58 AM, said:

I'm guessing your rotatesprite implementation doesn't handle shade yet.

It does, I just have that entire system disabled at the moment. I have it temporally disabled while I flush out lighting in my E1L1 "NG" map. I think what I might do is have a mode that can be enabled by a maphack, that disables sector shading/palettes, and only uses NG lighting. Then by default map developers will be able to mix and match but I'm not sure how good that will end up looking. Obviously if the map doesn't support NG lighting, it will use sector shading/palettes as you would expect.

[Danukem]

icecoldduke, on 16 June 2016 - 10:12 AM, said:

Then by default map developers will be able to mix and match but I'm not sure how good that will end up looking.

That's the way it works in regular polymer and the results really depend on the map. If the map has a lot of sectors specifically made to be shadows, then it can look weird. But having regular shading enabled is useful, even if designing a new map for polymer/polymerNG because shading is a low-resource way to set ambient light levels. E.g. in an underground tunnel you set shade very dark, above ground much lighter, and right away there is some basic ambient light without using dynamic lights.

[icecoldduke]

Trooper Dan, on 16 June 2016 - 12:44 PM, said:

That's the way it works in regular polymer and the results really depend on the map. If the map has a lot of sectors specifically made to be shadows, then it can look weird. But having regular shading enabled is useful, even if designing a new map for polymer/polymerNG because shading is a low-resource way to set ambient light levels. E.g. in an underground tunnel you set shade very dark, above ground much lighter, and right away there is some basic ambient light without using dynamic lights.

Sector lighting could also be used for faking shadows in theory. There are good reasons to keep it, so relax you will be able to use sector lighting and palettes with NG lighting, just for the time being so I can work I have temporally disabled the feature.

[icecoldduke]

Point light shadows are completely working, need to add culling and other things, but the math is complete. Here is a point light in E1L1.

[MusicallyInspired]

I thought only spotlights cast shadows. They both do now? That's pretty cool.

[icecoldduke]

MusicallyInspired, on 17 June 2016 - 08:56 AM, said:

I thought only spotlights cast shadows. They both do now? That's pretty cool.

In regular Polymer, only spot lights casted shadows. In PolymerNG there are three light types, point, spot and sky. All three cast shadows. Right now I only have code in for point lights, and that's what I'm showing off above. Eventually I would also like to get area lights in as well.

[Mark]

Is there going to be a flag to toggle if someone doesn't want a point light to cast shadows? And I hope the light isn't leaking through walls like we have now. The shadow is a good thing but there may be some instances where its not wanted.

For instance, if there is a point light in the center of the room for illumination I may not like all the shadows dancing on the floor and walls during a crowded fight

[icecoldduke]

Mark., on 17 June 2016 - 09:38 AM, said:

Is there going to be a flag to toggle if someone doesn't want a point light to cast shadows? And I hope the light isn't leaking through walls like we have now. The shadow is a good thing but there may be some instances where its not wanted.

For instance, if there is a point light in the center of the room for illumination I may not like all the shadows dancing on the floor and walls during a crowded fight

Oh yes shadows are togglable(currently by setting the sector effector palette to 1). In fact I only want people to have at max 5-7 shadow casters in view at once. You guys will be able to have a lot of non shadowed lights visible at once, but only about 5-7 shadowed lights visible at one time, this is for performance reasons.

[Mark]

Not much more I can ask for. Cool.

[MusicallyInspired]

Do the different types of lights have different levels of shadow "softness?" Or better yet, can you set the "softness" as a modifier?

[Sanek]

I wonder if anyone ever tried to launch my limit-breaking map, Bridge Between Two Islands with Polymer. I guess the map stopped as soon as you get yourself on the top.

[icecoldduke]

MusicallyInspired, on 17 June 2016 - 11:55 AM, said:

Do the different types of lights have different levels of shadow "softness?" Or better yet, can you set the "softness" as a modifier?

I have not implemented soft shadows in the code yet. I might expose the softness value, but I do havesome fears with that. What is your use case?

Sanek, on 17 June 2016 - 12:58 PM, said:

I wonder if anyone ever tried to launch my limit-breaking map, Bridge Between Two Islands with Polymer. I guess the map stopped as soon as you get yourself on the top.

I haven't even heard of it, if you send it my way I'll look at it later on. Right now I'm focused on e1l1.

[MusicallyInspired]

icecoldduke, on 17 June 2016 - 01:10 PM, said:

I have not implemented soft shadows in the code yet. I might expose the softness value, but I do havesome fears with that. What is your use case?

Purely hypothetical. I'm just thinking of closer lights having harder shadow lines while farther away lights (sky lights, for example) would be softer. Unless this is calculated automatically? In Polymer they're just all hard lines and not soft at all, which is why I'm asking.

[icecoldduke]

MusicallyInspired, on 17 June 2016 - 02:05 PM, said:

Purely hypothetical. I'm just thinking of closer lights having harder shadow lines while farther away lights (sky lights, for example) would be softer. Unless this is calculated automatically? In Polymer they're just all hard lines and not soft at all, which is why I'm asking.

I think for now I'm going to keep the shadow softness level in the engine, we can re-eval at a later time based on your needs.

[MusicallyInspired]

Yeah, if it's going to be an automatic engine calculation then that's cool. I was going by the assumption that it wasn't until I thought about it some more...