Need a little help!

[theschell]

I'm working on a new freebie item, and I am wondering if anyone here knows how to rig/morph working tank tracks. I've tried and can't figure it out, and I'm having issues with the DS/Hex bridge not transferring the model to Hexagon so that I can try creating a morph for them... If anyone here knows how and might be willing to make the attempt I'd appreciate the help!

 

[English Bob]

There's good news, and there's bad news.

The good news is that it's possible, it has been done, and there is/was a tutorial on how to do it.

The bad news is that the tutorial has had its images broken by a subsequent forum upgrade and it was difficult enough to follow even with them. Without images, I don't fancy your chances. As far as I can tell I haven't saved a copy of it, but I'll keep looking.

 

[theschell]

I'd found a tutorial on it, but couldn't and haven't been able to make heads or tales of it as I'm not familiar enough with Poser to make it work, and with the DS to Hexagon Bridge not transferring the model I can't attempt it using that to generate a morph that might have worked. Anything you can find would be appreciated, but what I'm really hoping is that I can find someone willing to make the attempt to work with me on finishing this project.

 

[English Bob]

A morph won't do the job, unfortunately. You need each segment of the track to be a separate group, and the whole thing rigged in such a way that the segments follow each other around a complex path as the wheels turn. I barely understood VK's tutorial as it is, although that may just be because I never tried to put it into practice. Later versions of Poser have options such as animateable joint centres that weren't available when the tutorial was written, around the time of Poser 4.

A couple of posters in that thread said they'd saved a copy. If I can figure out how to do this, I'll happily help out - but be warned, it's a big 'IF'.

 

[Ken1171]

Makes me wonder why a morph wouldn't work to animate the tracks? It would need multiple morphs, in stages. Similar to how Paul has rigged DawnSE's morph to lick her lips. Once you have the morphs in place, they will need to be rigged into the model in Poser using the Dependency Editor. I think you will only need enough morph steps to make the animation loopable. I haven't tried animating tracks before, but I think this method should work.

 

[theschell]

Makes me wonder why a morph wouldn't work to animate the tracks? It would need multiple morphs, in stages. Similar to how Paul has rigged DawnSE's morph to lick her lips. Once you have the morphs in place, they will need to be rigged into the model in Poser using the Dependency Editor. I think you will only need enough morph steps to make the animation loopable. I haven't tried animating tracks before, but I think this method should work.

That was sort of the method I was planning on doing... do staged morphs tied to an ERC dial using the DS-Hexagon bridge and the figure tools for adding ERC coding... the road-block I've hit is that for what ever reason DS refuses to send the model to Hexagon through the bridge for me to do this. If the DS/Hexagon bridge was cooperating then I could try and set things up myself, but since it won't I've had to put out this shout-out for some help...

 

[Ken1171]

You don't need a bridge to get the morphs created. All you need is to create each stage of the morph in Hexagon and export to OBJ. You can then import them back in Poser or DS as a morph target. However, ERC hooking is different in Poser and DS, so you will have to do it twice if you want to support it in both platforms.

 

[theschell]

DS generated ERC's work just fine in Poser as well (been using DS to make Poser compatible content for years quite successfully)... If I recall though DS won't use Poser style morph targets any more though DS can still generate Poser-functional morphs using the bridge... I could be wrong about the morph targets thing...

 

[Ken1171]

The basic idea is that DS doesn't understand ERCs that were hooked up using Poser's Dependency Editor. It will just ignore all of them when imported into DS. The ERC dials are imported, but none of the channels are hooked. That is the info that gets lost when importing Poser CR2s into DS. It's simpler to just do the ERCs in DS itself with the usual "Freeze ERC". I don't know if DS ERCs would work in Poser, but if they do, even better.

As for morph targets, there are indeed issues with Poser because it doesn't support unimesh geometry (models made of a single piece that have many poly groups). However, that is not usually the case with props because those don't have groups and bone rigging. If your tank is a figure rigged with bones, however, that would be a problem coming from Poser to DS because of the above. Poser would split your geometry when exporting morph targets, which would turn them all invalid. DS exports don't have that issue because everything works with unimesh internally.

Nonetheless, I wrote a little program that deals with this. It gets the OBJ exported from Poser and rebuilds it into unimesh geometry, making it compatible with DS. It requires the original unimesh OBJ without morphs to create a profile, and after that it can convert any broken morph targets exported from Poser into unimesh versions that work in DS. I have been using this to create the DS version of my current Poser body sculpt for Dawn. The program rebuilds the broken (split) geometries back into unimesh, recovers the vertex order, recreates the lost poly groupss, fixing these things in both geometry and UV coordinates.

 

[theschell]

The basic idea is that DS doesn't understand ERCs that were hooked up using Poser's Dependency Editor. It will just ignore all of them when imported into DS. The ERC dials are imported, but none of the channels are hooked. That is the info that gets lost when importing Poser CR2s into DS. It's simpler to just do the ERCs in DS itself with the usual "Freeze ERC". I don't know if DS ERCs would work in Poser, but if they do, even better.

As for morph targets, there are indeed issues with Poser because it doesn't support unimesh geometry (models made of a single piece that have many poly groups). However, that is not usually the case with props because those don't have groups and bone rigging. If your tank is a figure rigged with bones, however, that would be a problem coming from Poser to DS because of the above. Poser would split your geometry when exporting morph targets, which would turn them all invalid. DS exports don't have that issue because everything works with unimesh internally.

Nonetheless, I wrote a little program that deals with this. It gets the OBJ exported from Poser and rebuilds it into unimesh geometry, making it compatible with DS. It requires the original unimesh OBJ without morphs to create a profile, and after that it can convert any broken morph targets exported from Poser into unimesh versions that work in DS. I have been using this to create the DS version of my current Poser body sculpt for Dawn. The program rebuilds the broken (split) geometries back into unimesh, recovers the vertex order, recreates the lost poly groupss, fixing these things in both geometry and UV coordinates.

Oh yes... ok I get what you were saying about it being due to Poser specific coding now, and yes, things made using specific features of either DS or Poser will have issues when transferring to the other (was a pain in my back-side when I was regularly creating and selling content).

I can verify that ERC's created in DS with the ERC freeze do work in Poser as all my products were rigged/coded using Studio rather than Poser and I test in Poser as part of my production pipe-line. My private beta-tester also tested in various versions of Poser to ensure cross-compatibility so it's been verified through customer and tester feed-back. It's actually why I stayed with DS as a tool for figure rigging and set-up... I knew I could make products using DS that would be fully use-able in Poser as well...

On the note of vertex issues and split obj's, I'm sadly all too aware of Poser exported files breaking things... If I recall it's best to make sure you have a back-up of your original obj saved before exporting a file from Poser so you can replace the one Poser breaks with one that is intact? It's been much discussed over the years, and I know that it was an issue that lots of users had been asking for SM to fix... We can hope that the Rendo Dev's listen better than SM did!

 

[Ken1171]

There is nothing to discuss - we should never use anything exported from Poser in commercial products. This also means we cannot do any grouping in Poser, forcing this part to be done in other 3D software. The only ones I know of that support Poser/DS poly groups are Blender, Modo, and Lightwave. All others, including all of Autodesk's lineup (3DSMAX, Maya, etc) do not support unimesh. If Poser creates a new OBJ, we just have to throw it away and replace with the original unimesh one.

In a way it makes sense that it's easier to make DS contents to work in Poser than the other way around. Poser has been making an effort to maintain backwards compatibility in every version, so even ancient DS CR2 plugins still work nowadays because of that. Conversely, DS has been changing with little regards towards backward compatibility, up to the point where both platforms have become mostly incompatible. For many years SMS was asked to keep compatibility with DS, but that was impossible to accomplish simply because DAZ has decided at some point to depart from Poser compatibility, and since then it has never looked back.

The most blatant case was when so many people kept asking SMS to support the Genesis platform in Poser, when not even DS1, 2 or 3 could do that. DS4 was rewritten specifically to support a new proprietary and closed platform, so there was no way Poser could support that - ever. DAZ would sue anyone who tried that because it's their proprietary technology. In addition, people seem to forget that the 2 companies were competitors in the same field. It's like asking Coke to sell Pepsi. Nonetheless, we will still see PLENTY of people asking Poser to support Genesis. I used to be one of them, but at some point I've realized what I was asking for.

Nonetheless, you are right - it is easier to start from DS and then do the Poser version. But mind you, Poser's incompatibility with unimesh pre-dates SMS. It's not a bug, but instead a design choice back from the very first version. It's deeply integrated into the Poser's inner works, and changing this would mean rewriting Poser from scratch. Larry Weinberg told me that himself, and I could tell that's nothing to be taken lightly. The Poser core code is ancient, and it shows. They don't want to change it, mostly because it would be a major overhaul, it would take a long time, it would be super risky, and it could potentially break everything else attached to it (all the other "Rooms"). Larry has considered doing this in Poser 12, but those days were gone after the dev team was fired.

Rendo will certainly avoid such drastic actions for now, when Poser is still new to them. However, I would prefer they released Poser 12 with all the many critical bugs FIXED instead of stuffing shiny new features like SMS used to do, keeping the core under the hood broken. Having that said, maybe the chances are that Poser may never support unimesh internally. That will depend on how seriously Rendo will take this. Maybe it's just me, but I believe that Poser will remain in significant disadvantage for as long as it's internally incompatible with unimesh. This alone will keep it incompatible with everything else, not to mention it breaks part of the content creation pipeline.

Sorry this got long. There is no simple way to put it.

 

[KageRyu]

I know the trick and had it explained to me, let me see if I still have the zip/pdfs. Basically it is a combination morph/ERC. The Track movement is a morph, and ERC is used to link it's movement to the movement of the wheels. so they all move together.

 

[Ken1171]

Yes, that's how I think it will work. ERCs can also be used to switch between different stages of the track animation. Chances are that just 1 single morph may not be enough to produce a loopable animation.

 

[KageRyu]

It's 1 morph for each track (2 total if 2 tracks), with ERC to link each tracks movement to it's wheels and maybe a separate ERC to run both tracks together. Me, I would probably put in an extra ERC for left and right turns to have the tracks run in opposite directions as is done for sharp turning on tracked vehicles.

 

[theschell]

It's 1 morph for each track (2 total if 2 tracks), with ERC to link each tracks movement to it's wheels and maybe a separate ERC to run both tracks together. Me, I would probably put in an extra ERC for left and right turns to have the tracks run in opposite directions as is done for sharp turning on tracked vehicles.

In this case the tracks wouldn't reverse each-other for sharp turns... the vehicle/mech I'm working on is a half-track suspension and the turning is handled by stopping one track while the other keeps going based on which way the front steering wheels are turned (it's got road wheels as well as the rear tracks)... Making a right turn would turn the front wheels to the right and would apply the brakes to the right track while the left track would keep turning to pivot the vehicle and vice-versa. I'd planned on tying the track movements to the front wheel stearing and the Drivers steering/braking control sticks in the cockpit...

 

[Ken1171]

One way to make the track animation morph would be to constrain all the track elements into a spline, so they follow it in both direction and orientation. Depending on the size of the track elements, this would need more or less morph target steps to make it loopable. I assume if each step would have to be equal to the length of a track element movement, only 1 step could already make it loopable?

 

[raven]

The M1 Abrams that comes with Poser in Props-Vehicles has moving tracks. Would it be worth looking at that to see how it's done?

 

[theschell]

The M1 Abrams that comes with Poser in Props-Vehicles has moving tracks. Would it be worth looking at that to see how it's done?

I looked at that, but wasn't able to figure out how it was accomplished... there wasn't any specifically obvious clues to be able to work from sadly... and I've been trying to figure the trick out for a couple of years now... lol...

 

[raven]

Ah, shoot. It was worth a try

 

[English Bob]

The M1 Abrams that comes with Poser in Props-Vehicles has moving tracks. Would it be worth looking at that to see how it's done?

Ah, good clue. I'd overlooked that. Just having a quick look at the workings now. The rigging is quite convoluted (understatement alert!) and isn't perfect. If you hide everything except one track and its associated wheels, then operate the appropriate Track dial on the body, you can see the track jumping off the wheels at the top. This would be disastrous on a real tank, but that part is hidden on the model so they can get away with it.

This is because the basis of the rigging is a single morph for each track. The tracks aren't continuous on this model - the top part that's hidden under the guards isn't modelled. The key is that morph, though, and I could see you would have your work cut out making that! For a freebie, if the user was asked to dial in each movement separately, you might get away without the rest of the complex stuff which relies on a host of hidden valueParms that also make the wheels rotate.