Quote -
I tend to suspect that e-frontier was primarily wanting to use Poser as a vehicle by which they could get Shade into the US market in a big way.  But what happened instead was that while Poser itself remained just as popular (& growing) as it had always been -- Shade just didn't take the US by storm.

To be honest, Shade was one bad-assed mofo of an app suite for its price range back then. Seriously - it was goooood insofar as getting some sweet results out of basically nothing.

Then Silo showed up. Then Modo showed up. Then e-on came out with Vue5 (to mixed results, but still...).  Then McMeel got it's sh!t together and came out with a version of Rhino that actually lasted more than 30 minutes without crashing. Then Eovia did some really neat stuff and made Carrara 5 a damned sweet app to go with their already sweet renderer.

Point is, all the sudden... who is this Shade thingy and why should I bother spending any money on it? Hell, I still have a copy of it that came as part of a P6 deal and I never opened or installed the thing.

Anyrate - call that prediction one that was killed by a huge curve ball of events flying in formation.

---

As far as conspiracy theories and such? There's this nasty little thing called confirmation bias that you get to fight against. Me, I got no dog in any fights here -- at least not anymore (I've gotten too old and cynical for most of them, and not enough spare time to really get down and bother with the rest of 'em). So, whatever I say, take it with a pinch or a block of salt, as desired. :)

--

Quote - It took nearly ten years to arrive at Poser 4 ProPack - and that was with a development team in a company over a good portion of that time.  That and the fundamental paradigm of Poser can't be maintained but only emulated in other applications.  At least DAZ could build from the ground up and use whatever methodology was closest to Poser.

True enough - I was thinking more along the lines of breaking it down technically.

DAZ approached the Poser end from the files and the behaviors. That is, you look at a poser-specific file and go "I want that to do 'blah, blah, blah' - and the file to make it do that has 'bleh, bleh, bleh' in it - how do I best make the second give me the first?" Meanwhile, Taylor Wilson laid one hell of a foundation by simply looking at the goals of each feature and determined how best to get there natively using what was at hand.

There's no Poser emulation at all in D|S' engines after the data is read-in from the file and filtered through import - trust me on that one.

Quote - In my case, there is a virtual pantheon of obstacles to navigate so that the emulation works in the hosting application.

I don't know exactly what behaviors you're wanting to emulate, but the files' ASCII format and a solid knowledge of what each field does in that file goes a long way, yes? All you would really have to worry about (assuming that this is an external app and not Python or a plugin) is insuring the results are in a format that Poser can understand on the data's way back into it.

If you're emulating Poser it full-on? Err, please don't. Do What Thou Wilt instead, after you've read the critter in, and only concentrate on making the results into something that Poser can understand without undue stress. If you're trying to emulate every behavior in Poser along the way, you'll end up with a lot of the same headaches... but I could be reading this all wrong, and prolly am, since I don't know hardly anything about what you're trying to accomplish.

--

/P