Archangel35757

@@DT85 -- I understand their similarity, but in Ghoul2 models they should be labeled as "bolt_" and "tag" in MD3 was my original point. Also, I just uploaded a brand new Maxscript that fixes the broken Softimage dotXSI v1.7 Import Plugin... well, I mean it cleans up the mess and puts the animation in the proper 3ds Max coordinate system... Softimage dotXSI Import (v1.7 Plug-in) Cleaner 0.4 Beta So now the screwed up Wampa animations can be imported into 3ds Max... but I would recommend using my other dotXSI Importer maxscript for all other files.

"bolt" is the terminology for Ghoul2 models... "tag" is the terminology of MD3 models. So I just want to make sure that I don't mess up in writing the importer to do something it should not. All mesh objects for the character, creature, or vehicle are set at the world origin [ 0.0, 0.0, 0.0 ]. But currently, the pivots of all bolts are located in world space at the bolt (i.e., NOT at the world origin-- this is what I wanted to confirm to be the correct behavior). P.S. -- I can't seem to figure out how to "fix" the wampa files... (so far it is the only one slightly messed up in some face bones). @@minilogoguy18-- I saw something in Softimage Mod Tool that talked about making the scene root be co-located with the first bone??? I wonder if this is what is causing the transforms to be exported such that the Wampa seems centered about the origin??? Perhaps it was exported with incorrect settings? And somehow ModTool is compensating for this during import.

@@DT85. @@Psyk0Sith I just want to verify that all mesh objects, bolts, caps, etc. are supposed to have their pivots at the origin? ...and that this requirement applies across the board to humanoid, creatures, vehicles, etc.

@@DT85 Well crap... I'm going to have to come up with another solution (other than using the SRT transform for the basepose-- to fix those characters who have their basepose below the groundplane) because that will only work for the root pose files. In the animated files they did not export frame0 so the first frame in the file is the initial animated pose on frame1-- which is NOT equal to the basepose. So my fix messes up on animated files. Thinking out loud... I believe I am going to have to let it import as-is... and then check to see if the root basepose on frame0 is below the groundplane... then provide a checkmark option to shift basepose up on frame0. I'll need to work out those details...

It looks like there will need to be some tweaking on how to properly handle the auto-generated normal maps-- because if you look closely... Tavion's tattoo's appear to be cut into her flesh... whereas the tattoo should just be on the top of her flesh with no "+/- thickness". Great work Jon! Keep it up!!!

@@DT85, so you might like this new layout (although your request isn't implemented yet... it has a placeholder): Ok, now on to the issues that remain. So some dotXSI files (so far I'm only aware of the Wampa dotXSI files...) are problematic. For some unknown reason, the SI_Transform BASEPOSE templates in the dotXSI file are messed up: Because the parent of this rear_null is "skeleton_root" which has a transform matrix of identity... these two templates should be identical. I can't explain yet why they are not... but what I did to try and correctly import these "messed" up files was to use the SRT transforms to compute the Basepose as opposed to using the Basepose transforms on frame 0. The SRT and BASEPOSE transforms are related. The BASEPOSE transform is the matrix for an object with respect to World space coordinates; and the SRT transforms is the matrix for an object in local coordinates with respect to where it is in its parent space. Nodes/objects which have no parent or their parent is a node at the origin with the identity matrix as its transform would have equivalent SRT and BASEPOSE matrices. (World space): Basepose Transform = ( SRT transform ) * parent.transform or, (Parent space): SRT transform = Basepose Transform * (inverse parent.transform) **The way I try to remember this to keep things straight as to what space is what, is a little saying I came up with, which is: "A child (i.e., SRT matrix) separated from its parent (i.e., not multiplied by its parent matrix) would be lost in the world. But when a child is with its parent, then it knows its place in the world." So I added a checkbox along with some logic, conditional statements to use the SRT transforms to compute the basepose matrices on frame 0. This worked but for some odd reason the LOD0 mesh object remained in the lower, incorrect position. It was exactly 30.0 units lower than where it should have been-- the exact error between the two templates above (for the Y-axis values, Y is up in Softimage). The result is this circus act (note: the importer only applies textures to LOD0, but it does put the materials in the material editor for you): For those 3dsMax users who ever imported the Wampa with the old Softimage importer then this should be no surprise seeing the LOD0 mesh below the ground plane. Additionally all the caps were misplaced lower as well. The easy fix for this is straightforward, simply select the offending objects (and choose affect objects only) and then, in this case, move them vertically 30.0 in the +Z axis. With all the meshes selected go into the character menu and set these fixed positions as the new skin pose. If you do this correctly, you should get this: ...for grins, I changed the rear_null template values to match and re-imported (not using SRT values but the Basepose values) and all this did was fix LOD0 to be in the correct position and shifted LODs 1 and 2 to be "riding the shoulders of LOD0". There must be something else I'm doing wrong... because Mod Tool has no problems importing this file correctly. When constructing the meshes from the xsi data face-by-face... I do multiply by the parent transform (which in my case is identity matrix)... perhaps I'm doing something incorrect there... but then again the Importer is working just fine for the humanoid and other creature files I've tested... so maybe it's only the Wampa files that are messed up. [Edit]-- One thing I am not doing is actually storing the BASEPOSE and SRT transforms for mesh objects... because all meshes should have their pivots at the origin, and mesh vertex data has the positions where all the vertices should be... since I'm constructing it poly-by-poly... but I just looked at the hips_1 and hips_2 LODs and their templates have a -30.0 value. So I think I need to be using their SRT and BASEPOSE templates as well. I will investigate this ephiphany later... off to bed now. Feedback is welcome.

