[Fox]

That's an interesting effect.

But I always felt that some game sprites and HUD sprites shouldn't be affected by Polymer lights, and these negative lights only reinforces it.

[Micky C]

I agree, it's definitely interesting. I look forward to testing it out some time and seeing what juicy goodness is possible.

[Diaz]

Very interesting Plagman, the negative lights indeed seem to be a great shading tool, I'll make sure to get some good use out of them. And thanks for the shadow-less spotlights! As you mentioned in the changelog, if we had a usecase where we needed no shadows but actual texture projections (if that's what lightmaps means) we should let you know... well, I have to say that's exactly the primary use I was going to give them! I'm using spotlights with projections to simulate water caustics, and those are the ones that should not cast shadows; but they do need to project a texture.

[Mark]

It would be cool to have that negative light attached to an enemy so darkness surrounds him wherever he goes. And it would drain health just being near him. A soul sucker.

[Plagman]

Fox, on 20 October 2012 - 10:03 PM, said:

That's an interesting effect.

But I always felt that some game sprites and HUD sprites shouldn't be affected by Polymer lights, and these negative lights only reinforces it.

Particle kind of sprites, sure; most of them should be fullbright no matter what, I agree with that. Why HUD models though? They looked very off before while they weren't affected by surrounding lights and pretty much everyone was complaining about that.

[Plagman]

Diaz, on 21 October 2012 - 05:03 AM, said:

Very interesting Plagman, the negative lights indeed seem to be a great shading tool, I'll make sure to get some good use out of them. And thanks for the shadow-less spotlights! As you mentioned in the changelog, if we had a usecase where we needed no shadows but actual texture projections (if that's what lightmaps means) we should let you know... well, I have to say that's exactly the primary use I was going to give them! I'm using spotlights with projections to simulate water caustics, and those are the ones that should not cast shadows; but they do need to project a texture.

Yeah, OK; I'll fix it then.

[Fox]

Plagman, on 21 October 2012 - 08:40 AM, said:

Fox, on 20 October 2012 - 10:03 PM, said:

That's an interesting effect.

But I always felt that some game sprites and HUD sprites shouldn't be affected by Polymer lights, and these negative lights only reinforces it.

Particle kind of sprites, sure; most of them should be fullbright no matter what, I agree with that. Why HUD models though? They looked very off before while they weren't affected by surrounding lights and pretty much everyone was complaining about that.

I meant just some HUD sprites, specifically muzzle flashes and shrinker crystal.

I suppose some sprites shouldn't suffer from both "positive" or "negative" lights. Perhaps just checking if the sprites is affected by the sector shade could work out. On top of that sprites shouldn't be affected by their own light source.

[Diaz]

Thanks Plagman!

BTW, I had to add fixes to some light effects on my mod that relied on changing a special sprite to a SECTOREFFECTOR in CON code; flickering lights in DukePlus use the same kind of code, namely:

....


        espawn SMALLSMOKE

        setactor[RETURN].lotag 49
        setactor[RETURN].hitag LE_RADIUS
        setactor[RETURN].xvel VR
        setactor[RETURN].yvel VG
        setactor[RETURN].zvel VB

        ifvare KILLINDEX 0 setvarvar LE_ID1 RETURN
        else ifvare KILLINDEX 1 setvarvar LE_ID2 RETURN

        setactor[RETURN].picnum SECTOREFFECTOR
        setactor[RETURN].cstat 32768
        changespritestat RETURN 3
.....

As you can see I had to add a line to manually set the cstat of the SECTOREFFECTOR to 32768, otherwise the light would be a negative light by defalult. I don't know if it's been broken in Duke Plus too, probably so, as this code was based off it.

[Plagman]

That's because SMALLSMOKE has cstat 128 by default, I think.

[Plagman]

Diaz, the emitshadow flag shouldn't affect lightmaps anymore; I also fixed a bug where it could make some smotlights disappear under obscure circumstances.

[Diaz]

Works like a charm. Thanks A LOT. This will improve performance on my maps by a huge deal

[PokeThePower]

Plagman, on 20 October 2012 - 09:42 PM, said:

I also implemented support for negative lights; they remove light from the scene instead of contributing more to it. To activate it, just set the half-submerged bit on any light SE ('C' in mapster) and it will become negative. The color components work as usual, except they're substracted from the scene.

Awesome... thanks! Being able to do it per color component is extra bonus!

[Micky C]

Marked, on 21 October 2012 - 05:03 AM, said:

It would be cool to have that negative light attached to an enemy so darkness surrounds him wherever he goes. And it would drain health just being near him. A soul sucker.

That would indeed be very cool!

I think my first use for it will be a pit with a black light in it to make the hole fade to black over a smooth transition, as opposed to just black fog which can move around a lot depending on where you look. I haven't tried it out yet, but it should work fairly well. I'm a bit busy to sink my teeth into it deeply at the moment, but I'm sure Diaz will discover some pretty amazing things to do with it.

Also a warning to all polymer mappers: there's a good chance that some extra features will be added to lights at some point in the future, and that they might use extra bits such as flipping or wall alignment. If you use any of these and then these features are added, they will then occur in your old maps with undesirable consequences.

