Archangel35757

The last episode I saw was Ezra having a vision and the traitorous Senator. Kanan was not captured then... but if you say Tarkin is with the Inquisitor -- then it must be that Kanan kills the Inquisitor at some point because Tarkin tells Vader in EP.4 that he is the last of that "religion."

...do tell.

Use a looping ROFF2 animation

@@AngelModder -- you must write some mapping technique tutorials for this engine!

Update: ...only one issue remains to be resolved for the new dotXSI 1.x and 3.x Importer Maxscript (v2.0 Beta)-- which is... there is some sort of bug where some of the rancor's textures are not importing. This issue doesn't show up when importing other files but it could impact other files and so I need to trace it down and fix it. I also need to apply the dotXSI 3.x changes to the batch import routine and then it'll be ready to release.

Awesome work!

Anything different or unique in the header of the md3's that have issues?

Any news?

Ok... the new Maxscript to be used with the Max6 Softimage dotXSI importer should be fixed and working properly now... Softimage dotXSI Import (v1.7 Plug-in) Cleaner 0.5 Beta

Maybe we should hear `em sizzle when hit by a laser bolt?

@@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.