That wiki crap is all bullshit... IMO. Anyone can update it to read differently. That gyroscopic effect is only when you ignite the Saber-- not continually. Also, If it was, when you threw the Saber it would tumble like crazy. Also, Vader's saber had a feature to vary the blade length somewhat [according to novels]... perhaps there is a physical limit to blade length due to power/crystal requirements, etc.

I believe Castle Wolfienstein has a chemical lab and related assets... search thru its PK3s.

I hope at long last, we are blow away with the lightsaber skills of Jedi Master Luke Skywalker-- it better top Darth Maul fight fight Obi-Wan and Qui-Gon on Naboo. Even how Obi-Wan and Qui-Gon handled their lightsabers dealing with the droids on Naboo... just give me something other than a medevial knight swinging a broadsword... or the little tappy-tap exchanges in Ep. 4.

Ok... so the way I have the script set up to import the model textures is this: First, it will look in the relative path (read from the XSICustomPSet template) and appending it to the base directory path you specify. If it find's the texture then all is good. But if the textures are not in the base path then it looks in the same directory as the file being imported, if the texture still is not found, then it creates a composite checker map with a "MissingBitmap.png" texture. So if the textures are not found it would come out like this: Regardless, it will write the proper texture file name and relative path as the Diffuse Texture Map Slot Name. The Top-Level Material name is just sequentially numbered: material_1, material_2, etc. These can be renamed by the Artist to whatever they want it to be... e.g., head, torso, etc. But the new version of the exporter will expect the relative path for the texture (e.g., models/players/jedi_malak/body.tga ) to be the Diffuse Map Name. Once you sort out your missing textures, it's easy to replace the "Missing Bitmap" Checker pattern-- where they should immediately show up on the model. The checker pattern will always use the first color as RED the secondary color is a random color that doesn't use any red in it's RGB value... and the values are limited so it doesn't get too dark. Any feedback on this approach?

That's only during the ignition that it generates that effect. Also, technology wise there has been scientific discussion that the most likely technology for a lightsaber would be a plasma blade-- which wouldn't give off any heat... but it would generate light! And could be constrained to the shape of a blade-- unlike true light. Google for the Sci-Fi or Discovery episode that discussed the science of Star Wars weapons.

I despise their cartoonish choice for modeling & texturing! In my opinion they should have strived to make it surpass KOTOR & TFU but more cinematic.

I'm watching episode 11 "Idiot's Array" and just laughed out loud how the escape pod "fell-away" from the Ghost as if it were in atmosphere under the full affect of gravity! Hilarious... the writers need to brush up on some fundamental physics of space. ...puffer pig! Please... it's a wonder it didn't snort like the pigs from Angry Birds game.

UPDATE: ...so I've sorted out the skinning issues-- they should be resolved. Unfortunately, there still is a bug in Maxscript regarding the "readValue" command for newer versions. I say it's a bug... because the script works just fine for all game types from Max 5 to Max 2011. In Max 2012, all dotXSI 3.x files import correctly (given the WIP status of the script-- still need to finish some things...). Unfortunately, this "readValue" bug breaks compatibility with the older dotXSI 1.x files in Max 2012. ...and in 3dsMax 2013+ the script seems to have more than one problem... even if you uncheck importing of envelopes. So, I'm going to finish the script targeting versions up to 3ds Max 2011 (which will work in 2012 for dotXSI 3.x files only). ...I hope you guys didn't un-install your older versions of 3ds Max.

@@DT85 -- So I found the bug that is causing skinning errors with v1.8 exporter files. This script bug is also the cause for the "readValue" error posted previously. Actually the original error lies with Raven's custom dotXSI exporter and not the Softimage based v1.8 exporter. It just manifested that way because I designed the script to first process Raven assets-- thinking all others would be good as well. When I get this fixed I will send you another beta version to try out.

I meant in terms of weight-- their movie props were probably close the the weight of a Katana.

@zefilus -- their dueling sabers they used during filming are in essence katanas... i.e., carbon fiber wound rods with steel cores.

I disagree. Lucas modeled the Jedi after the Samurai/KungFu Monks -- but he failed to hire stunt/fight coordinators who grasped that idea/vision... rather people in London, England interpreted "Lightsabers" like medevial two-handed broadswords-- and that is how they pathetically choreographed the OT saber duels... like medieval knights. Plus they used delicate clear glass rods which easily broke on contact-- thus making the fights look more pathetic. The Prequels got this aspect of saber dueling right!

Perhaps Ezra was biding his time undergoing further training-- after all. He'd need to be a true Master to face Darth Vader and the Emperor. Luke was truly a match for neither... only saved in the end by his father. One reason I wished they added scenes with a double having Yoda properly instruct Luke in all the lightsaber forms while on Dagobah.

Ok... I'm still having some bugs dealing with dotXSI files exported using the v1.8 exporters. Good news is the maxscript compiles and functions in 3ds Max 2015, but I'm getting the error that @@DT85 got in Max 2014. This issue is related to skin modifier and applying the skin weights. Here is the results of my error from the Maxscript Listener: So it looks like I have a little more debugging to do.