Animated Textures for UFOs [CODING HELP NEEDED !!!]

[MCR]

btw, for v3 of this I will introduce subfolders in tex_ua for much easier navigation through the frames...

So if you are searching for a skin or for a screen-overlay or button, you will find all of these in their designated subfolder... 

I am just not 100% sure what to do about the buttonskins, because they should be in the same folder like the buttons are & maybe even stored redundantly for each animation, so the 'coder' of the material file can not 'forget' the skin around the button, if they need one (not all of them do)...

Also I will make some additional demo material-files for other levels, like basedefend, where I will show more of the benefits this new system has to offer & that is, that we could use most of the screen overlays for multiple different monitors (example: the so2_17_0*.* animations also 'fit' on the screen of ufo2_13-16), so we can use the same overlay-animations on different monitors & screens if we design them wisely

Also I will introduce a new readme.txt file, which gives a short explanation on how many frames a animation has, what it shows & which playback-command to use to best show it in all of its beauty & to help making the set-up of the material file as easy as possible for the mappers

There will be also a material file, which contains a whole setup for the most complex animations for the U.F.O.s possible (all buttons, all displays, all animations enabled), so mappers can copy & paste from there & just have to delete what they do not like for their level afterwards. So it should be possible to set up a complete U.F.O. material definition in 2 minutes if one does not like to optimize stuff 

Also each other material-file I will make, will have a complete documentation (with comments), so it would be easily understood even from people who know nothing about the material system & also can be copied easily to other material files .
You can see a preview of this (unfinished & unpolished) in the tropic.mat file of v2 already...

I will also update the wiki (never done that before) to keep everyone interested up-to-date regarding all of this.
I found out for example that it is not necessary to compile @ all, when adding new definitions or changing existing ones in the material files. You can set this up on the fly. That also will help mappers in setting this whole thing up nice, fast & easy...

Also I want to note here, that this new system is really innovative, I checked out ALL available demo-material files from Quake2world, before I started this, to see what others have done with it & to learn what is possible, just to find out that NOBODY  pushed this as far down the rabbit hole as I did here for UFO:AI  . Maybe it got a little complex  , but it adds loads of functionality & variance-possibilty to our U.F.O.s for sure... 

For all of you interested in this, please check out tropic.mat from 1materials.pk3.

And now I will 

[MCR]

Here once again 1pics.pk3.

I am really sorry for all of you who had trouble downloading 
I think me & Gren killed Hyperupload.com 

Here is a new link:

http://rapidshare.com/files/375834363/1pics.pk3.html

This one is triple-checked by me (uploaded, downloaded, decompressed & surfed through (=opened) all of the frames once), so I really hope there will be no problems anymore...
Unfortunately you will have to wait 35 seconds until the downloadlink appears & there are only 9 additional downloads available from v2 of this. So you maybe will have to hurry to get your copy  . Just joking.

Really hope everything worx thiz time...

[MCR]

@Mattn: I have 3 additional questions regarding the material system:

1. Are all the property-textures & textures loaded into memory, which are defined in the material file, or only those textures & their property textures that are really used in the map loaded ?

2. Is there a possibility to use one of the blendmodes with 'empty' frames (only alpha channel), so that I could use simply 'empty' frames when nothing changes in the animation for a couple of frames (e.g.: buttons not changing for 5 frames) & if there is such a possibility which opengl blendmode command do I have to use to achieve this effect ?! I already made a couple of experiments, but did not find out somehow, but I am quite sure that this should work somehow & could help us save additional ressources  

3. I also had problems with property textures deleting or overwriting the original texture during the animation if I try to use ressources wisely (see animation fx2_10_0a0-15 for example), which deletes the original green color below when used (gets black below) ... (will attach 4 screenshots of those frames to show what I mean)

[H-Hour]

I already wrote a feature request regarding this & I am all for supporting old systems & slow computers also, that is why I think there should be an additional graphic option to turn off the material system & all new tex_ufo textures (already in trunk) are ready for that (nothing cut out in the standard-texture)

I don't like this idea, because some aspects of the material system are vital. My street textures, for instance, simply wouldn't make sense without their material blends.

