de_serenity

[Armageddon]

Having big things on grid helps optimization tremendously.

[Hollow]

don't be grid snobs...

Game play, performance, and the players perspective is all that matters, period.

If you don't want to know how sausage is made, stay out of the kitchen.

Well that is totally misinformed.

BSP and how you use it is intrinsically linked to performance, especially in an old ass engine like Source. Overlapping brushes and huge gaps or off grid stuff fucks up your visleafs by cutting them up in ways it shouldn't. Tidy BSP work means all that extra space could be squared flush with the skybox & sealed more efficiently, saving on optimization. There is absolutely no need to have huge open pockets of space behind the playing area, all it does is impact negatively on the engine.

If you presented your work and they wanted to know how you went about constructing it, your workflow & mapping habits, showing them something like this shows complacency. Yes, it does look good from the players viewpoint, but why is that an excuse to make it in such a sloppy way? You have to work with all of these elements in mind. I used to do this shit years ago, make stuff that looked pretty but ran like crap because I was spamming things in and hiding all the cracks where necessary. It's bad level design through and through & nothing to do with 'typical interlopers being snobby'.

[Major Banter]

don't be grid snobs...

Game play, performance, and the players perspective is all that matters, period.

If you don't want to know how sausage is made, stay out of the kitchen.

If I fill a sausage with some epic, epic filling but then skimp on the actual casing and it falls apart, it has failed as a sausage. Likewise, if I get some really solid casing but fill the sausage with horse meat, it's not worthy of breakfast.

Gameplay, performance and perspective are intrinsically linked into the very fabric of the structure. If the absolute basic structure is sloppy, the other elements will inevitably become so as well, no matter how good they may look superficially.

It doesn't take much work to bring everything onto a unifying vertex. It concerns me that Xyos didn't deem it worth his/her time, when they put so much effort into the models and textures.

With UDK you can afford to be sloppy to some extent, yes, but it underscores a design philosophy that is fundamentally flawed. If you can't be arsed to get the absolute basics together correctly, then I have no faith you can carry any element through to a superb conclusion - merely a mediocre one. This isn't snobbery - this is attention to detail.

[Xyos212]

Source has evolved since the old days. I am aware of the importance of boxing a level in as tight as possible and not leaving open gaps behind it for performance reasons. That is not needed anymore with source today for a few reasons:

1. That small optimization makes no difference on the modern machines of today.

2. Source handles open areas much better now. (func_viscluster!)

Go take a look at militia. You would be shocked to see how much of the map is actually NOT skybox but open area. With the inclusion of the entity func_viscluster (used for OPEN areas) it allows source to handle open areas MUCH better.

There is NO BSP that is rotated, or snapped off the grid. Everything that is off the grid or rotated is a func_detail. Yes I mapped for a long time using UDK and brought some of those habits over, but like I said we are not mapping for HL2 anymore with users running a Geforce 6800. You can have open areas (func_visclustered), you can have func_details off the grid.

There is a reason for everything in my map. That area is FILLED IN with a NODRAW BSP Brush. All the BSP is either NODRAW brushes behind the func_details, or Skybox brushes above.

I posted here to show you guys my work as an artist, because Ive been on this site since HL2 first came out and respect most of the users' opinion. I dont understand why your delving into my map nitpicking its construction. This is a map that has never been done in source. Almost 100% models. Its construction is not going to be similar to a Brushwork based map.

I hate to say it, but brushwork is not enough if your trying to compete with modern graphics in games today. I wanted a look where someone starts the map and says "wow". I achieved that, and am happy. That cannot be done with brushwork. It looks blocky, old, and cant come close to the detail you get with models. Some udk games now dont even make simple walls with brushes anymore, its all models. It can be done in source as well.

This post is primarily for Smurf. Smurf I dont know what your problem with me is, but you seem to be either jealous, or just a nasty person. Every post you have made has been derogatory and insulting. I am well aware of mapping on Source, its not complicated, I've been at it since 1.6. If you want to nitpick my map, do it respectfully and properly.

[Major Banter]

I dont understand why your delving into my map nitpicking its construction.

Well, we have a right to criticise - just as much as you have a right to ignore that criticism!

I'd have to disagree with a number of your statements personally, but that's my opinion. The things that can be done with brushwork alone blow my mind sometimes, and de_investment is one of the finest examples of that I know.

[ErikKiller]

That small optimization makes no difference on the modern machines of today...we are not mapping for...users running a Geforce 6800.

Well, I'm excluded then from playing your map.

[Xyos212]

I dont understand why your delving into my map nitpicking its construction.

Well, we have a right to criticise - just as much as you have a right to ignore that criticism!

I'd have to disagree with a number of your statements personally, but that's my opinion. The things that can be done with brushwork alone blow my mind sometimes, and de_investment is one of the finest examples of that I know.

I have ABSOLUTELY NO PROBLEM with CONSTRUCTIVE CRITICISM. I do have a problem with ignorant criticism thats delivered in a disrespectful and nasty way liks Smurf has been doing. The ignorant part comes from not knowing what I func_detailed and what was a model assuming it was BSP. Assuming that gap behind the wall was not filled in with BSP. All the comments I have gotten on gameplay and performance I addressed in each update, I have no qualms with critique.

If you disagree with my methods than thats fine. I know everyone here knows their stuff inside and out, I am not doubting your opinion. Just consider my methods. Source has evolved since the old days. Since CSS, even since L4D. Take a look at cs_militia.vmf and see what I mean. Try out func_visclusters with open areas. Source is trying to emulate UDK because thats how everyone is creating content nowadays.

