Hmm, here's an idea... maybe it's not reading the model's new X axis correctly, if you have to rotate it (does experiment).
Nope. That's not it. Dunno what's causing this.
Upspring 1.54
Moderator: Moderators
Ok... here's what's going on:
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.
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.
Uploaded the WIP version again :
http://user.supradigital.org/jcnossen/U ... %20WIP.exe
* Fixed weird lighting
* Undo/redo now working without slowness, also please notice the photoshop style history viewer :)
* Light unlockable from camera
But I still couldn't fix that normals bug, can you send me a not-working 3DS example.
http://user.supradigital.org/jcnossen/U ... %20WIP.exe
* Fixed weird lighting
* Undo/redo now working without slowness, also please notice the photoshop style history viewer :)
* Light unlockable from camera
But I still couldn't fix that normals bug, can you send me a not-working 3DS example.
Okie doke! The normals thing is the only major issue, then! I really like the configurable light, btw, although it'd be nice to specify a non-black level for ambient.
As for the normal thing... here ya go:
Click here to download two sample objects, in 3DS format. These objects are always shaded wrong, unless "recalculate vertex normals" is used.
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.
As for the normal thing... here ya go:
Click here to download two sample objects, in 3DS format. These objects are always shaded wrong, unless "recalculate vertex normals" is used.
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.
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.
Upspring 1.5
Ah everything is clear now, that was an easy fix actually!
http://user.supradigital.org/jcnossen/U ... er-1.5.exe
Complete changes for 1.5:
- 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
http://user.supradigital.org/jcnossen/U ... er-1.5.exe
Complete changes for 1.5:
- 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 only guessing here, but could the bug be in Spring's rendering engine and not in Upswing?
Time to get to WORK!
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.
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.
