I understand your concern about optimization and the assets being created, and let me say, first and foremost, that's my concern too. I have gone to great lengths to create functional, good-looking and cost-effective assets. Going into projects like this one, and the swamp set and the mayan set for loot, a budget is always on my mind--how could it not? I can't pretend that items I make are going to have no consequence, especially when I understand the possibility of other people using my materials for their own projects. I don't have an ultra powerful gaming PC, I simply can't afford it. My graphics card is getting so old, the new maps are really taking their toll on my computer. Sometimes in the heat of things, it gets so unplayable I have to just sit next to a sentry gun and hope for the best...
What I'm getting at is that the source engine and Valve in particular have always been concerned with people who don't have the best gaming platforms available, but don't penalize those who do--they've demonstrated various backward compatibility solutions for people not up-to-date with the best hardware available.
So the suggestions and the critique, while I appreciate them, don't really have a whole lot of consequence in the Source engine--and by that I mean that the Source engine thrives on modeled detail--the engine doesn't support normal maps like most modern game engines do, just a limited bump map, which sort of scrapes the bottom of the barrel in terms of acceptability for the function it provides. Let me show you an example of what I mean:
Here's a brand new asset that came out in the latest engineer update, boulder5.mdl. It looks really fantastic, I love the shape of it. And like most of the previous rock props, you'd expect it to be around 200, 300-500 polygons at maximum...but it's not!
This seemingly basic world prop is just 9 polygons less than my piano model. Which do you think is the more complex shape? I'd certainly think the piano deserves every one of it's 2311 triangles. And on top of that...this boulder has no LOD versions, while my piano's LODs cut the polycount almost in half. The truth is that the artist who created this model felt the need to retain the polycount to preserve the detail, which would not have produced the same result if using a real normal map.
If the Source engine build of TF2 supported normal maps, I could see boulder5.mdl being cut down to the expected 300 or so polygons. And I too would bake a normal from a highpoly version and make a lowpoly piano with it. But in the Source engine, we simply do not have that option. As is now...using a normal map is a poor choice, I'd be using up another 512 or 1024 map that I could fit into the theme's budget somewhere else. Additionally, it should be noted this piano will probably only be used 1 time in the map, as it is unique, and it's going to be indoors, in an enclosed space, world geo sealed off with areaportals to ensure best possible optimization, YM has already picked out a spot for it.
Speaking of which, have you seen some of the barrels?
Or god forbid, the airboat from the swamp pack: all of its faces are double sided (if you no clip into it, you can see the insides!)
Please, you're hurting "$nocull" "1"'s feelings. Just an honest material property doing his job. And I made that model (it has LOD's too!). And for Alia, the SDK wiki defines nocull as:
$nocull
From Valve Developer Community
Jump to: navigation, search
Makes the material appear on the reverse side of the surface it is applied to. Generally only useful when used in conjunction with $translucent or $alpha.
I don't believe it doubles the material, just makes the polygon double-sided. It's extremely useful in optimization, and things like foliage, fences, the piano uses it for the wires.
And I want to assure you I didn't keep every single key, that would have been silly! I joined all the polygons together for the white keys after baking the ao map, here is the result: