#1081
Posted 25 October 2014 - 03:56 PM
#1082
Posted 25 October 2014 - 04:34 PM
Cimarb, on 25 October 2014 - 03:56 PM, said:
Hehe, I'm working on a new music parody video, and need to animate about 5 or 6 mechs. Just rewatched my third one again so I can figure out wtf to do. This stuff takes time and practice, and even then, it requires constant use to keep your skills fresh.
#1083
Posted 25 October 2014 - 04:37 PM
Heffay, on 25 October 2014 - 04:34 PM, said:
Hehe, I'm working on a new music parody video, and need to animate about 5 or 6 mechs. Just rewatched my third one again so I can figure out wtf to do. This stuff takes time and practice, and even then, it requires constant use to keep your skills fresh.
Im sorry we couldnt help out with that one, we're just too busy and we have only one 3D artist..
#1086
Posted 26 October 2014 - 07:49 AM
Iqfish, on 25 October 2014 - 04:41 PM, said:
No, our CPUs don't. Especially this time
Rebus farms!
Or roll your own:
http://cgcookie.com/...-a-render-farm/
#1087
#1088
Posted 26 October 2014 - 01:28 PM
Heffay, on 25 October 2014 - 03:52 PM, said:
Does this file actually exist?
Yes, but I've figured out the problem, by default neosis attaches an output tag to any file you convert, blender does not like this, and you must disable this option in preferences or in the batch tool or blender will not load the file.
The internal structure of the pak files has also changed, a bunch of the shared meshes and textures are not where your script thinks they are, with the null inputs causing the script to hang and time out, import the cockpit and weapons manually allows you to work around this.
Edited by HlynkaCG, 26 October 2014 - 01:30 PM.
#1089
Posted 26 October 2014 - 04:01 PM
HlynkaCG, on 26 October 2014 - 01:28 PM, said:
Yes, but I've figured out the problem, by default neosis attaches an output tag to any file you convert, blender does not like this, and you must disable this option in preferences or in the batch tool or blender will not load the file.
The internal structure of the pak files has also changed, a bunch of the shared meshes and textures are not where your script thinks they are, with the null inputs causing the script to hang and time out, import the cockpit and weapons manually allows you to work around this.
I'll have to take a look at this. The Locust used to import just fine, but it's possible things have changed. Thanks for the heads up!
#1090
Posted 27 October 2014 - 10:09 AM
In regards to changes my pak files taken from the most recent game build has no monitor textures and the cockpit files (shared panels and the like) are seperated by Clan vs IS.
Other than that good work, and thanks you for the script and the support.
#1091
Posted 27 October 2014 - 12:13 PM
Anyway, thanks to Heffay and this thread I am able to start taking apart the models and see how they fit together. One interesting thing that I've noticed off the bat is that a lot of the newer mechs, clan mechs in particular appear to make use of forced perspective in their cockpits. Simply put, many of the screens that look tiny are in fact full 24in monitors and there is no way for the cockpit to fit inside the mech. The locust's cockpit is particularly gregarious, being a full meter longer than the mech itself.
That said the exterior meshes don't seem too bad.
ETA:
For those who are curious, the "pilot" is a 5' 10" 80 kg male mesh that I routinely use as my "baseline" human when doing CAD work. as you can see he fits in the mech quite comfortably even though the cockpit does not.
The mech is an Uller A
Edited by HlynkaCG, 27 October 2014 - 12:15 PM.
#1092
Posted 27 October 2014 - 01:00 PM
#1093
Posted 27 October 2014 - 01:17 PM
HlynkaCG, on 27 October 2014 - 12:13 PM, said:
Haruka did a full series of posts on cockpit sizes:
http://mwomercs.com/...line-asset-art/
It's interesting reading, but yes, the cockpits are larger than what the mech would support. I tend to wave it off with explanations like " the average pilot height was 4'9" in 3050". Although they still say they are normal sized people, the Houses tend to use NBA height scaling when discussing how tall someone is (hey, never hurts to add a few inches to the player reports, eh?).
#1094
Posted 27 October 2014 - 02:36 PM
Heffay, on 27 October 2014 - 01:17 PM, said:
Haruka did a full series of posts on cockpit sizes:
http://mwomercs.com/...line-asset-art/
It's interesting reading, but yes, the cockpits are larger than what the mech would support. I tend to wave it off with explanations like " the average pilot height was 4'9" in 3050". Although they still say they are normal sized people, the Houses tend to use NBA height scaling when discussing how tall someone is (hey, never hurts to add a few inches to the player reports, eh?).
If you look I linked to that thread in my reply, and what I'm talking about goes a bit beyond a few inches in hieght. The chair in the kitfox's cockpit mesh is scaled for someone who's legs are 2 meters long, but has a normal (baseline) sized torso.
That's what I was referring to when I mentioned forced-perspective.
#1095
Posted 27 October 2014 - 04:12 PM
I'm working on a custom Jagermech model and I used multiples of the same type of weapons to make new ones - barrels etc.
I can't get those weapons to stick to the armature for some reason. At first I thought it was because they were mixed L/R and Heffay's script wanted them to be correct because some of them would move.
So I redid the weapons with the correct sides and now none of them would move. i renamed all the objects so they don't have .001s etc and have left/right in them but still nothing. Any ideas as to why even though parented to the armature these still won't budge? (I did also rename the vertex groups for those objects to the originals but nada. I basically made several copies of the mech using the script to use as "parts".)
EDIT: Something that I noticed in the spawning of the objects is that the ballistic weapons, namely the AC2s and AC5s come in as a pair of objects tied together by some force different than parenting or anything else I've ever encountered. I found out how to separate them by doing Edit Mode > P to separate them by selection/texture etc. but this won't work because you can't select ALL the vertices for either object (base and barrel) in order to separate them. So...there's actually 5 useless pieces flying around in space in this image, about a billion kilometers away. Just a heads up, Heffay. i think it's because of the recoiling barrels function that they did it this way.
Edited by Edweird, 27 October 2014 - 04:33 PM.
#1096
Posted 27 October 2014 - 05:32 PM
The original pairing of the mech object with a particular bone comes from one of the config files. Each object has a bone name associated with it, and the script will assign those vertices in that object to that bone name. Like this:
# Create a vertex group with the bone name. This makes parenting to armature super easy! $parsedline += "bpy.ops.object.vertex_group_add()" $parsedline += "bpy.context.object.vertex_groups.active.name = `"$bonename`"" $parsedline += "bpy.ops.mesh.select_all(action=`'SELECT`')" $parsedline += "bpy.ops.object.vertex_group_assign()" $parsedline += "bpy.ops.mesh.select_all(action=`'TOGGLE`')"
What you can do is in edit mode, select the vertices you want to assign to that bone into the vertex group. Vertex groups are under the... umm.. here:
In edit mode, you'll be able to assign and deassign as necessary. Add them to the vertex group that is controlled by the bone you want to move them with.
Now, this will probably not be enough. I think. I'm theorycrafting here, but you'll need to parent those vertices with the bone as well. Go check out the weight paint function. It's under the mode menu, where you switch between object, edit, pose, etc. If you have the object selected, one of the functions is weight paint. When you select a bone, you should see which vertices are affected by it by color. For robots it's super easy (usually 100% or 0%), but with humanoids (because flesh stretches) it can vary. If the vertices you want to move are blue when you select the bone, then you have to paint them until they turn red.
The exploding geometry object is a known issue with the Noesis plug-in. I have a test version that kinda-sorta helps fix it, but it's still not perfect. You can find it here: (keep in mind there may be other bugs, but... it may help out)
https://dl.dropboxus...ne_cgf.dll.test
Take off the .test extension, place it in your Noesis plugin folders, and see if that helps.
#1097
Posted 28 October 2014 - 02:56 AM
Heffay, on 27 October 2014 - 05:32 PM, said:
Apparently ALL the objects had ALL the vertices assigned. O.o
But that wasn't the issue.
Yup, you were right, it was the weight, those objects had no weight with the armature.
Thanks! I'm gonna try your fix for the object explosions now. Setting the origin of the object on one of the pieces goes around the issue but...it is kind of annoying to have a spare part hanging in mid-air a mile away and I imagine it bugs the hell out of you. (Yes, I see that the barrel is hanging in mid-air too lol)
Edited by Edweird, 28 October 2014 - 03:33 AM.
#1098
Posted 28 October 2014 - 06:36 AM
#1099
Posted 28 October 2014 - 07:08 AM
CaptainKBX, on 28 October 2014 - 06:36 AM, said:
Can you post some screenshots of what you're seeing? The more specific info you provide, the easier it is to find out what went wrong. Thanks!
#1100
Posted 28 October 2014 - 07:15 AM
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users