Some words about 227 (and static meshes)

[Smirftsch]

This is some information about coming 227g.

I noticed this "problem" already with some of the testers, so to avoid that this "wrong idea" about 227g becomes a common mistake, here some words.

Although we have a lot of features and additions in 227g many people know from UE2. 227g is NOT UE2 and this is NO UE2 CONTEST.
Of course its quite normal and I understand that because of the known features a comparison with UE2 can't be completely avoided, but you need to realize that it is not UE2 and it never will be.

A good example for "misuse" are the static meshes. During the development time we made the static meshes work almost perfectly, but only almost. There are some Engine based limitations which we can't change without rewriting a lot of the base rendering system and that is (at least currently) entirely out of question, if even possible at all for our small team without me being allowed to share render sourcecode and that's very unlikely.
So static meshes were meant as expansion, as addition to bsp, to avoid a lot of problems especially with tricky bsp building but it was never meant to be and it can't be a full replacement for bsp like it is in >=UE2.
We fixed a lot of problems with bsp building and we reduced f.e. very much the appearance of bsp holes, but instead that this is appreciated people try to use now static meshes at any cost because they handle it like in UE2.
Of course avoids the use of static meshes a lot of problems in 227g too like in UE2, but the base rendering is still construed to bsp in 227g's UE1.
The answer for this example is to use bsp where it is possible and to use static meshes if necessary or if it makes sense. This will produce the best results in stability and performance (for the engine).

I'm sure there are quite a lot of other examples like these, so please, keep in mind that this is a fixed and extended UE1 engine and not a limited UE2. Of course we try to make it the best possible and if things can be improved we always try to do it, but there are limits.

The target was and is to make the game we all love the best possible, not to create a new engine or even game. Also the extensions were made to reach this target and not to become some UE2 alike although it can't be denied that a lot of ideas were taken over from modern games and of course UE2 too.

[Hellkeeper]

I figured this out after trying a few stuff with SMs



Too much is simply too much. This is an old engine.

[creavion]

Well, at least my beach map has to be finished with SMs as terrain pieces, even if I splitt them to very small pieces, no other way there, otherwise I can nearly rebuild the half map from ground up.
Is that railing there each one mesh?

[Hellkeeper]

Yes, each little column is a mesh.

As for the terrain, I guss you could still convert it to a brush and add/subtract it in a traditional way...

[creavion]

Yes, each little column is a mesh.

As for the terrain, I guss you could still convert it to a brush and add/subtract it in a traditional way...

I have build the Terrain out of Brush sheets and SMs have btw a limited amount of useable materials.

[Turboman.]

I figured this out after trying a few stuff with SMs[/URL]

Too much is simply too much. This is an old engine.

wow looking at the smoothness of each column, i'd say even ue2 wouldn't be able to handle that properly


Still, i've had almost no issues with staticmeshes, overall i'd say they're very good as they are. Ofcourse i'm not trying to pull of entire ue2 stuff with them, but with moderate usage i got a fairly bugfree (at least to me) result.

[Smirftsch]

lol, well, don't get me wrong. I never intended to say that our meshes are "bad". I only wanted to make clear that there are maybe some things which we just can't do or fix if you compare to UE2 f.e..
I want to avoid disappointments or wrong expectations. We are no high paid development team with dozens of professional members, we are just "some people from at home" like you, we have jobs, we have school, we have bills to pay and not unlimited free time.
Also we have the problem that it is only me with access to the sources.
Dots works his ass off to pre-build and work out many things and I'm building it in then. A lot of the new features are based on his work and that restriction means a multiple times more work as it could be if I'd be allowed to share at least parts.
Or take UTGLR, I'm sure Chris could make it a multiple times more efficient and extend it way better if he could work on the render.dll too.

I just wanted to make you aware about that, people seem to forget that we reached already fantastic things we never dreamed of.

[Hellkeeper]

I figured this out after trying a few stuff with SMs[/URL]

Too much is simply too much. This is an old engine.

wow looking at the smoothness of each column, i'd say even ue2 wouldn't be able to handle that properly

Actually, each column is 256 polys, which is a very low number of UE2 SMs. The main problem here is that the node count goes through the roof because just this staircase (and really, all there is is on the screenshot) features 86 columns, each with two small bsp prisms to link it to the ramps. One full ramp is already 178 brushes and 43 meshes, which means a maximum of  11 008 polys just for meshes on just this staircase and nothing else (the map is only a big empty cube with these stairs).
So yeah... The engine is not really suited for this.

However, this means we will be able to create decoration meshes on the fly with no converting or anything needed Textures will be adjustable as we will through brush conversions, and allt his also means less BSP cuts, less BSP artifacts and an overall more stable and flexible engine. I hope some great maps will take advantage of all this

[Mister_Prophet]

Hey, I'm just jazzed that you've got static meshes   ;D

[KeeperUTX]

The 227g version is server-side, right? That means that it gives more advantages to people that like servering (?)

[Smirftsch]

it's an update for both server and client.

[KeeperUTX]

(=Cool=)

[Dozey]

I found a problem with lighting on the static meshes. Even if I rebuild geometry and lighting problem don't want to leave and I've got dark static meshes. Okay I like Dark Match game type but I don't want to see this on my map that default brightness is about 170 points
It don't look very well.

[GreatEmerald]

Vertex lighting. You can't do anything about it, it's like that in every UE game.

[Hellkeeper]

I found a problem with lighting on the static meshes. Even if I rebuild geometry and lighting problem don't want to leave and I've got dark static meshes. Okay I like Dark Match game type but I don't want to see this on my map that default brightness is about 170 points
It don't look very well.

Lighting on Static Mesh and decorations are not calculated for each point on the surface and compiled into lightmaps as it is done with BSP. Light is calculated at each of the vertices of a polygon (each of the 3 points of  triangle), and then blended together.
So if everything is black, make sure you don't have all your vertices in a wall or in the floor. It might be useful to clip the mesh in half to have more vertices and thus more lighting definiton.

This gets me wondering : would it be possible to allow lightmap compilation for meshes ? UE2 allowed for imported custom lightmaps to be used on static meshes and this was pretty much the only way to have perfect lighting on static meshes; something like that might be nice if it's at all possible.

[KeeperUTX]

Whoa,wait!

what the cps is a static mesh?!

[Hellkeeper]

Whoa,wait!

what the cps is a static mesh?!

Just one the major features of 227.

[TheIronKnuckle]

I hope smeshes don't become the major focus of new maps. BSP has charm. Good to hear that you've done your best to reduce the chance of BSP errors! 

[Hellkeeper]

I hope smeshes don't become the major focus of new maps. BSP has charm.

As this topic demonstrates, SMs are good for improved and quick-made decoration. The engine itself is not powerful enough to display too many polygons, either SMs or BSP. Lighting on SMs is quite bad too. Most of the work will still be made with BSP, I think what will happen is that things that would have been made decoration actors will be made SMs instead (easier to do, easier to use).

[creavion]

I hope smeshes don't become the major focus of new maps. BSP has charm. Good to hear that you've done your best to reduce the chance of BSP errors! 

Ever tried to build a terrain map like my Kamah? Ever tried to remove over a period of around 5 weeks the most retarded bsp bugs? Have you ever testrun your map that much that you begin to hate it? I started that map with a lot of fun, ever keeping in mind, that nobody ever tried something like that before to such extend. It was the major reason why I was able to finish the map at all, I guess. At the end I was that sick of that map that I never played it again, after it was finished. Of course I could not remove any of the HOMs and ICHs... It was such a pain. Mental I smashed several mouses and keyboards and I cursed a lot near the end.
BSP should be actually only used for basic stuff. But reality looked different. Most mapper had to adapt their maps to the mood of the engine. (remove or change several construction because you are unable to remove the bsp bugs). Nowadays I look at my still bsp-buggy map and I have to say to myself: Seriously, was I crackbrained or anything that I tortured myself with something like that? And no you say please stick to bsp as much as possible? If you start to get serious with mapping (this means maps with a visual quality level like Revelation or Swanky), you will see you dont have to take care that much of bsp bugs anymore. You have to be crazy if you would still stick to bsp terrains or complex bsp constructions. I mean then you would have to love pain. Possible that this engine upgrade still relys to 99 % to cpu, but dots development beats epics UEngine 2 static meshes in many ways. They can be created without much worrying in the ed, they even can have smooth lighting (or you can set your materials to bsp lighting if you like), UNLIKE UEngine2. Alignment does not get lost, UNLIKE Uengine 2. Dots will lay the world at your feet with an absolutly user friendly static mesh system.

Yes, static meshes get only calculated over CPU, like I said, they EVER display - if set - detail textures and they are not able to display decals. Well, not YET, I would say. I will never forget those days last summer where static meshes were still only an idea.

[TheIronKnuckle]

Funnily enough I do love BSP based terrain I love the fact that you get to, and have to exercise fine control over every vertex.

I hate the actual doing of it though, takes forever XD

Your maps are ambitious, they would benefit from static meshes for sure. When I map, I personally want to avoid meshes at all cost. I prefer the low poly visual experience to a high poly one.

However, in the example map turboman posted up, I had to open up the editor before I realised that the whole map was essentially a static mesh I was fooled: I knew there were going to be smeshes in there, but I couldn't pick out where they were.
So I suppose you could say the fusion between BSP and static mesh is much less jarring in the old unreal engine than in its later incarnations, and to me that's a good and welcome thing.

Anyways, personally it boils down to this: I look at masterful use of BSP and think "I want to be able to do that", because I can see how they've done it and this gives me the urge to do it as well. I see how they've crammed in heaps of detail using amazing lighting, texture use and BSP alone, and I'm impressed.
Whereas when I see static meshes... sure, I can see that there's way more detail than is possible with BSP, but so what? I don't appreciate that the same EFFORT has been put into the map. I concede that to actually get that smesh, you have to have skills in an external 3d modelling program, and there's effort involved there. But once you get into the actual mapping, you just copy paste and manipulate smeshes over and over again.
It's a different style of mapping completely to BSP, and it's one which I find hard to appreciate.

When I look at a good looking BSP map I am blown away, and feel a real appreciation that sweat, blood and tears went into producing it. A good looking map or game means nothing to me, but a decent looking map built from BSP is something which I can understand, and have a deep respect for.

In any case, I see the addition of smeshes to 227 as a good thing, they allow for details which simply weren't possible before. But due to the 13 years of mapping for an engine that never had them, I doubt they'll completely take over. Trim, texture sinking and other such CSG trickery will still have their place.


I'm interested in the technical details though. There's talk of being able to make static meshes "on the fly". This would explain why I didn't immediately detect the smeshes on Turboman's test map. Am I right in assuming that you can make up a bunch of detail brushes, and instead of converting to semisolid as I usually do, I can just convert to a staticmesh? This could come in handy...

[creavion]

Well, nice if you like them, but sorry, then you dont have invested THAT amount of details like I have. Otherwise you would understand me. If you keep it unreal 1 - simple, well it might work. Not surprising at all.
Creating an Unreal 1 typical map would be for me nowaydays however only a matter of style, nostalgia, but definitely not for a more serious map in terms of visual aspects.

@copying of the same meshes: Thats just how it works nowadays. Pretty normal.
UT2004 mapper (and onwards) dont know it any different. Some of them who I know were shocked about the - for them - crappy Unreal Engine 1. Somebody wanted to make a cave for me, some time ago. I told him: Well, as mesh it is useless for me. I told him about the cylinder collision, the disappearing meshes, the retarded lighting (this all happened before 227g) and he was like "WTF are you mapping for?".
ATM I am about to start a project with some buddies, some of them are making additional static meshes, I will take care of the textures. We try to share the content as best as possible, both textures and static meshes. I still like to map for the oldies. I have never really liked UT2004 and it seems I am to old for UT3 .. lol. So why should we make our live any harder if the possibilities are given to make it easier?

With your way of thinking "bsp at all costs" you will be limited forever. Funny enough, that I say something like that, because I thought a long time ago like you, however I avoided meshes because of their uselessness (so happened before 227g as well). But things are different now.
Unreal Engine 1 is a relic from ancient times. BSP is limited as you might now and the 65536 nodes is ONLY one of the problems. I mean if you would create a hall with repeating architecture constructions, nowadays no problem at all. Once the static mesh is in the RAM, repeating him is not a big deal.



Edit: This is not meant to be insulting in any way. I just noticed it could be understood wrong.
I just mean, if you keep it simple, Unreal Engine is happy, as long as you dont start to build something more complex, then it starts to act weird.
Its like comparing a Redeemer Cube with extreme detail work. Its just not possible.

Or like:
"Man, its really hot today, this sucks."
"Whats your problem, dude? The weather is nice"
"My a**, have you worked all the day in the to warm office without air conditioner and a cold cola? No? Then STFU"

I'm interested in the technical details though. There's talk of being able to make static meshes "on the fly". This would explain why I didn't immediately detect the smeshes on Turboman's test map. Am I right in assuming that you can make up a bunch of detail brushes, and instead of converting to semisolid as I usually do, I can just convert to a staticmesh? This could come in handy...

Yes? Like I said, they can be easily created in the Ed as well. You could also prepare them in the Ed and then convert it as wavefront to any 3D modelling programm, edit them and import them back for example. What about .. you test it out yourself, I mean its not like you have to wait for 227h?
You  can use convert to static mesh as well to avoid (de)intersecting, so as some kind of tool if you want to see it on that way.

[Hellkeeper]

There's talk of being able to make static meshes "on the fly". This would explain why I didn't immediately detect the smeshes on Turboman's test map. Am I right in assuming that you can make up a bunch of detail brushes, and instead of converting to semisolid as I usually do, I can just convert to a staticmesh? This could come in handy...

Right-Click=>Convert=>To Static-Mesh. You can't make it easier

As someone who started mapping seriously with UT2004, I confirm that working with meshes is more copy/paste intensive And, in a way, less satisfying. BSP offers absolute control, but you find yourself limited by the engine itself as to polygons and performances. Then again, it's not impossible to do something nice with BSP only, even in an engine used to full mesh-made maps, but it takes a lot more time, creates more problems, is usually less detailed and overall, can be a pretty big waste of time and efforts. The ability to create your map from scratch in the editor with no other programm is what sells BSP to me. I like mapping because of UnrealEd and I like Unrealed because of mapping, I don't feel like creating a map in another program, and I don't feel like creating meshes in UED.

[creavion]

I could SWEAR I told Smirf long time he should please include a function to convert a static mesh in the mesh browser as well... but whatever.

BTW: Nice work, Hellkeeper. I am not sure if I have understood that now right, have you created that with bsp only or not?

[Hellkeeper]

It's all BSP and thanks.

I'm not sure I understood what you suggested to Smirftsch: the possibility to convert a Static mesh into... a regular mesh ?