OldUnreal (Engine)

Forgive me if this was posted before, or if it's already been considered, or whatever ,etc... I just wanted to get this out.

I was wondering, can we expand on STY_Modulated and add better support for subtractive colouring? And instead of being limited to purely additive lighting, can we also have subtractive lighting?

I'd like it if it were possible to fade colours on a STY_Modulated decal or actor, so that instead of blood and weapon marks vanishing instantly, they "corrode" into nothing.. I'm sure plenty of games do this, and hell, I think UT200x does it but at it's base, it appears to use alpha channel based decals, that don't appear to be subtractive like STY_Modulated is in Unreal currently.

It'd also be nice to beable to ScaleGlow\AmbientGlow STY_Modulated so that it's easier to create special darkening fade effects without having to supply 100 or so animation frames of the same texture with a different palette over and over, which bumps file size and looks ridiculous.

As for "subtractive lighting".. Basically I want lights that darken areas and actors, so I can have things like dark lights and other mysterious effects.. It's basically the opposite of what the lighting currently does in Unreal so far.. I also want, if subtractive lights are actually added, the volumetric lighting they produce to also be subtractive.

Another thing that'd be nice is sprite rotation, so that you can roll a sprite on it's axis to create more elaborate particle effect animations without, again, supplying a ton of animation frame textures, but instead of different palettes, it's different raster rotations.. And native support for DT_RopeSprite and DT_VerticleSprite so people don't have to use mesh hacks like .:..: did with DoomPawns. (which caused clipping issues and some other obscure oddities)

That's basically it, STY_Modulated at it's base is so limited it's ridiculous, and I'd like that changed so things like ScaleGlow and AmbientGlow and Alpha Channel changes can affect the subtractive colouring scheme it uses.. And subtractive lights would make much more interesting lighting schemes for custom mappers, and mod makers.. And I've always hated how you can never rotate a sprite along it's Roll axis to turn it left or right diagonally, not sure if it's been added in Canvas to turn images left or right on their axis, but I just want to see it on DT_Sprite overall..

When the moment 227 becomes absolute final, although I'm sure this may break backwards compatibility but I'm pissed right now.. Can we change the replication declaration where Actor doesn't replicate Rotation when DrawType == DT_Sprite..?? That's really stupid and it causes alot of online issues... And I'm tired of resorting to B$ hacks to get things to work on my side when I'm dealing with DT_Sprite actors that do various things... (I'm talking about Sprite PlayerPawn's)

Similarly to modulated textures, I'm wishing for alpha channel support (in 24/32 bit textures), would be awesome if textures can have a determined opacity instead of a simple palette mask

rotation replication should be fixed, new 227 is having dxt3/5 support for the alpha channels, sry, but now short in time atm...

rotation replication should be fixed

That rotation fix is for the bug when it does not replicate zero value components.
As for replicating it on DT_Sprite I see a very lil use of it as it would be a huge bandwidth waste in the same time.

dxt3/5

I'm not sure how to import the DXT's into Unreal, I've only ended up importing 24-bit BMP and it registers as "S3TC" for some reason...

dxt3/5

I'm not sure how to import the DXT's into Unreal, I've only ended up importing 24-bit BMP and it registers as "S3TC" for some reason...

"S3TC" is DXT1 texture.

So i just imported a dxt5 texture with a gradient alpha channel (supposed to fade the texture out into translucency smoothly)

however in opengl the alpha mask is rendered as a sharp mask, rather then a smooth blending effect, is this supposed to be?

you need one of the latest internal releases for 227g and SmoothMaskedTextures must be set to true, otherwise it won't work. I definitely need more testers for this, so please pm me...

Cheese actually made a mine that slowly fades out to nothing so it's "Hidden" until someone steps on it....so I think Unreal already supports the alpha channel thingy...

Not sure how Cheese did it...it's in iCExplosives though if u can find that (or have it). I'll send it to you if u want

Cheese actually made a mine that slowly fades out to nothing so it's "Hidden" until someone steps on it....so I think Unreal already supports the alpha channel thingy...

Not sure how Cheese did it...it's in iCExplosives though if u can find that (or have it).  I'll send it to you if u want

This:

ah...yeah...that works

you need one of the latest internal releases for 227g and SmoothMaskedTextures must be set to true, otherwise it won't work. I definitely need more testers for this, so please pm me...

Smoothmaskedtextures did the trick!

my opacity now works (mostly) fine! translucency is now mostly accurate to the gradient level of the alpha, the only issue i have though is that the completely black part leaves visible edges with the brighter colors in the alpha channel whereas it's supposed to blend in completely.

pic with imported DXT5 texture+alpha, demonstrating the obvious border around completely black and translucent.

fyi its the word ALPHA written over horizontal stripes.


might i also suggest to put bsmoothmaskedtextures default to true? if mappers ever use alpha channels they won't have to write an elaborate guide to players how to properly enable the effect (most users cannot even find the user.ini anyway)

ah...yeah...that works

which is quite different, fading effects work fine on translucent textures (see nali teleport effect)
but with modulated textures it is a complete different story, as they simply cannot be fade out in its current form.

I made it already to true as default setting. Was thinking about making it hardcoded, but for testing purposes its probably better to keep it configurable.
Which renderer did you use to test it?
And which tool to create the bmp?

I made it already to true as default setting. Was thinking about making it hardcoded, but for testing purposes its probably better to keep it configurable.
Which renderer did you use to test it?
And which tool to create the bmp?

