Mann Manor

CP Mann Manor Final release

Draco18s

L9: Fashionable Member
Sep 19, 2009
622
136
If you look at other models within TF2, especially center pieces like this, you'll see that they're quite high on the poly count. His model is actually at the lower end spectrum for what you'd find in TF2.

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!)
 

Chemical Alia

L2: Junior Member
Jul 22, 2010
98
51
If you look at other models within TF2, especially center pieces like this, you'll see that they're quite high on the poly count. His model is actually at the lower end spectrum for what you'd find in TF2.

Sure, like a truck. There are higher poly models, but it's relative to the amount of necessary detail. Also, notice that you see these models usually off to the side, and isolated from a lot of other high poly objects, with very sparse things around them.

You still have to consider every asset for what it is, and optimization/performance should always be the priority and unnecessary details simplified. And that piano has tons of unnecessary details, or details that could be handled in a less expensive way.
 

YM

LVL100 YM
aa
Dec 5, 2007
7,135
6,056
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!)

That's intentional actually, some of the thin geometry is one-sided and the material has $nocull so that you can see it on both sides. Useful for thin thing.
 

Chemical Alia

L2: Junior Member
Jul 22, 2010
98
51
Hehe, you should talk to Valve about props like the buff banner.

A single banner (not including the bugle or it's backpack) is well over twice as many polys as this piano. it's almost like valve forgot what optimization is since TF2's release.

They've got so sloppy over their asset creation it's sad

I haven't been keeping up with a lot of the new stuff in the past couple of updates, and don't really know what it looks like to be honest. But it is a main character item and more important, so I'm more inclined to allow for extra details. Obviously the weapons and first person stuff even more so. But yeah, I have noticed a lot more combined in some of the newer weapons, and even the Ambassador doesn't have any animations to it, unlike the original pistol.

That's intentional actually, some of the thin geometry is one-sided and the material has $nocull so that you can see it on both sides. Useful for thin thing.

But doesn't that essentially double the material for the entire mesh? You could just duplicate the propeller or selected thin parts, and flip the faces. Or depending on where it is, it probably wouldn't even be noticed if there's one-sided faces. Like, the sunglasses for the Sniper and Heavy's Hound Dog hat are one-sided, but despite being right in the faces of the characters, you never even realize it unless you inspect it in the model viewer.
 
Last edited:

Rexy

The Kwisatz Haderach
aa
Dec 22, 2008
1,798
2,533
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:

boulder_05_show1.jpg


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!

boulder_05_show2.jpg


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:
baby_grand_02.jpg
 
Last edited:

YM

LVL100 YM
aa
Dec 5, 2007
7,135
6,056
I haven't been keeping up with a lot of the new stuff in the past couple of updates, and don't really know what it looks like to be honest. But it is a main character item and more important, so I'm more inclined to allow for extra details. Obviously the weapons and first person stuff even more so. But yeah, I have noticed a lot more combined in some of the newer weapons, and even the Ambassador doesn't have any animations to it, unlike the original pistol.

I'll fetch the facts for you:

The buff banner is 8,686 polys. I know it's juggleboned so it flaps as the player moves, but it really could be done in more like 1,000 polys without any appreciable loss in detail. The bugle and backpack that accompany the buff banner add another 8,000 and 3,000 respectively.

The soldier, for comparison, is 16,620 polys. This means a soldier who is wearing a hat (let's say the new worms one at 9,770 polys) as well as using the buff banner is a grand total of 42,000+ polys.

And what's more is out of that list only the solder model has LOD models. so even a soldier in the distance maybe 100 pixels tall is taking up the same amount of polys as 1.5 soldiers (with no post-release equipment) that are only a foot away from you.

A release day soldier+rocket launcher would take up a grand total of 2,300 polys at the same distance.

42,000 polys vs 2,300... It's no wonder there are people complaining about significant performance hits with each update when the average poly count per class has doubled and now doesn't diminish with distance.


So like I said, Valve's newer assets aren't optimised at all. Not one of them has a single LoD model and not one of them is even the slightest bit conservative on it's polycount.

.

RE nocull: Yes it probably does double the number of polys the engine is rendering, but it may not, I don't know exactly how source deals with faces that aren't facing you and how nocull actually impacts that. If source handles it badly it could mean you're rendering double at just under 14,000 polys for the airboat, or it could handle it well and mean you're only rendering the full 6,900 polys the model actually is. (of course, if the latter is the case, the polycount rendered if it wasn't using nocull would be on average half the stated value)

So, difficult to tell if nocull is bad or not.


Also @ rexy, I think that rock prop was just another victim of the new lazyness in valve's assets. It looks to me like they just subdivided the existing rock models once then sculpted them a bit to make a normal map. They also have no lod models.
 
Last edited:

Rexy

The Kwisatz Haderach
aa
Dec 22, 2008
1,798
2,533
See that's the mystery...is it on purpose? Or is it laziness? Something they're not telling us? *shrug*

Edit: I did not know that telefragging an enemy charges your buff banner...that's awesome...wish I played more soldier.
 
Last edited:

littleedge

L1111: Clipping Guru
aa
Mar 2, 2009
986
605
10:15 PM - Selentic: If the Source engine build of TF2 supported normal maps
10:15 PM - Selentic: .
10:15 PM - Selentic: .
10:15 PM - Selentic: .
10:15 PM - Selentic: .
10:15 PM - Selentic: .
10:15 PM - Selentic: hello rexy
10:15 PM - Selentic: tf2 supports normal maps

Just thought I'd pass this on since I'm curious now.
 

Rexy

The Kwisatz Haderach
aa
Dec 22, 2008
1,798
2,533
I don't believe so. The Source engine does not render normal maps. What you're talking about is a bump map, which is not the same thing, and produce different results. The shader effect you're all refering to is "$bumpmap", though the term bump and normal map are often interchangeable lingo. The result of the above is not a true normal map, not as in those being used in modern game engines.

There's some information out there on the differences, go look for yourself:

http://en.wikipedia.org/wiki/Normal_mapping
http://en.wikipedia.org/wiki/Bump_mapping

http://developer.valvesoftware.com/wiki/$bumpmap
http://wbs.nsf.tc/articles/article11_e.html
 
Last edited:

JoshuaC

L420: High Member
Sep 2, 2008
444
164
I don't believe so. The Source engine does not render normal maps. What you're talking about is a bump map, which is not the same thing, and produce different results. The shader effect you're all refering to is "$bumpmap", though the term bump and normal map are often interchangeable lingo. The result of the above is not a true normal map, not as in those being used in modern game engines.

There's some information out there on the differences, go look for yourself:

http://en.wikipedia.org/wiki/Normal_mapping
http://en.wikipedia.org/wiki/Bump_mapping

http://developer.valvesoftware.com/wiki/$bumpmap
http://wbs.nsf.tc/articles/article11_e.html

Wow.. I don't even know how anyone can come back from that one.
 

grazr

Old Man Mutant Ninja Turtle
aa
Mar 4, 2008
5,441
3,814
Funny how most people don't realise that. But maybe that's just because i grew up around bump maps and when they were first (hacked) introduced to Gld Source.

It always kinda bugged me that people started using the term normal map synonymously.
 

Rexy

The Kwisatz Haderach
aa
Dec 22, 2008
1,798
2,533
You're absolutely wrong if you think source doesn't render normal maps. It may not handle them the way that other engines do, but it is far from what bumpmaps offer.

Really? Because I've never found a material that actually uses one...can you show me an example?
 

Rexy

The Kwisatz Haderach
aa
Dec 22, 2008
1,798
2,533
No, I'm being serious, I'd like to see an example. All the materials from the gcf I've ever found only have $bumpmap, and none of them behave like normal maps...I'd like to know I'm wrong because it's ridiculous not being able to have good reliable normal maps in the source engine.
 
Jan 31, 2008
555
1,482
I'm not sure what you're talking about Rexy. Many TF2 textures use normalmaps, which is one of the ways you can do bumpmapping on a texture. You can also use the Self-shadow bump mapping technique, or heightmaps if you like. They all go under the bumpmap category, and they all go next to the $bumpmap parameter.

People seem to call heightmaps bumpmaps, as if normalmaps are not bumpmaps...
 
Last edited:

Rexy

The Kwisatz Haderach
aa
Dec 22, 2008
1,798
2,533
I'm not sure either, I think I'm probably just making a fool of myself. I've used it tons of times to create effects, I just assumed the Source engine is really crappy with this effect, not at all like other engines, and took the name $bumpmap literally...I apologize for taking this discussion beyond what should have been, and for being wrong. Sorry everyone!
 

Chemical Alia

L2: Junior Member
Jul 22, 2010
98
51
No, I'm being serious, I'd like to see an example. All the materials from the gcf I've ever found only have $bumpmap, and none of them behave like normal maps...I'd like to know I'm wrong because it's ridiculous not being able to have good reliable normal maps in the source engine.

I am also confused by what you mean by this. From the VDC articles on bump maps and $bumpmap:

The texture is a bump map, but the process it is used for is called normal mapping; the two terms are often used interchangeably, however.

Format

Each pixel in a bump map contains the (x, y, z) coordinates that define a normalized vector.

Because of this each color channel in a bump map has a meaning:

1. The red channel defines the horizontal facing (X-axis coordinate) of the vector

0 = left ( Converted to -1.0 by the shader )
128 = forward, or facing viewer ( Converted to 0 by the shader )
255 = right ( Converted to 1.0 by the shader )

2. The green channel defines the vertical facing (Y-axis coordinate) of the vector

0 = up ( Converted to -1.0 by the shader )
128 = forward, or facing viewer ( Converted to 0 by the shader )
255 = down ( Converted to 1.0 by the shader )

3. The blue channel defines the height (Z-axis coordinate) of the vector

0 = facing 'in' to the texture away from the viewer (Converted to -1.0 by the shader, and as a result this is a 'bad' value. Anything under 128 means that the surface should be facing away from the player. This is not possible.)
128 = maximum depth capable of receiving dynamic light (Converted to 0 by the shader. It's a bad idea to go under this)
255 = facing 'out' of the texture towards the viewer (Converted to 1.0 by the shader)

The three channels represent a normal vector for every pixel which represents the direction that the pixel is facing in 3D space. This allows the engine to generate shadows and highlights on a two-dimensional surface, or give a 3D model more detail.

This sounds like a normal map to me, just that Valve uses different terms (like albedo for diffuse maps). You create RGB normal maps just like for any other engine, and I've never seen them behave any other way in lighting, despite the name of the $bumpmap parameter in the vmt.

Edit: Lol, basically just you can use them. And they are good. Though to be honest, TF2 isn't all that normal map heavy, and most props that I've seen them are just diffuse with some ambient occlusion. Characters and weapons use them, though.
 
Last edited: