"clean" topology?
polycounter lvl 8
hey ive been wondering what this "clean" topology everyone has been talking about is.
So far every time i have made a low-poly model for realtime use, ive followed a simple optimization plan of having every single vertice commit to the silhouette of the model in some way (basically, no verts on straight edges)
sometimes this forces me to have elongated polygons on my models, which i have gotten the impression here that is a bad thing.
The thing is i've never had any problems with long polygons or "bad" topologies.
heres an example i made to illustrate my point:
the RIS rail is just an example, so dont get caught in explaining the best way to do RIS rails, i know them all.
Like i said i've never had any problems with "bad" topology but im just wondering if there are hidden downsides or something, since from what i've read here everyone seems to be happy to waste a few extra polygons to keep the mesh clean..
So far every time i have made a low-poly model for realtime use, ive followed a simple optimization plan of having every single vertice commit to the silhouette of the model in some way (basically, no verts on straight edges)
sometimes this forces me to have elongated polygons on my models, which i have gotten the impression here that is a bad thing.
The thing is i've never had any problems with long polygons or "bad" topologies.
heres an example i made to illustrate my point:
the RIS rail is just an example, so dont get caught in explaining the best way to do RIS rails, i know them all.
Like i said i've never had any problems with "bad" topology but im just wondering if there are hidden downsides or something, since from what i've read here everyone seems to be happy to waste a few extra polygons to keep the mesh clean..
Replies
I'd advise actually having the top bits as floating geometry for most use cases, if this is small.
im not really sure why people even use UDK.. seems like CE3 is superior in pretty much everyting, especially after the latest patch.
except maybe performance, but high performance low visuals will soon be history anyway.
So I wouldn't be surprised if the latter might even be better, or even if you sort of zig-zagged them together (each rail come down to 1 vert each instead of two, centered between the verts you have now).
Unless butchering your model is to save a couple of hundred/thousand vertices in a very tight budget, 56 isn't going to be something anyone notices.
stuff adds up fast with large models.
also i realize the examples are really extreme, but i just made them so everyone is clear about what i meant.
Sandro: When i optimize my models, i do it at the very end, meaning i dont really work with them after that, except for maybe UV mapping..
Also, considering how simple this object looks ... why don't you save yourself all that hassle and and simply split off the tiny pieces from the long beam ?
oh my
Well, it might be the end for you, but for your asset it's hardly so. Model has to be uv mapped and baked with as little smoothing groups as possible (spartan optimizations make this harder) It will be later passed down to animators for skinning and exported to engine. In engine shader artist might come up with material that relies on vertex normals for calculating certain effects.
If you are working on static env. assets and level artist relies heavily on vertex blending then you need to provide him with cleaner topology to make it work. Sometimes assets also get vertex-lit or use vertex channels to store ambient occlusion for example (or tons of other stuff as you often don't have luxury of allocating unique texture space for everything and reuse tiling textures and rely on vertex masks to make them look unique)
So, there are lots of different variables to consider when making optimizations.
also lloyd i'd appreaciate it if you explained why you think UDK stands a chance compared to CE, instead of just saying "oh my"
Oh come on stop being so defensive :P
You never explained why Cry Engine 3 is superior in almost any way either.
edit: some reason why i think ce3 is better than UDK:
no lightmaps, everything done dynamically.
best skin shader out-of-the-box i've seen in any engine.
in-engine tools like flowgraph which enable you to do pretty much anything you want without knowing any c++
full 24 hour TOD editor with more parameters than anyone will ever need.
dynamic destruction system, and extremely easy to set-up prebroken objects in 3ds max or whatever you use..
thats just a start, i cant bother typing every single feature..
it can be argued per situation what is better pre-baked lighting with Global illumination, or a fully dynamic soultion.
probably because of the games made for each engine (UT and GOW vs C1 and C2)
The modern gpu fills triangle in 2x2 areas on the screen and if too many quads fall outside of the actual triangle it is trying to fill you're largely wasting your pixel fillrate. Ideally you want to find a middle ground between the two posted examples where you are quickly eliminating your triangles without getting too many super stretched ones.
You might also find yourself in a game scenario where fillrate is not an issue at all but your hardware is choking on vertice counts which will lead you to prefer the first example.
So if your a intermediate user(with UE3 or CE3), you’re more likely to produce a better scene in CE3 because of how simple they made cry engine to create a realistic scene. However, if we compare an experienced pro user of CE3 and UE3, UE3 will definitely come out on top.
As far as the Cry vs UDK discussion, I've used both: Cry was super buggy and would crash regularly doing relatively standard things, had overall less control in favor of dynamic solutions (not something I like and not better in terms of bang for buck quality by any means; it's easier and better looking than if you didn't know what you were doing in UDK, but dynamic lighting is not there yet).
If you want to throw an asset in and get something that looks pretty decent right away, without doing much of anything, then Cry is better. If you want more control, better tools, greater stability, and potentially more visual bang for the buck then UDK is the way to go imo. The notion that UDK is only for gamey fps' with small areas is completely false and shows a lack of knowledge about the sdk; UDK is highly customizable and could be used for pretty much any game.
UDK certainly has its shortcomings and can be fickle and demanding in certain ways, but it remains my sdk of choice for good reason.
What do you mean by dynamic solutions ?
Dynamic Lighting ? CE3 is far superior in this terms over UDK.
And no. It's not any secret that UDK do not handle big open areas very well. Especially with dynamic lighting only.
But to be honest it's worth mention that CE3 open areas support were dumped down because of poor terrain solution.
And at very end it's matter of baking lightmaps. In UDK it can take sevral hours depending on what you are doing. And at the end it may prove you have to bake again because of something.
In CE3 you do not have such problems.
Anyway. I'm never going back to engine to relies on lightmapping.
The CE3 sdk would crash ALL the time (enough so that after a week or two of solid work I abandoned a project because I felt I was just wasting my time), and I wasn't alone with that, but perhaps more recent releases are better about it.
Yes the lighting was what I primarily meant by 'dynamic solutions' but there's is also a difference in the approach toward other areas and the general mentality of the sdk, whether that be setting up some type of 'ecosystem' or day/night cycle, cry sort of has its own approach to things while UDK is more of a blank slate. This may go back to the op's idea that CE3 is 'living', but the difference I see is that for actual functionality UDK is much more about scripting while CE3 has its interpretation of things.
As for handling large environments, UDK used to be poor in that regard, but I wouldn't say so anymore. It's actually a very active area in its development right now; there are a lot of good features and approaches.
I will prefer baking lightmaps until dynamic lighting is actually good, which is a tall order to say the least.
And it is disadvantage because I have to rebuild them each time I change something. And I like change something a lot.
I disagree. Entirely. In UDK you will end up with ToD solution similiar to the one in CE3 anyway. Because I don't really see how diffrently Night-Day system may work, even on most fancy planet in universe.
And it depends what are you doing, but overall FreeSDK is much more modable than UDK. You can essentialy get rid of everything except engine, and do it from scratch. That insluding custom server if you want to make 100% online game.
And what do you mean by ecosystem ? You can setup in CE3 anything you want (game wise).
Still is. Yeah Landscape is very good. But try to setup large level without lightmapping and look at perfomance. Yeah. Now it probably wouldn't be much of the problem for Radeon 7850, but on my old GeForce 9600 it was. While CE3 had over 30 fps.
And for that matter I can't do large lightmapped levels in UDK. 12GB ram is not enough to build them.
I 100% disagree. Dynamic Lighting from CE3 look far better than Lightmaps in any engine. Not to mention CE3 do not need bazzylion of hd space nad RAM to look better.
What I can agree that for most of the time Editor tools are better in UDK. But at the end is not that big advantage.
Fact is, Unreal has rock solid position in the industry. Making SDK free was right step towards making Cryengine more widespread, but it's nowhere close to Unreal yet. Chances are on your next job you'll be using Unreal or some sort of modification of it. So, why neglect it? Learn both.
I would disagree. UDK's material editor alone is well worth dealing with some of the more obvious failings of the engine.
And on other hand if you know how really make shader you can write in HLSL anyway.
Writing raw HLSL using text based code is NOTHING like using the material editor even if the end result is a HLSL shader either way.
Just because i havent had a problem with it so far doesnt mean i wont in the future.
Some of the pointers in this thread have already made me realize that even though i didnt know, the long triangles were having a negative effect on my performance.
I find it very hard to measure microperformance of single assets, since the effect on the only performance indicator i know (FPS count) is extremely minimal with just a single asset and basically unmeasurable.
Now even though i havent dont so before, im now using my work in a larger scale production meaning the small performance losses of my seperate assets would build up, meaning that something that wasnt a problem before would become a problem.
anyways this thread has helped a lot and i can avoid those long triangles in the future.