Exporting vertex normals?

mixeh

Hey all,

I'm currently just messing around with getting a detailed tree inside UDK, I've used slide normal thief (I'm not sure if I've done that right in the first place - but looks okay) and I'm bringing it into UDK. As for the problem, I'll let the image do the talking:

EDIT: I'm finding that my vertex normals only work on my tree from the top view when I import into UDK from max.



in 3DS max I can rotate around the object and it will give me nice lighting based off a sphere I used to steal the normals from. But in UDK the lighting is static, it won't move with the viewer.

My export from max settings are standard fbx settings, with tangents and bi normals ticked, and split vertex normals ticked.

My import settings in UDK are standard with "explicit normals" ticked.

Eric Chadwick

Hard to tell from your screenshots and description just what is happening. Can you turn on the vertex normal display in both apps?

In Max you do this by adding an Edit Normals modifier, and I think there's a menu choice in the UDK viewer for this.

First off, the lighting doesn't look all that different between the two apps. Most of the top is lit, most of the bottom is not. Can you post an animated gif or mov with the light moving?

Second, those look like individual polygons for each leaf. This is the wrong way to do trees for a real-time 3d game, it's way too many vertices. What is your triangle count? You'll want more of an approach like this.

Jonathan

Are you trying to sphericalize your mesh normals?

As Eric said, a picture showing vertex normals (Max and UDK both have this option) would be helpful. I could write a quick Maxscript for you and show you how you'd do this if you'd like to know.

Thanks,

mixeh

Thanks guys. Forgive my noobness.

I checked the normals using the edit normals modifier, and they look fine. I'm stupid, sorry guys I thought how the light moves in 3DS Max, was how it moves in UDK, but durrr thats because the light moves with you in 3ds max viewport. I don't know if you get what I mean or not, either way just know that I understand it haha . If iI move around a light in UDK the normals are working fine, however I don't like how the planes turn REALLY DARK furthest away from the light, be could if you could limit this.

Eric the tree is ~ 9,500 tris. I just made it for a test, not to be used realtime, however I am curious as to why this wouldn't be acceptable in a game engine? I understand obviously you could cut this buy 99.9% using big planes, but aren't game engines cable of handling this sort of stuff nowadays, especially if there's only 1/2 in a scene? I know this is a pretty big change of subject, but I thought it was mainly texture size we had to worry about for next gen stuff nowadays?

Eric Chadwick

Triangle count per asset depends on many things, but in general if you're making a forest for a PC game, the trees are in the range of 900-2000 triangles, with 2000 reserved for the largest trees. If you're making a game for a portable like the iPhone or 3DS, then it's going to be a lot lot less, like 150 tris or less. Depends.

Jonathan

There are several things you'd probably want to keep in mind,

-small triangles on screen bloat the number of pixel quads needed to render the mesh, so you're hurting pixel shader performance there,

-a lot of triangles increases transform costs on the CPU side, eat up memory, etc.

-if you use lower triangle, larger "quads" for your trees, you're going to increase oversampling, even with alpha tests, as quad after quad will be rendered, the pixels that fail the opacity test will be "turned off"

so of course, what's "best" is what you're working on and what your engine does or does not do well (i.e.-traditional forward rendering and the amount of render passes vs deferred rendering, dynamic vs static shadows, the amount of shadow cascades, hierarchical Z pixel culling, etc.)

But long story short, yes, I'd say your construction method is a little unorthodox, but if it runs it runs.