Source is trying to have artists focus on the ART aspect instead of the gruntwork.

-As for that map you linked, that is really amazing. Mirrors edge look very cool.

[Xyos212]

@Hollow:

Nothing overlapping, off the grid, or rotated is a bsp. It is ALL func_detail, which is ignored when leafs are created. My Visleaf division is achieved through NODRAW walls behind the func_details of the building and models, through the skybox, hint brushes, and area portals. Like I said a NODRAW BSP behind that screenshot Smurf took occupies that space.

Its worth noting that my portalflow stage of compiling on a FINAL compile is seconds. func_viscluster greatly helps this with large open areas.

If you want to go the extra mile, feel free to decompile my map, Go to auto vis_groups, turn off func_detail and props, and see how I cut the map with BSP, Hints, and area portals.

[source-maps]

come on guys I don't think the guys who gave the critique meant to be meanies so lets not go down this road.

[srredfire]

For what it's worth, I liked your map. The only real things I could say that were wrong with it are:

- Some odd collisions on some of the models, namely the rocks outside near the cliff area.

- A few instances of overlapping models or brushes

- Minor FPS drop outside with all the grass

Other than that I thought it was a very nice looking map. I didn't get to play with a large group so I'm not sure what gameplay would be like on a full server, but regardless I enjoyed it.


Look I'm the nice guy for once!

[Xyos212]

For what it's worth, I liked your map. The only real things I could say that were wrong with it are:

- Some odd collisions on some of the models, namely the rocks outside near the cliff area.

- A few instances of overlapping models or brushes

- Minor FPS drop outside with all the grass

Other than that I thought it was a very nice looking map. I didn't get to play with a large group so I'm not sure what gameplay would be like on a full server, but regardless I enjoyed it.


Look I'm the nice guy for once!

Haha thanks! Ill try to address those collision and overlap problems if I get some time this weekend, the rocks in particular people have complained a lot about on my server.

Gameplay wise through Steam comments and playing on my server, players wanted more cover at Bombsite B, and paths through the middle. I did add those in the last update so hopefully it plays better now

[Hollow]

I dont understand why your delving into my map nitpicking its construction.

The majority of people here are designers/mappers so it's only natural for us to 'nitpick'.

This is a map that has never been done in source. Almost 100% models. Its construction is not going to be similar to a Brushwork based map.

I don't really agree with it not being attempted in Source. Also your comments on func_viscluster are a little skewed. func_viscluster just tells an area of visleafs they can see each other, and skips calculating each individual one inside that volume, what it doesn't do is reduce the number of leafs, so in effect you aren't optimising anything, you're just telling the compiler to bunch them together, that's why its fast.

Source is not designed at all to handle huge expansive environments like UE3 or CryEngine which primarily uses proper model instancing (not the same as vmf instancing fyi) and can stream it's environments, generating PVS based on meshes and not BSP brushes (something not supported in vanilla Source). It's an entirely different beast and going from UDK to Source and adopting the same workflow is pretty backwards, so you need to have a solid understanding of Brush-based workflow if you're going to map in a brush-based engine...even if it's 90% models.

[Xyos212]

I dont understand why your delving into my map nitpicking its construction.

The majority of people here are designers/mappers so it's only natural for us to 'nitpick'.

This is a map that has never been done in source. Almost 100% models. Its construction is not going to be similar to a Brushwork based map.

I don't really agree with it not being attempted in Source. Also your comments on func_viscluster are a little skewed. func_viscluster just tells an area of visleafs they can see each other, and skips calculating each individual one inside that volume, what it doesn't do is reduce the number of leafs, so in effect you aren't optimising anything, you're just telling the compiler to bunch them together, that's why its fast.

Source is not designed at all to handle huge expansive environments like UE3 or CryEngine which primarily uses proper model instancing (not the same as vmf instancing fyi) and can stream it's environments, generating PVS based on meshes and not BSP brushes (something not supported in vanilla Source). It's an entirely different beast and going from UDK to Source and adopting the same workflow is pretty backwards, so you need to have a solid understanding of Brush-based workflow if you're going to map in a brush-based engine...even if it's 90% models.

Hollow I am not trying to argue, and can take critique and respect your opinion, but I must justify my methods. I have the understanding of brushwork already. What others have pointed out as BSP was actually a model or Func_Detail, entities ignored by the compiler when creating visleafs. My BSP is nodraw walls behind what the player sees, like I mentioned in my earlier posts. Like I mentioned if you want to see what I did feel free to decompile and turn off the auto visgroups func_detail, and props, and see how I divided and cut the map.

[Hollow]

I'm more referring to this sort of thing:


I can see every single model in your map from one side to the other. There's nothing culling visibility, not even model fading applied. At one point it dropped down to under 5 fps.

I'm not trying to argue either, I just think you're getting a little confused as to what I'm trying to explain.

[Xyos212]

Hollow thats fine to point out faults, haha Im not perfect far from it. If you move around though not everything is rendered like that. That area you are standing sees into the left, right and center of the map.

I wont deny I could of optimized better though. If I get some time for it I will try to address optimization more. I will admit optimization took a backseat, I was too focused on the art and model side of things. I wont make that mistake in the future

Also I apologize if I have been over defensive. There is still much I have to learn and want to learn to better myself in mapping, and taking criticism from fair, to delivered in a harsh way is something I must work on.