Something in "recalculate vertex normals" corrects this problem. I don't know why, either- it looks fine in UpSpring, but in UpSpring, the light is moving with the camera, so I suspect it's hiding the problem, which I strongly suspect is being caused when the model is being imported.
If you make a 3DS mesh of a simple sphere, and then bring it into UpSpring, and just export it to whatever, then it is *always* screwed up. If you do "recalculate vertex normals", then it quits doing this, but it also removes all the verts that we need for nice, sharp edges and a lack of artifacts from shading.
I've tried exporting from 4 different pieces of software: LithUnwrap, Rhino3D 3.0, Milkshape3D, and Wings. I've tried OBJ imports (not that I want to use OBJ) and it's actually worse... OBJ models do not have proper normals on import, and must use "recalculate vertex normals" to display at all correctly.
All had the same result. It's actually easiest to see this problem if you use a simple texture and turn the shadows off, but it's clearly reversing the X axis- and only that axis. Everything else is perfect
Here's a quick proof. Trust me, it did this every time, with every model tested- and it's also just as clearly something reversing the X-axis of the normals, because at certain angles the models look good, if you're not looking at the shadows, or another model nearby providing contrast. It really did take me a second to see this clearly the first time, since the shadows on this map (Tropical) are mainly along the X axis.
Whoa... here's with shadows on. The light is obviously coming from an impossible, inverted direction. It's not inverted on the Y or Z, as you can see- just the X, where that pinpoint sun helps us clearly see the problem.
This has gotta be a single math error in the import code, I'm guessing. Unless you tell UpSpring to "recalculate vertex normals", it doesn't seem to actually *do* anything with the normals.
I had a weird thought... I don't suppose that this might be being caused by whatever code you changed so that the orientation of an object in UpSpring matches the orientation/mirroring of Spring? That would involve normal translation, surely. Just a thought.
They look fine in UpSpring... but bring 'em into Spring... and:
As you can see very clearly with shadows on, the light is inverted from the actual direction the sun is shining. That's what's wrong here. The Y-direction lighting is right (otherwise, these objects would be all dark, in this top-down shot), the Z-direction light is right (otherwise, we would see the top edges in this shot getting more light than the bottoms)... it's the light from the x-axis that is wrong. And it's unique to these models- older UpSpring stuff is fine, 3DOs are fine. Do you want a quick mini-mod, so you don't have to bother attaching a saved S3O to a unit and can see what I mean immediately? I could build a tester really quick-like.
And no, I don't mean merged/non-merged edges, or stuff like seams. Those are all a modeler's problem, don't worry about them- the sphere has one because I didn't bother doing a good job with the uvmap.
- Fixed wrong normals in X-direction for exported S3O models
- Undo/redo support + History viewer (Called Undo buffer viewer)
- Lighting unlockable from camera
- Fixed weird lighting when using untextured solid rendering
- Fixed "add empty"
- Fixed and improved "Set S3O texture dir"
- 3DS smoothing groups are used when 3DS files are imported.
Maestro: If you're reading this, I seem to have lost your latest PDF, and I'm not sure if the one in 1.43 is the newest, so thats why its not included currently
Last edited by jcnossen on 16 Mar 2007, 02:54, edited 1 time in total.
Its almost like its placing the shading on the faces but doesn't realize the traingle perspective relative to the light source and therefor those faces are not actually aligned the direction they should. I mean if you look closely it sees the faces on the left of the object as if rotated them 90├é┬║ off kilter, and the faces nearest to the light source are rendered completely ass-backwards. The darkest gradient should be away from the light source, not nearest it.
I'm only guessing here, but could the bug be in Spring's rendering engine and not in Upswing?
I'm going to have to export-->repair-->re-import quite a few models.
But... it's going to be soooooo worth it.
BEFORE: crappy welding issues making models look badly shaded and ugly.
AFTER: clean cuts, sharp edges, smooth curves! Even on this old thing, which I'll be the first to say has some fairly nasty flaws as a model, the difference is immediate.
The final test... is a FPS test, to make sure that this didn't make things render horribly slow or whatever. I very much doubt it, but we are processing quite a few more verts per model with this, so if you're making a really performance-based mod like NanoBlobs, you're going to want to weld completely whereever you can get away with it.
Users browsing this forum: No registered users and 0 guests
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot post attachments in this forum