Mapmodels with alpha?
#1
Hello.

I have a question:

Is it possible to make mapmodels with a smoothly changeover from normal texture to alpha?

I've tried with a normal .png but AC cuts it automaticly in total transparent and non-transparent.

But today I've looked through various files in my AC and found eg.
"damage.png" and "scorch.png" and they are half-transparent in AC.

Is there a way to make this in... the md3.cfg or maybe with a extra "alpha.jpg"?

Thanks in advance,

a_slow_old_man
Thanks given by:
#2
No. Smooth transitions would break the minimum requirements of this game. Smooth transitions are very costly.
It's either on/off transparency, or an overall fixed level of transparency like damage and scorch.
Thanks given by:
#3
only over time.
alias cycleup 0
alias alphaloop [
(damagescreenalpha ($cycleup));
(if (< $cycleup 100) [alias cycleup (+ $cycleup 5)] [alias cycleup 0]);
(sleep 10 [alphaloop])]
Just a really goofy script to play around with the alpha over time.
Thanks given by:
#4
Dunno about mapmodels (though iirc their rendering is no different than the rest, except that they're compiled displaylists), but in general PNG offers key colour (on/off), "baked-in" transparency (as in RGBA), and a separate alpha channel. This is usually set in save options or implied from image properties, depending on what editor you use.

If you can't explicitly set the format, you can try opening an image from AC & saving with a different name (check ac/packages/misc/scope.png, scorch.png, compass-base.png or damage.png).

This depends on AC fully following image format when creating textures in all usage scenarios, which may or may not be the case, but it's worth a try.
Thanks given by:
#5
It is not the case. Ac will ignore any alpha channels in png's, and will only use on/off transparency, creating hard edges if need be.

It's a question of performance, not of possibility. It could be coded in seconds. But its benefit compared to its cost is just too small to justify it. It would give a small detail of eye candy to some, but lag out many.
Thanks given by: