Sun, Dec 22, 5:30 PM CST

Renderosity Forums / Poser - OFFICIAL



Welcome to the Poser - OFFICIAL Forum

Forum Coordinators: RedPhantom

Poser - OFFICIAL F.A.Q (Last Updated: 2024 Dec 20 7:20 am)



Subject: Weightmaps vs Groups question


colorcurvature ( ) posted Thu, 19 January 2012 at 3:52 PM · edited Fri, 26 July 2024 at 9:07 PM

Hi,

I have been away from Poser a bit due to workload. Yesterday I was thinking: If there are weightmaps .... why are there at all actor groups? After all the assignment of a poly to an actor is identical to just a weightmap entry with 1.0.... so... why not get rid of all the groups, and use weightmaps for topological assignment of vertex to bone.

Does this already work? I heard about single group meshes earlier, but do not know how that evolved.

Second: Why not have morph targets for rigging weightmaps? If I remember, there was/is a valueAdd/Sub/Mult etc. stack for joint spheres... so its basically all there already. If we could ERC the combination of weight maps (slave that to dials), we could use that for further improving the genesis-i-fication of figures. It would ENTIRELY remove the need for a neuter base and treat all extremization morphs equally as an unmorphed base.

But maybe that all works already and I just dont know. It would be cool this way, the whole grouping issue could disappear. Grouping would be dynamic and ERCable... and so would be the rig. Hm.Hm.

 

 

 

 


LaurieA ( ) posted Thu, 19 January 2012 at 5:19 PM

LOL..I like how you think out loud ;).

Laurie



Cage ( ) posted Thu, 19 January 2012 at 7:00 PM

According to phantom3D, the actor divisions are actually better to rig.  As I understand it, they also split up the weight maps in a way that somehow makes more sense internally and functionally.  :unsure:  They do split up morphs.  Every morph would need to cover the entire figure geometry, without the actor division.  Without the actor splits, a Python script would have to iterate over the entire mesh to process a few vertices in what is currently one actor.  :scared:  In fact, get rid of actor geometries and huge parts of Poser's Python API would need to be expanded or revised to accommodate the new setup.

But keeping them means keeping the welds, and the welds are a PITA and a mystery.  :lol:

Apparently the single skin figure type is intended solely for export as a certain weight-mapped format.  Or something.  Maybe shvrdavid will happen along and explain it again.  Anyway, if you try converting a figure to single skin using the menu option, you'll see that bulge maps apparently stop working, among other things.  I guess that export format doesn't support bulge weights, so those aren't supported in single skin.  Very limited utility, that single skin format has.

One could make a single mesh figure using body handles for the skeleton.  That could work, AFAIK.  But you'd run into the potential problems I noted above, and probably others.  :unsure:

===========================sigline======================================================

Cage can be an opinionated jerk who posts without thinking.  He apologizes for this.  He's honestly not trying to be a turkeyhead.

Cage had some freebies, compatible with Poser 11 and below.  His Python scripts were saved at archive.org, along with the rest of the Morphography site, where they were hosted.


colorcurvature ( ) posted Fri, 20 January 2012 at 12:49 AM

Hm. you are rightIguess it would not be very backwards compatible. However, with regard to performance, one could query the figure for an actor map, asking which global vertices the actor map currently containes. t wouldbring another indirection, but one wouldnt have to process the entire figure - only the verts tha belong to the current actor map. bulge, hm, so bulge is not defined byjoint settings only.. i shall look out for shrdavid. We need anopensource cr2 interpreter :D 


Privacy Notice

This site uses cookies to deliver the best experience. Our own cookies make user accounts and other features possible. Third-party cookies are used to display relevant ads and to analyze how Renderosity is used. By using our site, you acknowledge that you have read and understood our Terms of Service, including our Cookie Policy and our Privacy Policy.