Beleg Cúthalion on 10/5/2008 at 06:32

---

Level sizes are somehow dictated by the static meshes, that's why Komag says you have to get accustomed to the library. But that's not new. However, there is some list around here including standard heights for doors (8ft.), rooms (10ft.), max. mantle heights etc..

What I learned thus far: Try to keep the brushwork simple. In fact you can do a lot with it, but T3Ed relies more on static meshes. What Komag doesn't mention afaik is that you can snap single corners of brushes to the grid (after rotating etc.) by selecting one corner in vertex edit mode and pressing Alt+RMB. I made a lot of complicated things with the (de)intersect buttons (which allow you to carve out - already built - added or subtracted brushes out of the builder brush) to make diagonal brushes before I realised that it is so much easier. Furthermore I'd try to avoid brush sizes below grid size 8, just to make things more clear and clean. Oh, and of course brushes should not overlap. You can see some of my early faults some pages back in the newbie thread, with a lot of helpful answers from the experts around here. Ah, one more thing: Take the advice to set all surfaces to "Don't cast shadows" seriously since brush shadows eat a lot of performance. Instead I have switched to BF-blanked (e.g. not rendered) static meshes to cast the shadows instead. See also the static mesh sharing platform.

Second: Navigation-Mesh. When adding static meshes former ISA member Krypt suggested to take out the "Add to/Subtract from Navmesh" properties in the browser (you have to do it only once per static mesh) and subtract the space they block via nav mesh subtraction volumes (like you create around the barrel racks in the tutorial). Otherwise the nav mesh would be adjusted to the rather complex static meshes themselves and the whole thing will be complicated and the building times incredibly long. See the Fleshworks Wiki for an introduction about this issue. Oh, and of course the original missions.

Just my two cents. Welcome to the community and have a lot of fun with T3Ed. At least I have it and my only problem is that I have too many FM concept ideas than time. :p

Judith on 10/5/2008 at 09:37

---

Level size is dictated by overall number of properties. It means properties used in static meshes, objects from actor class, etc. So, it's wise for example not to make everything interactive (frobable, pickable, etc.). Static meshes in most places and just really useful things from actor class. The same goes for npcs, they need a lot of properties, so overpopulating your level might be a bad idea, if you plan some bigger area.

As it goes for performance, the biggest problem is lightning. When you have more than 6 omni lights (shadowcasting or not) per scene, the framerate goes down. You can partially solve this problem by increasing MaxLightCount cap in your Level properties -> ZoneInfo. Yet bear in mind that most of FMs fans don't have high performance PC's, so increase this limit if you need but try not to exceed 10 lights per scene.

Overlapping lights is also a bad idea or one big light touching many high-polycount objects (use "lights that touch too many objects" option in your 3d view window: stick to green and the orange, try to eliminate the red ones). If you really need a lot of small lights here and there, use vertex lighting: it's very efficient and having like 20 of them per scene is not a big deal. The only drawback is, that they don't affect the normalmaps. try using them as a subtle emphasis of a scene (overall color theme for example), rather than main light source, otherwise your textures will look flat.

And last but not least, if you want to make some custom content in the future, you'll need 3dsmax 5.1 There's no way to make new texture definitions and static meshes without this thingy. Ok, well, the textures are not such a problem, you can make your own and then ask me, Ziemanskye, <strike>Beleg</strike> :( or a few others to make the matlib definition for you. You will need to send us those textures though (via sendspace.com or such services, for example).

Judith on 10/5/2008 at 11:50

---

Sorry to hear that... No, I use AmbientVertex lights for decorative purposes (highlighting or tinting static meshes for example, as I did in Unknown Temple Demo) <strike>and I doubt i could serve as sunlight. Generally any light touching many objects is bad, even a vertex one. I'd use ambient brightness level property instead</strike>.

Oh wait, they do not show up as "lights that touch too many objects" at all, so that may be a good idea too: dark cellar for example and daylight outside, made with a few of these lights set up with maximum radius and a proper brightness :)

Ziemanskye on 10/5/2008 at 19:44

---

You can just use the "Tint" property to recolour static meshes too. It's a bit heavy handed though, so sometimes just using vertex lights is a good idea instead though - I used quite a few of them in Schism though, for highlighting the edges of things mostly, or for when normal maps didn't feel all that appropriate, like bright lights on soft wood and such.

Judith on 15/5/2008 at 19:33

---

Actually, vertex lightning tends to look strangely when the radius is below something like 100-120, lighning up static meshes and barely affecting the bsp - that's why I use them for some small decoration only.

But getting back to the topic, one thing just crossed my mind about scripting. If you have a large map opened and you want to open/save/compile scripts, you may easily get some Viktoria error (due to the lack of RAM maybe? :confused:). Prepare some one small room map instead and test your scripts there. I do not recommend saving your scripts in a separate folder, because if anything goes wrong while saving/compiling scripts, you'll have them thrown in the root folder anyway. Instead, add a prefix to your scripts, e.g. indicating in which map you put them in, like Cas1_GarrettEntersTheRoom. It will let you keep all things nice and tidy, even if something goes wrong.