Position: Team Leader, 3D modeller, event scripter, sound design, level design, texture design
Occupation: Aspiring Game Designer, Boyfriend, Restaurant Front Worker
Age: 20
Listening to: (keeping music off for system resources)
For today's update, it's basically going to be catchup since the previous updates, nothing too major has happened since the last one but enough cool/important things have been done that I think it's time for another one.
Firstly, the retail foliage. You've probably noticed at some point that JPDS~testing used modified textures for some of its retail trees. These were cool and all, way better looking IMO than the retail ones, but still quite similar and clashing at times with the TC_Isle foliage. Recently while Nem was working on the level and I was figuring out which out-of-level objective I should take care of next, I decided it was a good time to bring the old retail-based textures up to speed.
The "willow" trees had actually been modified since JPDS~testing's release (you can see this version in Nem's update) but were not quite satisfactory and too uh.. saturated. I took fresh versions of the textures and modified them such that the tree would no longer seem so happy and colorful.. the result surprised me quite a bit.
Moving on to the other ones... I decided 100% new textures were in order. I dove into my self-generated photo texture archive and dug out the best bark examples for the trees I was looking for. They ended up being absolutely brilliant, dark, and fitting in seemlessly with the TC_Isle tree textures. The only original elements of their textures remaining are the leaf opacities and the more willow-like leaf textures (darkened/desaturated). The main leaf texture seen by us all a million times got a make-over with a certain photograph of mine and it works great.. biggest differece is that it has more variance and not just this or that color. Anyway here are the pics.
Btw, I had to actually modify the UVW for all the bark so it tiled properly (and the retail trees use tons of different textures, now there's only 2 for each bark type), which meant importing them into Max, spending time welding all the right vertices (yes, the import script fails even for retail models), map ID management, UV and UV unwrap.
There was one interesting case.. a tree model that turned out to be 100% identical to another except that it was internally rotated by a certain degree. I figured out that this was to give it a different texture set which accurately cast shadows onto the bark based on its canopy. Tricky little devs.. guess that means they were not intended to ever be rotated ingame. Ooops! Well so, since I didn't have another bark texture ready and didn't want it to be identical (I, for one, am not going to render shadowed maps), I just gave it the old-tree bark from TC_Isle.
Went on to create new rock textures to replace those ugly things on the climbable rocks..
Matt and I rather liked them but Nem pointed out that they looked too clean. So, I made a new set, which we all agree looks much better than either previous (starting image photographed by Matt).
Next fun thing I did was attempt to run Trespasser in triple buffer, since Matt indicated it was apparently what gave him such immensely superior framerates. In the initial test, changing the value in the INI file, I had this fun error where the lower 2/3rds of the screen were light blue, occasionally flickering with the actual display, making navigation through the menu and through the level quite difficult. Apparently these flickers are known as "thunders", heh. FPS did seem improved to me at the time.. Matt showed me how to accommodate for this by altering some graphics card settings. In the end, this did work but FPS seems mostly unaffected. I could run JPDS in 1024x768 and I'm not sure if it was related to triple-buffer or not, but ultimately I deactivated TB because much of the time it caused a black screen while playing the opening cutscene.
K what else.. well there are some things we can't mention of course. There was this fun pic I snapped and turned into the new JPDS~testing loading screen, my fav. to date..
Then.. I was.. well I wasn't bored, I think I was just up late and in one of those moods. Made some cool images in photoshop..
Well.. here's a little peak at some of the other things I've been doing.
And now.. in closing, I'm actually going to discuss our latest problem. First off, earlier this week I painfully went through all the JPDS1 textures and put many of them into one of a select few palettes I had open in photoshop. Many of the retail ones I just didn't bother with, since they are generally more optimized like that and there are just so goddamn many of them. I did make sure to do all the rocks and wood, though, but the biggest thing was getting all the TC_Isle textures to use existing retail palettes. Now so, when I finished this, I went to update a blank JPDS1 SWP with these textures. The problem was that GeomAdd began telling me there wasn't enough space in the SWP file. I was like, WTF, these are the same ones that were just in there... Of course, the 24-bit'ers were overlapping each other in many cases. I spent many, many hours last night consulting with Slugger and attempting to make it all fit into the SWP file like I wanted. Here are my conclusions:
- The blank SWP files given to me by Rebel, prior to any being publicly released, did indeed have more specified SWP space than any of the released blank SWP (or is it in PID?) files currently available to the community. He said they had an especially high texture size limit because they were the TC_Isle backups and the 24-bit maps in that level were cause for considerable additional space to be used. The ones generated by Rebel's new level generator seemed to be the smallest, while the XX files were somewhere between that and TC_Isle's backups. I could never tell for sure because GeomAdd won't display the "mb used out of" limit data when entries from the PID file were missing.
- When dealing with 24-bit textures in a SWP file, the order of import can mean everything. A small test level with only models that included 24-bit maps (and the player) was made, and in some combinations of SWP updating, even just those few caused GeomAdd to announce that the firstPacker had run out of space. This probably (IMHO) means that 24-bit texture arrangement by GeomAdd is highly inefficient, or that the format usable by the SWP just isn't great for 24-bit maps anyway and is one reason why we don't see 24-bit windows in the game. Strangely enough, there was a way I found to get them all into the test level.. I forget exactly now, but I repeated the process with JPDS1 and then imported the REST of the textures - the result was a SWP file that cut short many MBs away from the total original size, meaning that there is no truly optimum import method that will let the rest of the textures fit in. The reason TC_Isle could do it is because it did not actually have as many normal (8 bit) textures as JPDS does (that is one good design element to congratulate the ops for, they only made as many textures as they needed to), JPDS relying heavily on retail textures.
- From what I can see (though it's not yet conclusive, really), the rectangular shape of some new 24-bit bmps is responsible for most of the overlap you get when importing new textures. I had hoped that by changing my rectangular window textures into squares, I could optimize the arrengement such that they would fit better into the SWP, but ultimately it only seemed to reduce the number of additional (8 bit) BMPs that could be imported, meaning that it is conclusively not a solution to the problem.