- Site Map >
- Modding and Creation >
- Sims 3 Creation >
- Meshing >
- Milkshape 3D - ObjectTool V1.01, MS Plugins 4/22/2011
- Site Map >
- Modding and Creation >
- Sims 3 Creation >
- Meshing >
- Milkshape 3D - ObjectTool V1.01, MS Plugins 4/22/2011
#101
7th Jan 2010 at 11:47 PM
Last edited by Fire~ : 8th Jan 2010 at 1:21 AM.
Posts: 39
Hi Wes, uploaded a file from WA for you to look at.
Edit: you will not need the the relicSethStatue.zip as it seems to be ok to clone but i will leave if for now if you still want it? in my next post i uploaded a torch file from WA that has the same issue.
I pulled the Mlod and the Modl file and included the original file as well just in case you wanted to look at it as well?
I also included the Lighted table tiki torch file which is a base game file as it seems to be the problem file? it is one of two torch lamps from the base game, this one is a table lamp and the other not included here is a floor torch lamp, i will search out and clone another torch from WA to see if the problem persists?
Sorry i would have had it to you sooner but we are experiencing 17 year old know it alls at the moment.
Edit: you will not need the the relicSethStatue.zip as it seems to be ok to clone but i will leave if for now if you still want it? in my next post i uploaded a torch file from WA that has the same issue.
I pulled the Mlod and the Modl file and included the original file as well just in case you wanted to look at it as well?
I also included the Lighted table tiki torch file which is a base game file as it seems to be the problem file? it is one of two torch lamps from the base game, this one is a table lamp and the other not included here is a floor torch lamp, i will search out and clone another torch from WA to see if the problem persists?
Sorry i would have had it to you sooner but we are experiencing 17 year old know it alls at the moment.
Attached files:
relicSethStatue.zip (534.7 KB, 14 downloads) - View custom content | ||||||||||
0 01-07-10 15:33 Modl Original/ 11444 01-07-10 15:33 Modl Original/S3_01661233_08000001_767AADDB9E8F093B%%+MODL.model 0 01-07-10 15:33 Mlod Original/ 13352 01-07-10 15:33 Mlod Original/S3_01D10F34_08000000_767AADDB9E8F093B%%+MLOD.lod 650690 01-07-10 15:32 R_Fire_relicSethStatue.package -------- ------- 675486 5 files |
||||||||||
LightingTableTikiTorch Mlod Modl.zip (313.8 KB, 17 downloads) - View custom content | ||||||||||
0 01-07-10 03:34 Mlod1 Original/ 35032 01-07-10 03:33 Mlod1 Original/S3_01D10F34_00000000_B8D70A2D041CAECE%%+MLOD.lod 0 01-07-10 03:40 MODEL Original/ 20952 01-07-10 03:39 MODEL Original/S3_01661233_00000001_B8D70A2D041CAECE%%+MODL.model 391439 01-07-10 02:21 R_Fire_LightingTableTikiTorch.package -------- ------- 447423 5 files |
Advertisement
#102
8th Jan 2010 at 1:12 AM
Posts: 39
Yes the problem persists so far with the outside torch lamps, i tested with the World Adventures LightingFloorTorchAnubis which is an outside ground Torch lamp.
ERR: 160 vertex size specified exceeds 64 limit.
Group Count = 3
Group 0: Faces = 2, Vertices = 4, Matl_block = 1
Group 1: Faces = 120, Vertices = 240, Matl_block = 6
Group 2: Faces = 988, Vertices = 809, Matl_block = 12
Total faces = 1110, Total Vertices = 1053
Here is the full file with Mlod and Modl file attached
ERR: 160 vertex size specified exceeds 64 limit.
Group Count = 3
Group 0: Faces = 2, Vertices = 4, Matl_block = 1
Group 1: Faces = 120, Vertices = 240, Matl_block = 6
Group 2: Faces = 988, Vertices = 809, Matl_block = 12
Total faces = 1110, Total Vertices = 1053
Here is the full file with Mlod and Modl file attached
Attached files:
LightingFloorTorchAnubis.zip (787.6 KB, 13 downloads) - View custom content | ||||||||||
0 01-07-10 17:05 Modl 1 Original/ 32196 01-07-10 17:04 Modl 1 Original/S3_01661233_08000001_EC9F691F1CC7B2BA%%+MODL.model 0 01-07-10 17:04 Mlod 1 Original/ 65100 01-07-10 17:04 Mlod 1 Original/S3_01D10F34_08000000_EC9F691F1CC7B2BA%%+MLOD.lod 1003635 01-07-10 17:03 R_Fire_LightingFloorTorchAnubis.package -------- ------- 1100931 5 files |
#103
8th Jan 2010 at 4:57 AM
Posts: 2,832
Thanks: 6616 in 20 Posts
Thanks... I looked at this, and it has uncompressed floats in group01. We don't have a spec for this... granted, I did write the spec we have, but this does not fit in it. I can get past the size issue easily, but most of the content of that group does not decode, because it is written for the compressed types found in all the other modl/mlod chunks.
I will add this to the growing collection of mysterious oddities, to be worked on in my "spare" time.
If you like to say what you think, be sure you know which to do first.
I will add this to the growing collection of mysterious oddities, to be worked on in my "spare" time.
If you like to say what you think, be sure you know which to do first.
#104
8th Jan 2010 at 6:15 AM
Posts: 39
Thank you Wes,
I will look forward to any mysterious oddities you may correct? in the future.
I will look forward to any mysterious oddities you may correct? in the future.
Alchemist
#105
8th Jan 2010 at 11:30 AM
Posts: 2,932
Thanks: 15582 in 28 Posts
This is probably a stupid question, but does this mean there is a risk that people with WA would have game problems with the object if someone using the base game only cloned this item and made something for the game from it?
I ask because (as you probably know) that Tiki Torch MLOD has only 2 groups when cloned from the base game but 3 groups when cloned by someone with WA (and 2 vs 1 group for the MODL). The number of faces and vertices reported by the cloner info button isn't the same either. There's no problem decompiling the one pulled out if all you have is the base game installed...you can change its mesh/recompile etc. and it looks fine in the base game...would it still be ok for everyone who had WA?
I ask because (as you probably know) that Tiki Torch MLOD has only 2 groups when cloned from the base game but 3 groups when cloned by someone with WA (and 2 vs 1 group for the MODL). The number of faces and vertices reported by the cloner info button isn't the same either. There's no problem decompiling the one pulled out if all you have is the base game installed...you can change its mesh/recompile etc. and it looks fine in the base game...would it still be ok for everyone who had WA?
#106
8th Jan 2010 at 2:26 PM
Posts: 39
Orangemittens, That is not a dumb question at all!
in fact it has me wondering why i cannot go back and clone this from base game and not the updated version through World Adventures? Wonder if Object cloner can be changed to do this as i seem to not be able to clone the base game versioned tiki lamp no matter what i try?
Also it seems as if they changed something in the torch lamps so they could use them in WA?
so now all torch lamps react differently?
in fact it has me wondering why i cannot go back and clone this from base game and not the updated version through World Adventures? Wonder if Object cloner can be changed to do this as i seem to not be able to clone the base game versioned tiki lamp no matter what i try?
Also it seems as if they changed something in the torch lamps so they could use them in WA?
so now all torch lamps react differently?
Alchemist
#107
8th Jan 2010 at 11:28 PM
Posts: 2,932
Thanks: 15582 in 28 Posts
I don't know if EA changed the fire-lamps either. That's a good question also Fire~. Definitely the object looks very different to the S3ObjTool but is it that EA changed the object or that one or both of the other two tools are handling it differently for some reason if WA is installed?
To save you time (since it's part of the base game and not a pay object or anything) here is the package for the TableTikiTorch if you want it. I already cloned it just to look at it since your MODL information got me curious about why it had two groups.
http://jaue.com/om/EA_Lighting_TableTikiTorch.rar
To save you time (since it's part of the base game and not a pay object or anything) here is the package for the TableTikiTorch if you want it. I already cloned it just to look at it since your MODL information got me curious about why it had two groups.
http://jaue.com/om/EA_Lighting_TableTikiTorch.rar
#108
9th Jan 2010 at 2:41 AM
Posts: 39
That is a good question as well Orangemittens,
Thank you for the download, i was getting frustrated and about to remove WA just to clone the tiki lamp,
then mod it, then reinstall to see if it changed anything? now i can leave in the expansion then test, you saved me a headache, again i thank you.
Thank you for the download, i was getting frustrated and about to remove WA just to clone the tiki lamp,
then mod it, then reinstall to see if it changed anything? now i can leave in the expansion then test, you saved me a headache, again i thank you.
#109
9th Jan 2010 at 2:57 AM
Posts: 2,832
Thanks: 6616 in 20 Posts
I looked at and at least decompiled almost every MODL in the game. There are some with two MODL chunks (internal chunks) that the decompiler will refuse to work with because I could never properly define what the second MODL was for, and how to manage it, using a mesh editor designed to have one mesh in it at a time.
But I never saw one that looked like this. Not that it will be impossible... they are probably simpler than the decoding that had to be done on the compressed versions.
And prior expansion packs for Sims 2 not only added content, but sometimes revised base level content to be more compatible with some programming changes made in the EP, sometimes adding features and sometimes just being made differently. A lot of that happened on EP1, so a lot of items needed to be rebuilt for University, if I am remembering properly... seems like it was half a century ago, instead of 5 years or so.
If you like to say what you think, be sure you know which to do first.
But I never saw one that looked like this. Not that it will be impossible... they are probably simpler than the decoding that had to be done on the compressed versions.
And prior expansion packs for Sims 2 not only added content, but sometimes revised base level content to be more compatible with some programming changes made in the EP, sometimes adding features and sometimes just being made differently. A lot of that happened on EP1, so a lot of items needed to be rebuilt for University, if I am remembering properly... seems like it was half a century ago, instead of 5 years or so.
If you like to say what you think, be sure you know which to do first.
Alchemist
#110
9th Jan 2010 at 11:01 AM
Posts: 2,932
Thanks: 15582 in 28 Posts
You're welcome Fire~ If you decide you need another fire object from the base game PM me and I'll clone it for you. I'm interested to know the result of your work with the Tiki torch and if it does ok in your WA game.
"But I never saw one that looked like this..." that seems par for the course with Sims 3 IMO. Maybe I've blissfully erased the pain but it seems to me that in Sims 2 objects were not as idiosyncratic as these Sims 3 objects are. Working with a new one is like learning how to mesh for the game all over again each and every time. I'm glad you have the patience to stick with the programming end of it all Wes.
"But I never saw one that looked like this..." that seems par for the course with Sims 3 IMO. Maybe I've blissfully erased the pain but it seems to me that in Sims 2 objects were not as idiosyncratic as these Sims 3 objects are. Working with a new one is like learning how to mesh for the game all over again each and every time. I'm glad you have the patience to stick with the programming end of it all Wes.
#111
9th Jan 2010 at 11:27 PM
Last edited by Fire~ : 9th Jan 2010 at 11:47 PM.
Posts: 39
Quote: Originally posted by orangemittens
You're welcome Fire~ If you decide you need another fire object from the base game PM me and I'll clone it for you. I'm interested to know the result of your work with the Tiki torch and if it does ok in your WA game. "But I never saw one that looked like this..." that seems par for the course with Sims 3 IMO. Maybe I've blissfully erased the pain but it seems to me that in Sims 2 objects were not as idiosyncratic as these Sims 3 objects are. Working with a new one is like learning how to mesh for the game all over again each and every time. I'm glad you have the patience to stick with the programming end of it all Wes. |
Well so far the file does not allow the flame to show correctly?..well not at all in WA, i see the light but cannot get the flame? i made a simple mesh to show the problem.
in the WA file i pull' they have new information added that has to do with the flame, information and a .DDS file for the flame itself,
when my son gets off of the other computer i will add the base game back and pull the files myself to see if anything was missing? i have changed nothing but the mesh, i do not think it is anything i am doing wrong with the mesh? so it has to be because of new information in the file?
Here is a pic of both on and off functions.
Edit:
Here is a pic of your file, Mesh untouched.
Alchemist
#112
9th Jan 2010 at 11:59 PM
Posts: 2,932
Thanks: 15582 in 28 Posts
That's the extra group then...the flame group. I pulled the entire working file for the package that I posted above...that's all the base game object has. Like all the lighting objects in the base game, candles included, this one has no flame and instead just produces a sort of all-over glow. Here it is in my game...it looks just as it does in yours:
I wasn't aware that EA had corrected their flame deficiency in WA or I would have mentioned that you were unlikely to get a flame from using the base game object to clone from...I apologize.
If I were you I wouldn't bother pulling the base game item yourself...you're only going to get a duplicate of the one I posted. WA has flame but the base game doesn't. You didn't do anything wrong and there's no way to fix the issue using a base game clone I bet.
I wasn't aware that EA had corrected their flame deficiency in WA or I would have mentioned that you were unlikely to get a flame from using the base game object to clone from...I apologize.
If I were you I wouldn't bother pulling the base game item yourself...you're only going to get a duplicate of the one I posted. WA has flame but the base game doesn't. You didn't do anything wrong and there's no way to fix the issue using a base game clone I bet.
#113
12th Jan 2010 at 2:14 AM
Last edited by Raven Shadow : 13th Jan 2010 at 10:53 PM.
Posts: 209
Thanks: 1945 in 29 Posts
Using the most recent versions of S3OC, S3PE & S3 Object Mesh Tool,
I've been unable to decompress the mlod1 mesh for sunset valley's
school house.
S3ObjTool returns "ERR: Unknown Vertex element type 3 specified."
The info button returns this:
Edit:
many of the other rabbit holes cause the same error, only the restaurants &
stores seem to be decompilable.
How did other modders make alternate ones?
I've been unable to decompress the mlod1 mesh for sunset valley's
school house.
S3ObjTool returns "ERR: Unknown Vertex element type 3 specified."
The info button returns this:
Quote:
Group Count = 20 Group 0: Faces = 60, Vertices = 120, Matl_block = 1 Group 1: Faces = 4, Vertices = 8, Matl_block = 1 Group 2: Faces = 56, Vertices = 112, Matl_block = 9 MTST: tag 0x3F0742EF, block 66 block 66, tag 0x2EA8FB98 block 67, tag 0x51371AB8 Group 3: Faces = 163, Vertices = 278, Matl_block = 13 Group 4: Faces = 724, Vertices = 1092, Matl_block = 17 Group 5: Faces = 423, Vertices = 732, Matl_block = 20 Group 6: Faces = 260, Vertices = 368, Matl_block = 23 Group 7: Faces = 562, Vertices = 904, Matl_block = 23 Group 8: Faces = 260, Vertices = 368, Matl_block = 23 Group 9: Faces = 22, Vertices = 42, Matl_block = 32 Group 10: Faces = 452, Vertices = 778, Matl_block = 32 Group 11: Faces = 638, Vertices = 1126, Matl_block = 38 Group 12: Faces = 1941, Vertices = 2893, Matl_block = 41 Group 13: Faces = 136, Vertices = 168, Matl_block = 44 MTST: tag 0x4D474AE4, block 68 block 68, tag 0x2EA8FB98 block 69, tag 0x51371AB8 Group 14: Faces = 94, Vertices = 186, Matl_block = 47 Group 15: Faces = 256, Vertices = 408, Matl_block = 50 Group 16: Faces = 56, Vertices = 112, Matl_block = 53 Group 17: Faces = 260, Vertices = 251, Matl_block = 56 Group 18: Faces = 64, Vertices = 128, Matl_block = 59 Group 19: Faces = 3728, Vertices = 7190, Matl_block = 62 Total faces = 10159, Total Vertices = 17264 |
Edit:
many of the other rabbit holes cause the same error, only the restaurants &
stores seem to be decompilable.
How did other modders make alternate ones?
#114
14th Jan 2010 at 10:13 PM
Posts: 39
Raven you might want to pull one of their files and take a look into someones package file and see how it was modded? could be as simple as just a few flag changes? but that is a start in the direction i would take.
#115
14th Jan 2010 at 11:30 PM
Posts: 2,832
Thanks: 6616 in 20 Posts
The error message tells me a lot, because I made it cite the value it found in the new file. That value was not used in any base game files, as best I can tell. Since the decompiler does not know what it is, nor what to do with the data field, it bails out... to do otherwise is to invite a crash.
Let's settle this question on this, because I think it is something that changed in WA... it is not unusual for items to be updated in an EP, even when they appear to be the same as before.
Please post ONE of the MLOD files that will not decompile, including the TGI. I will compare it with the base game version. It would be simple enough to silently ignore these, but that is provided the model can be remade without them.
If you like to say what you think, be sure you know which to do first.
Let's settle this question on this, because I think it is something that changed in WA... it is not unusual for items to be updated in an EP, even when they appear to be the same as before.
Please post ONE of the MLOD files that will not decompile, including the TGI. I will compare it with the base game version. It would be simple enough to silently ignore these, but that is provided the model can be remade without them.
If you like to say what you think, be sure you know which to do first.
#116
17th Jan 2010 at 9:05 PM
Posts: 209
Thanks: 1945 in 29 Posts
Quote: Originally posted by WesHowe
The error message tells me a lot, because I made it cite the value it found in the new file. That value was not used in any base game files, as best I can tell. Since the decompiler does not know what it is, nor what to do with the data field, it bails out... to do otherwise is to invite a crash. Let's settle this question on this, because I think it is something that changed in WA... it is not unusual for items to be updated in an EP, even when they appear to be the same as before. Please post ONE of the MLOD files that will not decompile, including the TGI. I will compare it with the base game version. It would be simple enough to silently ignore these, but that is provided the model can be remade without them. |
If by TGI's you mean the ones in the mesh , I attached the file exported straight from S3PE.
Fire, (the same one from CS3?)
That would require editing the mesh file itself, the error isn't caused by vpxy or objd, etc., and if the WA versions are different from the original, then
changes to the mesh (or using the original) could cause trouble later, just
like the Blue Lot issue was caused by incorrect data, that was ignore by earlier versions of the game, but not the newer ones.
Attached files:
Bad LOD1.zip (173.4 KB, 10 downloads) - View custom content | ||
636316 01-17-10 15:55 S3_01D10F34_00000000_000000000042E113%%+MLOD.lod -------- ------- 636316 1 file |
||
Description: Sunset Valley School House LOD 1 |
#117
18th Jan 2010 at 12:23 AM
Posts: 2,832
Thanks: 6616 in 20 Posts
This is not a WA change, the same structure is in the original game file archive... I needed your file to satisfy myself that it wasn't a WA change, we're just noticing it now is all.
It is really not a substantive issue, but it will take some work here to incorporate this into the decompiler and recompiler. The "type 3" are just four uncompressed floats for the skin weights... not that the model uses anything but 100% on the first assignment. Generally the models use a compression type on all the data items, with an implied 4th weight.
The uncompressed fields make considerably larger files, but aside from shoehorning in some handler code for it, it will be easier to manage than all the compressed fields.
If you like to say what you think, be sure you know which to do first.
It is really not a substantive issue, but it will take some work here to incorporate this into the decompiler and recompiler. The "type 3" are just four uncompressed floats for the skin weights... not that the model uses anything but 100% on the first assignment. Generally the models use a compression type on all the data items, with an implied 4th weight.
The uncompressed fields make considerably larger files, but aside from shoehorning in some handler code for it, it will be easier to manage than all the compressed fields.
If you like to say what you think, be sure you know which to do first.
#119
18th Jan 2010 at 3:51 AM
Posts: 2,832
Thanks: 6616 in 20 Posts
Well, I worked on this tonight, and it has left me very frustrated. I worked out the importation part and can import the file, but *parts* of the mesh do not seem to follow the algorithms that work on the rest.
You can see on the screenshot below that most of the normals are not right, you cannot see that some of the groups have UV mapping that is out-of-bounds (which creates multiple warnings on recompilation).
I am trying to decide what to do next... I could release a partial fix soon enough, but it will only aggravate people even more when they have to remap some groups to make it work right. The normals are easy enough to fix with a smooth all, but the UV maps are broken forever until they are remade.
Maybe I will then wait until I figure out why the decompilation is different on this one.
If you like to say what you think, be sure you know which to do first.
You can see on the screenshot below that most of the normals are not right, you cannot see that some of the groups have UV mapping that is out-of-bounds (which creates multiple warnings on recompilation).
I am trying to decide what to do next... I could release a partial fix soon enough, but it will only aggravate people even more when they have to remap some groups to make it work right. The normals are easy enough to fix with a smooth all, but the UV maps are broken forever until they are remade.
Maybe I will then wait until I figure out why the decompilation is different on this one.
If you like to say what you think, be sure you know which to do first.
#120
18th Jan 2010 at 9:38 PM
Posts: 209
Thanks: 1945 in 29 Posts
Everyone that I know of that need/want this fix, want to be able to create
custom rabbit holes (especially on CS3).
So if it makes it easier,what about a popup warning that the mesh will have to be re-UV'd before recompiling and letting the decompile proccess scrap the existing uv's?
I guess it depends on whether the rabbit holes with the unknow vertex data can function if recompiled in the same format as the stores & restaurants.
custom rabbit holes (especially on CS3).
So if it makes it easier,what about a popup warning that the mesh will have to be re-UV'd before recompiling and letting the decompile proccess scrap the existing uv's?
I guess it depends on whether the rabbit holes with the unknow vertex data can function if recompiled in the same format as the stores & restaurants.
#121
21st Jan 2010 at 3:37 AM
Posts: 2,832
Thanks: 6616 in 20 Posts
I had to make another fix, for the bounding boxes, so there is an update to V1.01 (in the first message of the thread). I left the code I have written in there, so it will work with at least two rabbitholes. There is something very wrong in the decompression for some groups, the normals and UVs are out-of-whack. But the mesh looks pretty much correct, so maybe you can work with this, as the UVs are not bad on every group, and the normals are easy to fix (smooth all).
If you like to say what you think, be sure you know which to do first.
If you like to say what you think, be sure you know which to do first.
Forum Resident
#122
21st Jan 2010 at 5:26 PM
Posts: 658
Thanks: 37894 in 37 Posts
Thanks for these fixes, that will help a lot, I think.
hexameter
hexameter
#123
21st Jan 2010 at 9:49 PM
Posts: 2,461
Thanks: 1849 in 12 Posts
Wes, thank you very much for the update!
#125
6th Feb 2010 at 5:53 PM
Posts: 209
Thanks: 1945 in 29 Posts
Wes,
After messing around some more with the school house,
TSRW released RC4 and while it still doesn't support rabbtit holes,
It will load the mesh data for the school.
It shows that it has 4 extra bounding boxes that are used to show the
size/shape of each wing of the building and one for the front entrance.
These bounding boxes are causing the game to maintain a huge footprint for
the building, even when the vpxy footprint and the main bounding boxes are
much smaller.
Since I can't find any reference to these new bounding boxes in S3PE and bounding box data is kept in the mesh file, I'm lead to believe that
the compressed type 3 vertex data could actually be the "Extended Bounding
Boxes" TSRW displays.
BTW, the grocery doesn't have the type 3 data, nor does it have xtra
bounding boxes and I was able to use a clone of it as a School House
A way of editing or just deleting this info would be greatly appreciated.
After messing around some more with the school house,
TSRW released RC4 and while it still doesn't support rabbtit holes,
It will load the mesh data for the school.
It shows that it has 4 extra bounding boxes that are used to show the
size/shape of each wing of the building and one for the front entrance.
These bounding boxes are causing the game to maintain a huge footprint for
the building, even when the vpxy footprint and the main bounding boxes are
much smaller.
Since I can't find any reference to these new bounding boxes in S3PE and bounding box data is kept in the mesh file, I'm lead to believe that
the compressed type 3 vertex data could actually be the "Extended Bounding
Boxes" TSRW displays.
BTW, the grocery doesn't have the type 3 data, nor does it have xtra
bounding boxes and I was able to use a clone of it as a School House
A way of editing or just deleting this info would be greatly appreciated.
Who Posted
|