Basically, avoid using extra bits at all costs.

[Hendricks266]

Micky, there was debate on IRC whether Plagman should use cstat bits like 8192, but the consensus was that mappers would prefer bits being togglable via keys Mapster32 provides, like '1' and 'C' which Plagman used. The other option would be to use out of range bits to avoid conflicts but require mappers to use the 2D mode sprite properties editor to add the bits, or else make a small M32script to make their own hotkey.

Fox, on 20 October 2012 - 10:03 PM, said:

But I always felt that some game sprites and HUD sprites shouldn't be affected by Polymer lights, and these negative lights only reinforces it.

Can't that be done by setting specularity to 0 or something along those lines in the defs?

Also, do glow maps get affected? If they do, they should not.

[Micky C]

I agree, it makes things much easier. I just said that in case some people made their SEs wall aligned to make it easier to see which way the spot light is pointing or something.

[Micky C]

Wow.

Check out how vibrant this red is on the right using negative lights, as opposed to a normal red light on the left.


This green is amazing, normally you'd have to make a texture like this pitch black to get any kind of green out of it.


And it's a fantastic transition between black fog and other fog (and most likely other fogs too). Using TROR, we now have fog depth

[Fox]

Hendricks266, on 21 October 2012 - 04:56 PM, said:

Can't that be done by setting specularity to 0 or something along those lines in the defs?

For HRP perhaps that could work, but I am thinking of how it display regular sprites.

[Hendricks266]

Maybe it's because I'm up past my bedtime, but does that even happen? Could you show an example?

[Jblade]

I definitely disagree, they look far far better being affected by the lights than they ever did remaining flat-shaded. It's a huge positive reason to use 3D models rather than 2D sprites.

EDIT: whoops didn't see there was a whole page of discussion past the talk about lights affecting models

[Fox]

Hendricks266, on 21 October 2012 - 11:53 PM, said:

Maybe it's because I'm up past my bedtime, but does that even happen? Could you show an example?

Well, these are examples of what should not happen:




===//===//===


I am experiencing a bug with ifvar commands.

Basically, I am trying to add some code in EVENT_DISPLAYROOMS, but for some reason this

  ifvarand sector[SECT].ceilingstat 1
    do something

is not working, and instead I must use this

  getsector[SECT].ceilingstat TEMP
  ifvarand TEMP 1
    do something

I remember that for quite a while I avoided using "sector[id].member" as a variable, and now I know why.

[Hendricks266]

Fox, on 22 October 2012 - 12:33 AM, said:

Well, these are examples of what should not happen:

Ah, I understand now and I agree completely. Since the SHRINKSPARK and GROWSPARK lights are hardcoded, they should be modified so that they do not apply to the sprite casting them. Other hardcoded light sources, such as RPG, are debatable. Such functionality (cast a light but don't also be affected) should be expanded to CON usability, such as a new cstat or htflags bit that ignores Polymer lights.

Your other problem is a job for TX.

[Fox]

I believe it may not even be debatable, and it should apply to all hard-coded spritenoshade sprites.

[Tea Monster]

Just out of curiosity, is there any kind of roadmap for Polymer? New shader types, optimisation etc.?

[Fox]

Is it possible to add a resize function to tilefromtexture? It would use nearest filter, of course.

Technically I could use a resized image instead, but that would affect the linear filter in OpenGL mode. I could define a highres image with normal size, but an highres textures behaves differently...

[Hendricks266]

I think what you are looking for is along the lines of assigning a non-square pixel ratio to your image, though you also want a specific size. Correct?

[Fox]

Not necessarily. I want something as simple as what you can do by resizing an image, but without the need of a resized image.

[Plagman]

I think just resize your images... free tools like XnView, IrfanView, GIMP all have batch resize capabilities if you need to resize lots of them in one go.

[Micky C]

So any word on making the polymer draw distance adjustable in con? I'm making a lot of progress on my Serious Sam WGR2 episode and the draw distance pretty much makes it unplayable as it's a huge distraction, and you can't admire the large scale scenery to its fullest.

[Plagman]

I don't think it'll ever be adjustable in CON because that doesn't make much sense, but it's a bug that it's currently fixed the way it is:

http://sourceforge.n...duke32/bugs/26/

It was just a quick and dirty way of getting it up and running, but it needs to adjust dynamically depending on the scene contents and above a threshold, toggle into a slightly more expensive mode where you get increased depth precision. I'm unsure what you can do before that work is done, though; if I just naively bump the far clip plane distance you'll start to get more depth aliasing elsewhere in the scene. Maybe add fog as a workaround until that's fixed? Sorry I don't have a better solution and for generally dropping the ball on Polymer work.

[Fox]

Plagman, on 26 October 2012 - 03:00 PM, said:

I think just resize your images... free tools like XnView, IrfanView, GIMP all have batch resize capabilities if you need to resize lots of them in one go.

I could do that. But that would have side-effects, and more important I don't want to. The same way I could batch recolor images, but that doesn't means tints or palmaps are not necessary, right?

The problem here is that there are things you can't do depending on the technical scale (art file data) of the image.