[Danukem]

In DukePlus I am disabling Polymer lights on all switches, and here is why:





1. They look fine without big ass polymer lights coming out of them. That's what glowmaps are for, people!
2. Look at the frame rate difference in the two shots. In the shot without lights, it is 141. With lights, frame rate plummets to 40. Jesus fucking Christ.
3. Making light come out of switches by default often looks like crap, and it might ruin what the level designer is going for.

There might be other sprites that should have lights disabled. If anyone can think of them, I'll do it.

[Plagman]

Yeah, though in this case since the switches are the only light source your second shot would be identical if taken from Polymost. I think you're right that the current state of hardcoded lights looks way overdone in certain cases (large concentrations of alien canisters is the other case I'm thinking of), but I'm not sure these should be totally removed. How does it look if you just reduce the radius by half or so?

[Danukem]

Plagman, on Jan 10 2011, 02:09 PM, said:

How does it look if you just reduce the radius by half or so?

It's not so easy to find out. What I'm doing there is setting the flag that disables the hardcoded lights using CON code. I would need to modify the source code to control the radius. I will predict that it would look better but that framerate would be about the same as having the larger lights. Since imo it looks fine with no light, I'll keep it that way.

Consider also that the hardcoded lights can play havok with level design. In that shot, for example, a spotlight coming from behind the player might look great, casting the player's shadow on the door. But the effect will look quite different when there are already so many lights on the surfaces.

[bullerbullerseven]

The problem seems to be that the lights they make are far too big.

If it's too much to make the radius smaller then i think you should simply turn the polymer lights off. I prefer that instead of the big lights that could blind a man in real life.
Just take care that you don't make it a habit.

[Helixhorned]

They should definitely be controllable by CON. I've grown accustomed to that look in the first shot though .

[Danukem]

Today I have been experimenting with a CON controlled draw distance feature for sprites/models in Polymer. The goal is to boost frame rate by making things invisible. The distance is dependent on the frame rate (higher frame rate = larger draw distance) and priority. I'm getting some pretty decent results now, but it occurs to me that Polymer might benefit from having its own built in draw distance that could be controlled by cvars or CON or both.

[Scott_AW]

DeeperThought, on Jan 10 2011, 04:40 PM, said:

Today I have been experimenting with a CON controlled draw distance feature for sprites/models in Polymer. The goal is to boost frame rate by making things invisible. The distance is dependent on the frame rate (higher frame rate = larger draw distance) and priority. I'm getting some pretty decent results now, but it occurs to me that Polymer might benefit from having its own built in draw distance that could be controlled by cvars or CON or both.

That actually sounds like a pretty good idea, I put that into my water particle actor since having a few in one map drug things down on classic render, and thats not a good thing.

I think the lights are excessive in size for LEDs, although having no light seems to be too plain, but speed wise it's probably a good thing not to have so much lighting. Light is the real killer.

[High Treason]

I have an idea, but I don't know how possible it is or how well it would work...

Perhaps code could be added to switches - either in the source code or con - to detect if the switch is near another switch and how many other switches are there, if it is less than a certain distance and there are more than so many switches (more than 2 in the same sector?) it will not cast light.

Just a thought.

Edit: And yeah, the light is excessive, I know superbright LEDs are always improving, but they aren't that good yet.

[Sobek]

Hey DT, I have to say I completely agree with what you're saying... Ignoring the performance aspect (as we can probably expect some improvements there with time), the visual side of things is a bit too excessive, and it's not just the switches. User control is definitely the way to go as I've found most hardcoded light sources either clash with intended design styles, or drag performance down.

Also, did you mean for this thread to be open to suggestions for Polymer related issues? Because I can always bitch on about the transparency problems on sprite / texture borders

[Scott_AW]

Sobek, on Jan 10 2011, 09:20 PM, said:

Hey DT, I have to say I completely agree with what you're saying... Ignoring the performance aspect (as we can probably expect some improvements there with time), the visual side of things is a bit too excessive, and it's not just the switches. User control is definitely the way to go as I've found most hardcoded light sources either clash with intended design styles, or drag performance down.

Also, did you mean for this thread to be open to suggestions for Polymer related issues? Because I can always bitch on about the transparency problems on sprite / texture borders

Could always treat lights as a separate object or even a special tag. Hardcoded stuff is already a little vexing.