Yeah making it a configurable setting is just fine, as long as its default

renderer was opengl (its taken in the editor), havent tested it in d3d9 yet.

Bmp created with adobe photoshop, no special settings, other then 32-bit bmp.

Was thinking about making it hardcoded, but for testing purposes its probably better to keep it configurable.

Please don't hardcode it...I have it off cause it makes this really stupid annoying bug where it makes some textures translucent for no reason...usually masked textures like grates and bars and stuff...but it also seems to do it with textures that have pure black pixels somewhere in it (which then are completely invisible in that black area, while the rest of the texture becomes translucent and i see through walls).

I'll do a proper bug report when I know more on this.

And thats why we hardcode it so it doesn't do that.

If even the bUnlit flag isn't hardcoded, then you should definitely leave this as a configurable as well.

It may be best to avoid using PF_Masked plus SmoothMaskedTextures enabled for general alpha blending. Rune added a new PF_AlphaBlend flag for alpha blend, but since it looks like just about all the PolyFlags bits already used, it's really a dual use or reallocated bit. It could be more difficult to find a bit for reuse / realloc if care about preserving compatibility. With Rune being a new / different game, easy to free up some of these bits by cutting certain features might not ever need.

SmoothMaskedTextures enabled matches what the Glide renderer does for masked textures, but it also results in use of an order dependent algorithm on polys that aren't always drawn in the right order, so it doesn't always work correctly either. With simpler geometry, there's a higher probability that see problems that are more often minor and more often not seen an all (depending on the mesh, viewing angle, and what's behind it). With more complicated geometry using masked textures, such as trees in Rune, can often see fairly severe problems if enable SmoothMaskedTextures (and whatever is behind the tree is a significantly different color).

Could solve some of the problems with SmoothMaskedTextures enabled if did simple sorting before drawing masked texture mesh polys, but simple sorting based on summed poly vertex Z values (like used with software rendering for other reasons) still won't catch all cases. If ever have any cases where might need to sort across more than one mesh (like if branch from one tree could be between two different branches from other tree in line of sight), then that could be another difficult scenario to deal with.

PF_Masked also enables alpha test at a 50% level, so if try to reuse as alpha blend then won't be able to blend below 50%. For more general alpha blend support would want alpha test to only discard fragments with alpha at or very close to zero. But if change the alpha compare reference value for PF_Masked and masked textures, then the edges of things using masked textures will get pushed out a little (when texture filtering not disabled). This won't look good in some cases.

Also don't want masked and general alpha blending to be sharing the same PolyFlag / state bit if care about supporting the option to use alpha to coverage with masked textures. If use alpha to coverage and multisample to smooth the edges of masked textures, instead of alpha blend, then have an option to more easily smooth the edges of masked textures that avoids significant complexity compared to correct sorting required for correct rendering.

Wouldn't it be possible to just add a flag to Texture directly, something like "bUseAlphaChannel"? So that render drivers know whenever use alpha channel of that texture.

Why smooth/blend anything at all? It's moar cute when textures are sharp.

Why smooth/blend anything at all? It's moar cute when textures are sharp.

No it doesn't, on alpha channeled textures having sharp edges just looks retarded, it has undesireable effects on stuff like plants/foilage, puddles and other translucent effects where opacity should be determined by alpha.

I'm still hoping accurate alpha channel usage could be fixed (maybe as SMP mentioned by seperating it from masked?).

In 227 using textures + environment maps + alpha channeled textures create some of the most awesome specular effects ever... now we just need combiners for that

Hm yeah you're right, I thought you were referring to something else in the first place, non-smooth alpha channeled textures should really look fstupid, although I don't think I ever pretty much even noticed that... hm

Should be able to add at least a couple more single bit flags to UTexture after bHighColorQuality, bHighTextureQuality, etc. without changing the size of this object, but more work for the renderer to track state changes it needs to handle if spread certain things across too many different variables.

Or maybe could find more safe dual use PolyFlags since UTexture and FBspSurf have their own PolyFlags. Already a couple mentioned in the headers as reused for something else in OccludeBSP. If can find others that are maybe only used as FBspSurf flags before ever get to caring about what texture to use and then actually drawing it, then may have the option to have them mean something different in the UTexture flags if can merge into a single PolyFlags variable later before passing to the lower half renderer code.

Also have the option to create a lot more internal use PolyFlags for lower half renderer code only. There are many flags it doesn't use for sure, and if &= ~PF_* these away in all cases where get from higher level code (in case might be set for some other reason but ended up never looked at before), then could create new flags and set these based on other variables, with most of this being to avoid having to pass more parameters around to things like SetBlend() and AddRenderPass().

ok, made some tests with DXT3/5 and alpha. It does work and alpha blending is working perfectly fine if giving it a standalone flag. So either PF_AlphaBlend or PF_Masked. If using PF_Masked for it it just skips the alpha gradient at some point completely.
So question is and/or I need to think about it again if PF_Masked and PF_AlphaBlend are required to be set together in some cases.
On the other hand since PF_AlphaBlend is only supported by DXT3/5 it shouldn't cause any trouble...or do I miss something?


Before:




After:

I can't give you any technical help on masked or alphablend, but for a mapper, i'm really glad to see this feature working now!

Infact i'm thinking of the possibilities with alpha channeled textures and environment mapped textures, you'd be able to create effects that mimick bumpmaps!

(now there should be a combiner scriptedtexture like in ut2004 :p )