Upspring 1.54
Moderator: Moderators
-
- MC: Legacy & Spring 1944 Developer
- Posts: 1948
- Joined: 21 Sep 2004, 08:25
Version 1.44:
http://user.supradigital.org/jcnossen/U ... r-1.44.exe
Changes for 1.44
----------------
- Rewritten the sloppy S3O texture handling. Hopefully this will result in less crashes (I think this was what spiked talked about)
- 3DS support rewritten using lib3ds
- A lot of internal refactoring of geometry code. This is needed to allow upspring to grow, but it might have caused a few bugs along the way.. Save your stuff a lot and please report all crashes.
Because of the internal changes the opk format is also changed, so < 1.44 files can't be loaded with this version.
http://user.supradigital.org/jcnossen/U ... r-1.44.exe
Changes for 1.44
----------------
- Rewritten the sloppy S3O texture handling. Hopefully this will result in less crashes (I think this was what spiked talked about)
- 3DS support rewritten using lib3ds
- A lot of internal refactoring of geometry code. This is needed to allow upspring to grow, but it might have caused a few bugs along the way.. Save your stuff a lot and please report all crashes.
Because of the internal changes the opk format is also changed, so < 1.44 files can't be loaded with this version.
Hmm. Did some tests... it still seems to be welding things it shouldn't. And all 3DS models now have to have "recalculate vertex normals" performed on them before they don't show up basically black. Which means, I think, that it's not reading vertex normals correctly from 3DS files... which also would explain why it's screwing up the welding.
Gonna have to find the old, old, OLD version of UpSpring, which didn't screw up my welding, and see if I can save it in .S3O just after import, then open it with the new version for editing pieces, and see what happens.
The turning/transform bugs are still present (i.e., turning a Piece past 180, or combining 180 with other turns, results in very odd problems).
The new "don't lose my position if cut/paste" rules, though, making it even easier to build a model from an import, and without all the annoying problems of having to re-move everything. If the problem with the normals was cured, this would be darn-near perfect- I can live with having to save between major turning transforms, but I'm finding it hard to live with mis-welded geometry. Overall, this is a very big improvement, it's just not getting stuff with big flat areas right, and "recalculate vertex normals" is making some rather strange stuff happen when I check it in Spring- surfaces that were getting nearly full-lit by the sun are now partially lit, and so forth, giving the models a less realistic look I think.
Gonna have to find the old, old, OLD version of UpSpring, which didn't screw up my welding, and see if I can save it in .S3O just after import, then open it with the new version for editing pieces, and see what happens.
The turning/transform bugs are still present (i.e., turning a Piece past 180, or combining 180 with other turns, results in very odd problems).
The new "don't lose my position if cut/paste" rules, though, making it even easier to build a model from an import, and without all the annoying problems of having to re-move everything. If the problem with the normals was cured, this would be darn-near perfect- I can live with having to save between major turning transforms, but I'm finding it hard to live with mis-welded geometry. Overall, this is a very big improvement, it's just not getting stuff with big flat areas right, and "recalculate vertex normals" is making some rather strange stuff happen when I check it in Spring- surfaces that were getting nearly full-lit by the sun are now partially lit, and so forth, giving the models a less realistic look I think.
Can you test:
UpspringInstaller-1.45 WIP
Its work in progress.. I've removed all automatic mesh optimization, and added normal-checking for the manual optimization. You'll have to select optimize in the edit menu after loading from formats such as 3DS and OBJ
It has undo/redo support that is currently very slow during moving/rotating stuff because of a design flaw.
Also please keep in mind that 3DS doesnt actually contain normals, it only contains smoothing groups, so it only loads normals(calculated from smoothing groups) when importing, and doesn't store them.
UpspringInstaller-1.45 WIP
Its work in progress.. I've removed all automatic mesh optimization, and added normal-checking for the manual optimization. You'll have to select optimize in the edit menu after loading from formats such as 3DS and OBJ
It has undo/redo support that is currently very slow during moving/rotating stuff because of a design flaw.
Those are not bugs, its just converting between different forms of representing the same transformation.The turning/transform bugs are still present (i.e., turning a Piece past 180, or combining 180 with other turns, results in very odd problems).
Also please keep in mind that 3DS doesnt actually contain normals, it only contains smoothing groups, so it only loads normals(calculated from smoothing groups) when importing, and doesn't store them.
Well, on the one hand, now I can have models with razor-sharp edges again. Bravo.
But... that's the only good part.
After running a few tests, here are some definite results:
1. The smoothing groups are not being read from the model correctly- the resulting normals appear to all face straight up (+y, I guess) instead of their correct vectors.
If you're reading the normals from the smoothing groups, then I dunno what, exactly, is going wrong, but I end up with models that are "reflecting" light from above, but not from the sides. They look extremely weird in Spring when sitting next to everything else, because the lighting angle is obviously very, very wrong.
I can send you some screenshots if you need them to see what's happening. Just looking at the "view normals" view, I see some extremely strange things- normals that should all be facing straight out, because I darn well know I used a planar map... are instead facing at strange angles.
2. The texture location isn't being saved in the model any more. Caused a crash the first time, now I'm aware of it and can work around it, but it's still a bug.
3. What, exactly, does "Recalculate vertex normals" actually do? And why is hosing my welding completely, without fail, every time? It's like it just randomly re-welds stuff on its own, without checking for prior welding, and it doesn't seem to reference the normals generated during uvmapping, or anything else that makes sense. I'd use it if it ever did anything I wanted it to do, but it just seems to weld everything together. Which is not ideal.
Soooo...
I can have models that welded together, even when they shouldn't be, and they'll be lit correctly but have horrible welding flaws and no sharp edges.
I can have models with sharp edges, no welding, and that render incorrectly in the gameworld, but look less screwed-up in UpSpring because the lightsource travels with the camera, I suspect. Or maybe UpSpring is rendering differently from Spring again.
Or I can optimize the models, which doesn't seem to actually do anything, so far as I can see. I was hoping to see my welding re-appear, but without new welding appearing, but instead my imported models look like they're completely unwelded.
No matter which road I take, I have a model that looks terrible. This version rocks in many ways, JC, but there's something very fundamentally wrong with the 3DS import code still.
But... that's the only good part.
After running a few tests, here are some definite results:
1. The smoothing groups are not being read from the model correctly- the resulting normals appear to all face straight up (+y, I guess) instead of their correct vectors.
If you're reading the normals from the smoothing groups, then I dunno what, exactly, is going wrong, but I end up with models that are "reflecting" light from above, but not from the sides. They look extremely weird in Spring when sitting next to everything else, because the lighting angle is obviously very, very wrong.
I can send you some screenshots if you need them to see what's happening. Just looking at the "view normals" view, I see some extremely strange things- normals that should all be facing straight out, because I darn well know I used a planar map... are instead facing at strange angles.
2. The texture location isn't being saved in the model any more. Caused a crash the first time, now I'm aware of it and can work around it, but it's still a bug.
3. What, exactly, does "Recalculate vertex normals" actually do? And why is hosing my welding completely, without fail, every time? It's like it just randomly re-welds stuff on its own, without checking for prior welding, and it doesn't seem to reference the normals generated during uvmapping, or anything else that makes sense. I'd use it if it ever did anything I wanted it to do, but it just seems to weld everything together. Which is not ideal.
Soooo...
I can have models that welded together, even when they shouldn't be, and they'll be lit correctly but have horrible welding flaws and no sharp edges.
I can have models with sharp edges, no welding, and that render incorrectly in the gameworld, but look less screwed-up in UpSpring because the lightsource travels with the camera, I suspect. Or maybe UpSpring is rendering differently from Spring again.
Or I can optimize the models, which doesn't seem to actually do anything, so far as I can see. I was hoping to see my welding re-appear, but without new welding appearing, but instead my imported models look like they're completely unwelded.
No matter which road I take, I have a model that looks terrible. This version rocks in many ways, JC, but there's something very fundamentally wrong with the 3DS import code still.
Did another experiment. Checked UpSpring's recorded vertex normal positions and vectors on imported models, before applying any optimization. There was absolutely no change in the number of normals. The smoothing groups are clearly getting ignored for some reason, and the welding that is intended to happen isn't actually happening.
So, here's a segment of my model, just after using the manual optimization. Every vert you're looking at, right here, should be welded, except for the verts at the bottom edge (we're looking at a foot here, and we want a nice, sharp edge on the bottom of the foot). However, this is what we see:

To confirm my theory that Recalculate Vertex Normals is really just welding every vertice that is close enough to a common neighbor, and should be called something more useful, like "Weld", I then performed that step. Yup, every single vert is welded, whether or not the model's previous internal data was calling for it:

So... yeah... the smoothing groups aren't ever being read. I dunno what's causing the weird lighting when in Spring, though. The shadows render correctly, so it's gotta be something wrong with the normals when the model is getting rendered that is causing this.
So, here's a segment of my model, just after using the manual optimization. Every vert you're looking at, right here, should be welded, except for the verts at the bottom edge (we're looking at a foot here, and we want a nice, sharp edge on the bottom of the foot). However, this is what we see:

To confirm my theory that Recalculate Vertex Normals is really just welding every vertice that is close enough to a common neighbor, and should be called something more useful, like "Weld", I then performed that step. Yup, every single vert is welded, whether or not the model's previous internal data was calling for it:

So... yeah... the smoothing groups aren't ever being read. I dunno what's causing the weird lighting when in Spring, though. The shadows render correctly, so it's gotta be something wrong with the normals when the model is getting rendered that is causing this.
http://user.supradigital.org/jcnossen/U ... %20WIP.exe
One last attempt, if this doesnt work then there must be something wrong on the exporting side, because I'm already using the standard 3ds library that everyone uses (lib3ds.sf.net). I'll have to implement manual smoothing group creation within upspring if this doesnt work.
Recalc vertex normals definitely works, that's why it causes what you call "welding" (not welding is the same as having vertices with different normals on the same position).
One last attempt, if this doesnt work then there must be something wrong on the exporting side, because I'm already using the standard 3ds library that everyone uses (lib3ds.sf.net). I'll have to implement manual smoothing group creation within upspring if this doesnt work.
Recalc vertex normals definitely works, that's why it causes what you call "welding" (not welding is the same as having vertices with different normals on the same position).
Can you explain that? I can't seem to duplicate the bug.2. The texture location isn't being saved in the model any more. Caused a crash the first time, now I'm aware of it and can work around it, but it's still a bug.
You've got it!!! Imports now work perfectly. All verts are being welded/not-welded just as they should be. I have sharp corners and smooth curves. Wonderful!
However, there's definitely a remaining problem on the export side.
Whatever's being used to determine the direction that light is coming from is inverted on the X axis. So models are lit properly on the Z and Y axis, but not on X. I hope that's an easy fix, because it's the only thing that's a showstopper- the difference in quality that is going to result from this version is going to be nothing short of amazing, if you can get that fixed.
As for the texture bug... when saving the final model, UpSpring is no longer recording the texture directory, and every time I open up the models, it says it "cannot find texture blahblah". I then have to manually re-acquire the texture. If I fail to do so and then save, the model's texture is left blank, resulting in a crash. Not a huge deal, but probably easily fixed. And yes, this even occurs if I've already fed it my default texture directory
Lastly... there's one more bug, and it's a crash bug, so I should probably report it... if you import 3DS models and attempt to "Add Empty", UpSpring crashes immediately after assigning a name and hitting "Ok". Happens every time.
However, there's definitely a remaining problem on the export side.
Whatever's being used to determine the direction that light is coming from is inverted on the X axis. So models are lit properly on the Z and Y axis, but not on X. I hope that's an easy fix, because it's the only thing that's a showstopper- the difference in quality that is going to result from this version is going to be nothing short of amazing, if you can get that fixed.
As for the texture bug... when saving the final model, UpSpring is no longer recording the texture directory, and every time I open up the models, it says it "cannot find texture blahblah". I then have to manually re-acquire the texture. If I fail to do so and then save, the model's texture is left blank, resulting in a crash. Not a huge deal, but probably easily fixed. And yes, this even occurs if I've already fed it my default texture directory

Lastly... there's one more bug, and it's a crash bug, so I should probably report it... if you import 3DS models and attempt to "Add Empty", UpSpring crashes immediately after assigning a name and hitting "Ok". Happens every time.
I have one model saved on which that happened, only I don't know how and I can't duplicate it. Any ideas?Whatever's being used to determine the direction that light is coming from is inverted on the X axis. So models are lit properly on the Z and Y axis, but not on X. I hope that's an easy fix, because it's the only thing that's a showstopper- the difference in quality that is going to result from this version is going to be nothing short of amazing, if you can get that fixed.
I updated
http://user.supradigital.org/jcnossen/U ... %20WIP.exe
with fixes for the crash on "add empty" and the texture path problems.
I think I'm going to add internal smoothing groups support at some point, just for completeness.Although there were some oddities as some of my smoothing settings were entirely ignored while others weren't... any chance on getting .obj smoothing group support too?