Upspring 1.54
Moderator: Moderators
I apologize for my aggressive behaviour when I should've filed a normal bug report, I was angered by bugs.
I have had it happen quite often that pieces end up rotated and sometimes mirrored in the s3o in some way. The model that is saved doesn't match the model that is displayed. If I load the s3o with Upspring again it shows the same errors that Spring does with the s3o. This tends to happen more often with complex hierarchies, especially when I do bipeds. I often mirror the limbs by making a copy, scaling it by -1 in X direction and flipping its polygons. The incorrectly rotated pieces int he s3o I uploaded were built like that.
In this case after I saved the s3o for the first time and reloaded it the affected limbs had their Z and Y axis flipped I think. Either way, enterring rotation values would result in the rotation text fields containing values like 00#inf and other strings composed of a few digits, a # and letters. No, wait, I think first I tried to rotate around X by 90° but instead x reverted to 0 and Y and Z were rotated by 180°. Either way, it was some completely strange behaviour.
This happened with both 1.54 and 1.43. I almost consider it normal now that Upspring corrupts the model in one way or another and that I have to fix it in additional passes but this time I couldn't find ANY way to fix it.
The uploaded model will ignore scaling of -1 when saving, any mirrored pieces get drawn as mirrored by Upspring but end up unmirrored in any s3o I save.
All models I make are made in Blender, the root piece is always rotated 270° around the x axis (because of the different up axis) and scaled up by a large factor (like 16) after import. I use objs to assemble the model, one piece per obj (since objs always end up as one piece no matter how many objects there were before export, no idea which program causes that) and then move them into their places (the origin is placed where it should end up in Blender already).
EDIT: Also when I assemble the model the "insert object from file" dialog always defaults to s3o in 1.54, in 1.43 it used to default to the last filetype used so when I'm loading 10 pieces I don't have to tell it that I'm looking for an obj each time.
EDIT2: Oh and a minor bug that's been annoying me for ages is that if you make a new model, create an empty root object and insert an object from file that object isn't displayed in the parts list until you create another empty object.
I have had it happen quite often that pieces end up rotated and sometimes mirrored in the s3o in some way. The model that is saved doesn't match the model that is displayed. If I load the s3o with Upspring again it shows the same errors that Spring does with the s3o. This tends to happen more often with complex hierarchies, especially when I do bipeds. I often mirror the limbs by making a copy, scaling it by -1 in X direction and flipping its polygons. The incorrectly rotated pieces int he s3o I uploaded were built like that.
In this case after I saved the s3o for the first time and reloaded it the affected limbs had their Z and Y axis flipped I think. Either way, enterring rotation values would result in the rotation text fields containing values like 00#inf and other strings composed of a few digits, a # and letters. No, wait, I think first I tried to rotate around X by 90° but instead x reverted to 0 and Y and Z were rotated by 180°. Either way, it was some completely strange behaviour.
This happened with both 1.54 and 1.43. I almost consider it normal now that Upspring corrupts the model in one way or another and that I have to fix it in additional passes but this time I couldn't find ANY way to fix it.
The uploaded model will ignore scaling of -1 when saving, any mirrored pieces get drawn as mirrored by Upspring but end up unmirrored in any s3o I save.
All models I make are made in Blender, the root piece is always rotated 270° around the x axis (because of the different up axis) and scaled up by a large factor (like 16) after import. I use objs to assemble the model, one piece per obj (since objs always end up as one piece no matter how many objects there were before export, no idea which program causes that) and then move them into their places (the origin is placed where it should end up in Blender already).
EDIT: Also when I assemble the model the "insert object from file" dialog always defaults to s3o in 1.54, in 1.43 it used to default to the last filetype used so when I'm loading 10 pieces I don't have to tell it that I'm looking for an obj each time.
EDIT2: Oh and a minor bug that's been annoying me for ages is that if you make a new model, create an empty root object and insert an object from file that object isn't displayed in the parts list until you create another empty object.
Click, W, double-click. I know it's annoying if you have like 20+ pieces. You could try 3ds, saves you some work.EDIT: Also when I assemble the model the "insert object from file" dialog always defaults to s3o in 1.54, in 1.43 it used to default to the last filetype used so when I'm loading 10 pieces I don't have to tell it that I'm looking for an obj each time.
Actually you only have to move the camera once so it updates. But it is annoying. Furthermore how about assinging the pieces a default name, like filename (without extension).EDIT2: Oh and a minor bug that's been annoying me for ages is that if you make a new model, create an empty root object and insert an object from file that object isn't displayed in the parts list until you create another empty object.
edit:
About the mirror problems, could it be blender?
The normals seem to be wrong too. At least when I turn cull faces on in upspring the mirrored parts look all like they have inverted normals.
PS: This has nothing to do with the issue but one side of the sword blade should be flipped on the UV map so both sides match each other.
No need to get all nice and formal and stuff..I apologize for my aggressive behaviour when I should've filed a normal bug report, I was angered by bugs.
Anyway, if I mirror an object using X scale=-1, then it shows up inverted until I press apply transform (Apply transform automatically flips them when you have used a scale < 0). During the whole time, the normals will be untouched (but mirrored like they should) and showing up fine when I enable "render vertex normals".
So I don't see any problem. If there was, Argh would probably have written another one of his lengthy posts as well

- Guessmyname
- Posts: 3301
- Joined: 28 Apr 2005, 21:07
Okay, sorry for the late reply, I was on vacation...
It seems to me that Upspring is more likely to have saving issues the more complex transformations are within one branch of the hierarchy. If I do all the rotating and scaling before I parent the objects to each other, apply transforms and then start parenting them it seems to work fine, at least I got the problematic model to work that way.
It seems to me that Upspring is more likely to have saving issues the more complex transformations are within one branch of the hierarchy. If I do all the rotating and scaling before I parent the objects to each other, apply transforms and then start parenting them it seems to work fine, at least I got the problematic model to work that way.
Dump this in a .lua file in scripts/plugins (name doesnt matter)
I'll put this in the new version, but I'm waiting for some linux code before i release it.
Doesn't register an undo operation though, i'll fix that for next version too.

I'll put this in the new version, but I'm waiting for some linux code before i release it.
Code: Select all
-- Adds 2 menu items to the object menu
local function ApplyTransform (rotation, scaling, position)
local objects = upsGetModel():GetSelectedObjects()
for i=0,#objects-1 do
objects[i]:ApplyTransform(rotation,scaling,position);
end
end
function menuObject_ApplyTransform_All()
ApplyTransform(true, true, true);
end
function menuObject_ApplyTransform_RotScale()
ApplyTransform(true, true, false)
end
upsAddMenuItem ("Object/Apply transform/Rotation + Scaling + Position", "menuObject_ApplyTransform_All");
upsAddMenuItem ("Object/Apply transform/Rotation + Scaling", "menuObject_ApplyTransform_RotScale");
I can see the model is weird, but that doesnt tell me anything... the damage has been done before thatFor an example of when it fails, try the file I gave you.

-
- MC: Legacy & Spring 1944 Developer
- Posts: 1948
- Joined: 21 Sep 2004, 08:25
Hi, I don't know if this has been addressed before, but I still can not get Upspring to load UV Co-Ordinates.
I don't know how to explain it, other than to give directions to duplicate the problem. So here goes!
1. Open up any .S3O or .3DO model (if .3do, convert to .s3o and save)
2. Select "Export model for uv mapping" and export it.
3. UV map it.
4. Select "Import UV coordinates from model" and import new uv coordinates from uv mapped model.
5. Select "Show UV mapping"
6. Observe that no UV map was infact loaded.
It used to be that this problem rarely occured (several versions ago). Now no matter what I do I can't get uv coordinates to load. I use Ultimate Unwrap 3D, and I've tried both .obj and .3ds to do this. Also, I can load the entire model itself with Upspring (file>load model) and the UV co-ordinates show up fine. its just when trying to import uv coordinates to place them onto the spring model that they fuck up.
I don't know how to explain it, other than to give directions to duplicate the problem. So here goes!
1. Open up any .S3O or .3DO model (if .3do, convert to .s3o and save)
2. Select "Export model for uv mapping" and export it.
3. UV map it.
4. Select "Import UV coordinates from model" and import new uv coordinates from uv mapped model.
5. Select "Show UV mapping"
6. Observe that no UV map was infact loaded.
It used to be that this problem rarely occured (several versions ago). Now no matter what I do I can't get uv coordinates to load. I use Ultimate Unwrap 3D, and I've tried both .obj and .3ds to do this. Also, I can load the entire model itself with Upspring (file>load model) and the UV co-ordinates show up fine. its just when trying to import uv coordinates to place them onto the spring model that they fuck up.