[BrOiler1985]

Well, I personally think that the first shot looks really cool with those lights. But I agree that the lights are overdone. Con-Control of those lights would be really, really cool. Or maybe an extra value or something, to determine if the switch casts light, or not.

[Danukem]

Sobek, on Jan 10 2011, 09:20 PM, said:

Hey DT, I have to say I completely agree with what you're saying... Ignoring the performance aspect (as we can probably expect some improvements there with time), the visual side of things is a bit too excessive, and it's not just the switches. User control is definitely the way to go as I've found most hardcoded light sources either clash with intended design styles, or drag performance down.

Also, did you mean for this thread to be open to suggestions for Polymer related issues? Because I can always bitch on about the transparency problems on sprite / texture borders

The purpose of the thread was to bitch about Polymer related issues. Specifically, I wanted to start with ones that can easily be fixed. I guess I could have posted in the papercuts thread, but I felt like starting a new thread.

For me, the performance aspect is the number one reason to not have switches give off light by default, and the level design issue is second (but still important). It is good that they can be turned off by setting a flag in CON, but having full control of them would be better obviously.

[Tea Monster]

Got to agree that the second shot looks much more realistic. To those who think that the second one looks bare, maybe add a small light over the armory sign. But all those hard-coded glowing switch lights just look strange.

We may have to investigate the levels and see where else this sort of thing occurs. It could be that we can get a few extra fps with exchanging 'switch lights' for one or two carefully placed se lights.

[Jan Satcitananda]

Sobek, on Jan 11 2011, 08:20 AM, said:

User control is definitely the way to go as I've found most hardcoded light sources either clash with intended design styles, or drag performance down.

Yup, sometime when I tried to play Last Pissed Time in Polymer, I had a funny glitch due to the way its hard-coded lights work:

[Stabs]

personally the atomic health is the biggest offender in how it breaks gameplay and secret places, looks cool and all but maybe it should not be casting light untill the player can see it

[Fox]

Lights are surely a problem as they are now

1 - They are hard-coded. Nuff said.

2 - Objects are affect by their own lights (shots: how it is, how it should be)

3 - Lights close to each other cause an overpowered light effect (shot -> I) a light II) several lights in the polymer III) how lights should react placed close to each other)

[Danukem]

DanM, on Jan 11 2011, 03:33 AM, said:

personally the atomic health is the biggest offender in how it breaks gameplay and secret places, looks cool and all but maybe it should not be casting light untill the player can see it

Good point, so I'm adding this code to DP:

onevent EVENT_SPAWN
ifvare sector[THISACTOR].lotag 32767
ifvarn sprite[THISACTOR].statnum 4
{
	getactor[THISACTOR].htflags temp
	orvar temp 256
	setactor[THISACTOR].htflags temp
}
endevent

That means any sprite that starts in a secret area, unless it is a projectile, will make no hardcoded light. I also added a line to the atomichealth actor so that it does light up when you enter its sector.

Maybe there should be a sector hitag for killing hardcoded light? That way you could have a dark zone without the secret area message.

[Gambini]

For me it´s pretty stupid to even have to convince whoever added those hardcoded lights that they don´t fit. Hell, how in this world a one inch led can cast a huge light BACKWARDS!!!! I mean, those leds are aiming outside the wall but for some "magical" reason they cast a huge light towards the wall, where only crazy curved rays could reach! We´re witnessing a paranormal phenomenon!

[Danukem]

Gambini, on Jan 11 2011, 03:20 PM, said:

Hell, how in this world a one inch led can cast a huge light BACKWARDS!!!! I mean, those leds are aiming outside the wall but for some "magical" reason they cast a huge light towards the wall, where only crazy curved rays could reach! We´re witnessing a paranormal phenomenon!

That's one reason I think Polymer lights should only be used for larger light sources. Glowmaps are perfect for making tiny lights and don't hog resources.

[bullerbullerseven]

Yes the polymer lights are a bit overused. Switches aren't supposed to light up a whole room.

[MusicallyInspired]

I prefer the glowmaps as well. Although I'm undecided about the alien canisters. I like that they produce light and don't think that simple glowmaps suffice...but the framerate issue is tremendous.

[Plagman]

DeeperThought, on Jan 11 2011, 03:24 PM, said:

That's one reason I think Polymer lights should only be used for larger light sources. Glowmaps are perfect for making tiny lights and don't hog resources.

I wouldn't say they're perfect by any stretch of the imagination. Sure, they look better than nothing at all. The difference of quality between your two shots is tremendous, and you won't find a lot of people claiming that the first one looks worse (empirically, whether or not it suits Duke3D is off-topic here). Sure, it's overdone. From an artistic standpoint we can debate whether we need to reduce the light radius, push it further into the switch so that it doesn't light itself as much. We can also say that light shining from secret areas you haven't discovered is a problem and try to fix that bug. But let's not claim outright that the latter looks better, because that's just not true.

Also (to echo the end of your sentence and what MusicallyInspired said), I'm of the opinion that performance issues shouldn't impair artistic direction; people not getting the performance they're after are free to tweak their settings to remove these low-priority lights using r_pr_maxlightpriority. I acknowledge performance isn't where it should be and I have full intent to address that (as always, it's only a question of time at this point; it can and will be done), but we need to stay focused on shooting for the look we want, not compromise based on temporary performance concerns.

[Scott_AW]

Well you have two different styles actually, one is more artistic, showy, the other is subtle and a little more realistic.

However you also have to take in that Duke3d is a fast paced action game, so speed should take precedent. Although I know that more modern computers, or better built ones, have less or no problems.

But the best solution would not to have it hard coded, or even have it trigger by a simple flag that can reside in the config, be triggerable, or even disabled if the mod doesn't need it.

[bullerbullerseven]

Ok now we all agree that the lights from these switches are far too shining now stop talking and go edit it!! jk ofcourse xD
But i am glad that you guys are worked on it, and that you want to work on it.

[Tea Monster]

I think the main reason that everyone prefers the first one is that it shows off the bump and spec maps. If you put one or two small lights above the scene, you would get the 'pop' of the spec and you would see the normal maps in use and you would still have a lot more resources to keep your frame rate up.

I really don't think the first shot looks 'better'. I think whats going to have to happen is that if we knock the hard-coded lights on the head (which I think looks far more realistic in most instances), then we'll have to add a few SE lights here and there to make up for the glow. As if we don't have any lights in a scene, nobody can see any of the Polymer goodness actually at work. If we used the glowmaps instead of the hard coded, we could better distribute the lights in a level and get a better overall lighting effect.

[MusicallyInspired]

If the excuse is to use polymer lights on switches because it makes the surrounding textures look more realistic, I'd have to disagree with that. The lights on those switches wouldn't be near bright enough in real life to cast light on anything. Like someone said above, they're more like LEDs than light bulbs and regardless of whether or not it makes the surrounding textures look good, that shouldn't be an excuse to use them. The surrounding textures should already look good.

In fact, that's my problem with Polymer right now. When there's no lights everything looks completely flat. That's not entirely realistic and I don't think other modern engines behave that way either. Of course, Polymer is limited in what it can do (for now) and can't really be compared to other game engines but this is the single most glaring Polymer issue that bothers me. I find myself hunting for light sources just to enjoy Polymer's capabilities when really things shouldn't seem so flat anyway.

EDIT: Sort of ninja'd.

[Plagman]

MusicallyInspired, on Jan 12 2011, 06:23 AM, said:

In fact, that's my problem with Polymer right now. When there's no lights everything looks completely flat. That's not entirely realistic and I don't think other modern engines behave that way either.

They do, it's just that they have static light sources built-in the map. For example, a map in HL2 is pitch black until you start lighting it up. The problem here is that we've got the modern lighting layer of top of the classic Duke3D shade system, which can only be used as diffuse lighting and won't show off any of these features because of that. The vision Parkar and I had was for Polymer to just ignore the shade and start from darkness, and that's what the E1L1 maphacks were aiming for.

[Danukem]

I guess one cheap solution would be to make the player always give off some light. Then you always be able to see the bump maps etc. It would probably work best if it was a point light with a fairly long range, yet was not bright. A dim light that had the same intensity on surfaces regardless of their distance from it (as long as they were in its maximum range). Perhaps the intensity of the light could be tied to the ambient light level slider.

[Plagman]

Having the light originate from the viewpoint nullifies most of the effects, though.

[Stabs]

couldnt you just offset the light from the player cause that idea seems great