Home Technical Talk

Source Engine: $origin in models... Help Needed

polycounter lvl 13
Offline / Send Message
shawnolson polycounter lvl 13
I've run into a problem with a feature in Wall Worm Model Tools (ongoing thread at http://www.polycount.com/forum/showthread.php?t=78621 ) that I have been stumped on and currently don't have time to figure out. I'd like to fix a feature that sets the $origin setting in models' QC file as an offset from the world origin.

The reason for this setting is that a model designed away from the world origin will be offset the same amount from the prop entitiy when placed in game; it's documented a little more at http://wallworm.com/projects/utilities/docs/rollouts/export.html#uselocalorigin

I first added this feature after being introduced to the $origin command by Jed from www.wunderboy.org . But I am not entirely certain that I can get it to work properly. The only docs at the Valve Developer Community on $origin are mildly confusing ( http://developer.valvesoftware.com/wiki/$origin ) . If the diagram and explanation are correct, is there any way to use the $origin setting for anything other than view models?

I am hoping to be able to use this since it's sometimes easier to work with a model in place in the scene rather than in a separate file. But from my tests I have had crazy results in where the model ends up. Sometimes it is in the correct location... other times no.

Originally, I just did a reverse of the model's [X,Y,Z] to get the offset... but that failed. Then (because the docs say Z is reversed, I tried [-X,-Y,Z] but that also failed). Then I made it calculate based on if the world origin is positive or negative from the model's local X coordinates, etc. This works sometimes. It's just a mystery.

So if anyone has any actual experience and expertise with the $origin setting, please share the proper formula for setting it based on the model's current [X,Y,Z] in a scene -- if it is even possible.

If it's just not possible to use it as I thought, then that's that. Hopefully one of you can make up for my mental block!

Thanks in advance.

Replies

  • Mark Dygert
    I think, and I would have to test this, but if you skin the object to a bone, the bones pivot will override the world settings.

    So through script you can create a bone at the local pivot point, apply skin targeting just the one bone which will weight all verts to that bone, export and you should be good to go.

    Alternatively you could experiment with moving the object so the local pivot aligns to World 0,0,0, export, then move it back to its original position.
  • shawnolson
    Offline / Send Message
    shawnolson polycounter lvl 13
    So through script you can create a bone at the local pivot point, apply skin targeting just the one bone which will weight all verts to that bone, export and you should be good to go.

    Thanks Mark. The problem (off the top of my head) can be that the user may already be skinning vertices to bones in an animated model... so I am leery about automating it. I may do some tests though for a staticprop.
    Alternatively you could experiment with moving the object so the local pivot aligns to World 0,0,0, export, then move it back to its original position.

    That was something Jed suggested. I am still considering it... but I can already think of problems if there are multiple meshes in the model and/or complex rigs. If something controls the positions (like various contollers or linking) that WWMT doesn't account for... it could mess it all up.

    Still... it is on the list of options.

    Thanks!

    PS. If you do test any of these out or find a way to use $origin, please do feel free to share the procedure. I'd be happy to give credit on the docs site :)
Sign In or Register to comment.