[Helixhorned]

James, on 15 October 2012 - 04:12 AM, said:

That pixel detection thingy Helix added is fucking great! For those who don't check the synthesis/changelog, it basically allows you to define wall-aligned sprites and set them to have a per-pixel detection ability on them for hitscan, which means that they allow shots to travel through empty areas and stop bullets if they hit a solid part of the texture. It works great, thanks for adding it

Cool you're finding it useful! It was requested by M210 for his Blood mod, but currently it doesn't help his case as it only handles wall-aligned sprites. For a quick demo of what it's about, add

texhitscanrange 0 32768

to your duke3d.def and try shooting the fan in E1L1. (Caveat: won't work on the fences, since all MASKWALL* sprites clear the hitscan-sensitivity bit on spawn.)

[Jblade]

Helixhorned, on 15 October 2012 - 11:26 AM, said:

(Caveat: won't work on the fences, since all MASKWALL* sprites clear the hitscan-sensitivity bit on spawn.)

Heh, I had always wondered why that chainlink fence sprite at 913 never seemed to keep it's tag, now I know It works great with some new chainlink fence sprites I added in the AMC TC since they were coded to spawn sparks and sounds and stuff, it works really well with this new feature now.

[Kyanos]

Is there any way to increase the drawing radius of the renderer?
If not, I would like to request that the drawing radius be made adjustable some how. Either via con or preferably a way in Mapster to adjust the drawing distance for new user maps.

[Mblackwell]

Are you talking about visibility? In USER.CON change DEFAULTVISIBILITY.

http://wiki.eduke32....wiki/Visibility

[Micky C]

He's referring to the draw distance in polymer. It's a great way to boost the frame rate, but can be incredibly obvious and ugly in open maps where half the map is missing. Specifically there are a set of maps I'm working on for WGRealms 2 that require polymer and a draw distance of maybe 3 times as far as it is currently, so some way to change the distance in con would be ideal and welcome.

[Fox]

I have some ideas for effects that could be added in the future. In both cases it would especially usefull in making the transition from water to the skybox

The first would be to have a "transparent fog" effect. Here is a mock-up:



The second would be to render the sector floor ad infinitum in a wall. In other words, to stretch the floor texture to the horizon while that area doesn't really exists. I suppose the renderer can make it in a way that can save more CPU than making a gigantic sector.

[Mblackwell]

Micky C, on 16 October 2012 - 04:51 PM, said:

He's referring to the draw distance in polymer. It's a great way to boost the frame rate, but can be incredibly obvious and ugly in open maps where half the map is missing. Specifically there are a set of maps I'm working on for WGRealms 2 that require polymer and a draw distance of maybe 3 times as far as it is currently, so some way to change the distance in con would be ideal and welcome.

Ah, I see what you're/he's saying now.

[Plagman]

I finally hooked up the bit to prevent spotlights from casting shadows; it's linked to the one-way bit on SEs, so pressing '1' on a spotlight SE should remove its shadow.

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.

I can think of several uses; a fully white negative light would just create darkness and could be used as a shading tool that's a little smoother than sector shading.



If you only keep one component (eg. a cyan negative light would remove green and blue, leaving only red), it can create a fluorescent kind of effect:




Or just for 'unreal' effects, evil-looking auras, etc:



Thanks Charlie for submitting the idea.

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