I tried to make the animations as small as possible that is why I even cut out the skins around the smallest buttons to not have to load them into memory for each frame...
So do not worry, Nate, I will optimize this stuff to make it use as little resources as possible. I have additional plans also, but do not know if this will be working yet, so I will shut up for now.
But I must stress here that we are in 2010 (or 2084  ) & we should not make a game that looks like it was made for computers from the year 2000.

The optimization is not really the concern here, it's all very small. The problem is the excessive number of uselessly different animations.

Look @ them again:
b2_13-16_1a - 1c are completely different button behaviour animations

& as you know I already agreed with Mattn, that there will be no versions of animations in v3 anymore, which just vary color ...

I think we're crossing signals here. b2_13-16_1a all the way through to b2_13-16_1h are all animations of the same exact button set. That's 6 different animations for the same sets of buttons (there is no "d" or "f" for those paying attention). They're not "completely different button behaviour animations".

Also as mapper who is building 1 map all the time you should not forget, that I made animations which will be seen on dozens of maps & my goal was to make no U.F.O. look like another, to create the illusion for the player that each U.F.O. is a special one.

There is not a player in the world who is going to notice that the button sequence on this ship went 1-3-4-2-1-5-5-2-5-1 and the button sequence on the other ship went 1-4-5-1-6-2-6-1-4. This is pointless variation.

That is why I did all of this work, because I realized that this IS possible via the great material system.
But with the system of 'layered animations' we can make this possible even if we would have no color @ all

Look, this is part of a bigger issue I don't want to go into, because this game does not have enough artists. But it really lacks artistic direction. The artwork should not be guided by the technical capabilities of the engine. It should be guided by an artistic vision and those components which are necessary to make it work. Just because something is technically possible doesn't mean it should be done.

3. - so2_13-16_2a: Source File 
    - so2_13-16_2b: Source File Reverse (not necessary anymore thanks to Mattn & animb)
    - so2_13-16_2c: Source + ScreenFlickering
    - so2_13-16_2d: Source + ScreenFlickering backwards
    - so2_13-16_2e-l: 4 additional different color variations of the HumanScanner in some nice colors
    - so2_13-16_2m & o: Changing the color during the animation
    - so2_13-16_2q: Defect Screen Animation (unfinished)
    - so2_13-16_2s & u: Unfinished Copies

These were the lists of variations you have for the man animation. This is precisely an example of the excessive variation I'm talking about. You should not have 12+ variations of the same animation. If you want to make every UFO look unique, you will not succeed with different colors, or having a screen flicker a little bbit in this one animation. You will need to make screens that show completely different objects. When the player sees two of these animations on different UFOs, he will not think "This one is purple and the other one was green." He will think, "It's the human face animation again". He will recognize the similarities, not the differences.

I leave this decision to the mapper, my friend, that is why I invented those layered animations. Now you can choose if you want a button to be displayed or not, you can choose if you want a button animation for a screen, you can choose the speed of each of the animations, so you can have a fluently moving screen animation with 8.0 fps, while @ the same time the buttons beneath the monitor 'move' with 0.2 fps.

This is exactly what I don't want. I want three variations of all the button panels, so that I don't have to spend forever setting up complex material files.

You would not write all this stuff, if you had understood the new system I am introducing here. 
Please take a look @ the tropic.mat file to get a small overview & also try to make some experiments there if your time allows it...

I stand by my opinion that it's excessive, unnecessarily complicated and not artistically useful. Those animations you've done which have a subject -- the UFO, the human, the text, the planets -- are excellent and great work. I think your work adds a lot to the UFOs. But I think you've gotten caught up in the world of the technically possible and lost site of the artistically meaningful. Beyond a few different options, variations of the buttons add very little value to the end user's experience.

If you want to make each UFO different, you should put your energy into developing diverse SUBJECT MATTER. This means you should create animations that are entirely different in terms of what they represent.

I'm not a dev and I don't make these decisions. You've asked for my opinion and this is it, and I'd probably give it even if you didn't ask for it. But in the end the dev's will decide what they want to include. 

[Mattn]

1. Are all the property-textures & textures loaded into memory, which are defined in the material file, or only those textures & their property textures that are really used in the map loaded ?

they are all loaded

2. Is there a possibility to use one of the blendmodes with 'empty' frames (only alpha channel), so that I could use simply 'empty' frames when nothing changes in the animation for a couple of frames (e.g.: buttons not changing for 5 frames) & if there is such a possibility which opengl blendmode command do I have to use to achieve this effect ?! I already made a couple of experiments, but did not find out somehow, but I am quite sure that this should work somehow & could help us save additional ressources  

