Archangel35757

Compare the axes of the foot/ankle bone to the bolt axes.

the bolts in Modview behave like bones... they use +Z up, +X right, and +Y into screen if IIRC. Basically a 90 degree rotation about the X axis in Softimage. Is the face normal of the bolt triangle flipped the wrong way? Based on your screenshot... I'd try rotating your bolt 180 degrees about Y axis.

Do you have negative scaling on any of your tags? Edit: Is the triangle surface's Normal vector flipped? I'm assuming your bolt matches what you posted here: try putting long edge on red axis and short on green.

Is this a prototype for a Hutt? Looks like a cross between Casper the ghost and a Hutt. But hey, to each his own.

You can read about MD3 tags in the file format description here: https://linux.ucla.edu/~phaethon/q3/formats/md3format.html The red axis of the tag is forward, the blue axis of the tag is up, and the green axis of the tag is left. For example you want the red side of that tag to face front for tag_weapon. This corellates to the right-hand rule:

Does the base AT-ST have this same problem? The bone jitter was an issue with Carcass-- which is now resolved.

good discussion topic... (MD3 = tag_* and GLM = bolt_* ). Could your bolt be mirrored? I'm driving from Vegas to Palm Desert, CA. will post as soon as I can.

Yes, SP.

I'm wondering how difficult would it be to append ragdoll physics to some parts of the skeleton-- rather than have everything done as animations. For example... if we had a new animation to jump and grab a ledge (either a canyon-like gap or higher cliff edge)... the jump would start off as "BOTH" and grabbing the ledge would end up on the "TORSO" group of bones... but it would be nice if ragdoll physics could be applied to the LOWER/LEGS section... and finally dampen to a set LOWER/LEG pose. It would offer variability and not always look the same. Thoughts?

...a walkway, that no one can walk on, with a view no one can appreciate-- except powerful Jedi... My philosophy is that all architecture and structures should have a function/purpose... when stuff like this is out of place/unreachable by the Imperial personnel that built it-- it breaks the immersion experience. Imho.

then how would non-jedi reach the catwalk? If they can't, then the catwalk serves no real functional purpose...

Hmmm... catwalk screams for an access ladder-- you could model a ladder and use the ladder brush and @@eezstreet could incorporate @@DT85's SoF2 ladder code from the DF2 repo... just a thought-- and a new feature!

could you just use an texture image FX runner that would repesent a steel cable for lowering/raising crane magnet? (I don't really know what I'm talking about here-- just an educated guess).

Well, I look forward to your experiment results.

Thanks! If you made it a new keyword option on light entities then folks could choose themselves to use it or not... According to that paper the performance hit is minimal:

@@Xycaleth - did you download that PDF?

@@Xycaleth - how then do you accurately compute the dynamic lighting for a certain type of light? I think light entities should have a editable parameter that would accept an .ies file... which if left blank would do things as you currently do... but given the .ies file I would think it would simplify the computations for a light, no? http://www.cescg.org/CESCG-2013/papers/Krochmal-Real_time_prototyping_of_physical_lighting_based_on_goniometric_light_sources.pdf

Would it not be possible to lock out the player movements but have the joystick movements then drive the crane?

So in your Dynamic lighting calculations can you use the true .ies data file that almost all lighting manufacturers now generate and create for all their lights?

for example:

Have you ever used IES light data in alpha channels? http://www.cgarena.com/freestuff/tutorials/max/ieslights/

Awesome! Now write your tutorial on making Wall-e.

@ - hard to say... the new/fixed MD3 exporter will display export statistics on how many additional vertices were generated and what the final triangle and vertex count are... that looks like this: I'm not sure when @@DT85 will get them all recompiled and submitted.

When you export to MD3 it creates extra vertices. In 3dsMax/GMax mesh & vertex data is stored differently than the MD3 or Ghoul2 GLM formats. You must consider a vertex as having/representing a position, one UV texture coordinate, and one normal vector. 3dsMax/GMax do not store vertex information this way. Smoothing Groups allow you to have multiple normals at a vertex along the smooth group boundary edges. Also in 3dsMax/GMax there is no gaurantee that there is only one UV texture coordinate at a vertex-- again there could be multiple. So the MD3 exporter has to create extra vertices to hold this extra information. Does that make sense?

Under the utility menu there is a tool call polygon counter that counts triangles and vertices.