no - not possible

3. I also had problems with property textures deleting or overwriting the original texture during the animation if I try to use ressources wisely (see animation fx2_10_0a0-15 for example), which deletes the original green color below when used (gets black below) ... (will attach 4 screenshots of those frames to show what I mean)

where is the question here?

[MCR]

they are all loaded

Good to hear, I thought so after testing tropic on a old laptop yesterday.  - room for optimization !!! 

no - not possible

Now I know that for sure, no need for additional experiments for me on that field. Thanx.

where is the question here?

You are right, I forgot the question (lol), as this was intertwined with the second question...
So you answered this one also, even without question & answer  Reminds me of magic somehow
Thanx again.

[MCR]

@H-Hour: I will not comment your stuff anymore, as this is beginning to remind me of kindergarten.

Just one note here:

Your animations (3 animations: advertaa, advertab, advertbb):    22 frames, 2.63 (!) Megabyte

All my Buttons-animations (countless animations):more than (!) 1222 frames, 1.33 (!) Megabyte

I will stop here.

[H-Hour]

I'm sorry if I've upset you, MCR. I really do think some of your animations are great. I may have pushed my point a bit hard, but that was the second lengthy response I gave to your work, both making the same point (both of which at your request, btw). So I may have tried to get my point across a bit too forcefully.

But we're certainly capable of disagreeing, I hope. And we're also capable of critiquing the work that goes into this game. It doesn't mean the critique always has to be accepted, but I believe it ought to be given.

[MCR]

I will revive this project this weekend, so if you have any suggestions left, feel free to post those here...

[MCR]

I am currently in the process of reworking v2 of the ufo-animations.

I've already managed to reduced the size of all animationframes & skins together to under 5MB.
Unfortunately I am really not able to control all the colors of the animations just via the color command of the material system, this produces sometimes weird results & in many cases you are not able to use it for more than to 'influence' the color, but you are not able to make something that is completely green red for example...
So I am forced to keep at least some of the colored animation-versions to make the design work correctly...

The new commands are very useful, especially 'anima' & work fluently, thanks again for that, Mattn !!!

I will also introduce a new folder for the property textures named 'pt', where all of the frames, skins, buttons, screen-overlays, damage-animations will be stored in their respective folders.
This will make sure that no mapper will be confused with those textures, as those are purely defined & managed via the material system & will not be mapped directly in UFORadiant.

I will then delete all of the then unused property textures already messing up the tex_ufo folder.

I hope everyone agrees with this version of things, otherwise just make some noise here
I hope everything can be finished tomorrow evening...

[MCR]

I am uploading @ high speeds between 0 & 0.5KByte/second. Why is this so slow ?!?!?!?
Yesterday my commit failed after 3 hours of uploading 

But I am fighting to get the new ufo-animations in-game ! I am not giving up ! 

[MCR]

Okay, everything uploaded !

If you have suggestions or experience any bugs, please post those here.

Have fun with the new animations !
I hope everything worx as planned !

[MCR]

@Mattn: Is there a possibility to upgrade MAX_GL_TEXTURES ?!

1024 is not a problem on most maps, especially I am having the problem of hitting the maximum always just in tropic.
Several reasons: Tropic has not only the big Corrupter landing there, but also the Harvester. This would be no problem in tropic +bigufo alone, but there are also other tropic maps, where many additional textures for houses, interior & plants are loaded & here I am starting to get real problems with this limit...
In the mid-term problems with this limit will occur on other maps also, as our textures will get upgraded with ,_gms, _rms, _nms, _sms.

I tested increasing this limit & my problems were gone, no new problems occured...

So if it is some kind of oldschool-quake-artifact limit & not important anymore in 2010, please increase it by at least factor 2.

[MCR]

I have some ideas how to reduce the amount of texture slots needed for the animations by ca. factor 8-16, but I need help from a experienced coder to make this possible...

I want to introduce a new set of material animation commands which, when executed, will just use one texture per animation, so a 1024x1024 pixel texture could hold 16 frames of a 256x256 pixel animation.

@any experienced coder: Please help me realize that vision.