Forum Moderators: Staff
Poser Technical F.A.Q (Last Updated: 2024 Dec 04 2:47 am)
Welcome to the Poser Technical Forum.
Where computer nerds can Pull out their slide rules and not get laughed at. Pocket protectors are not required. ;-)
This is the place you come to ask questions and share new ideas about using the internal file structure of Poser to push the program past it's normal limits.
New users are encouraged to read the FAQ sections here and on the Poser forum before asking questions.
Actually, if you think about this is already a feature embedded and probably frequently used in Poser's Group Editor. Hrm, perhaps. What I'm wondering is now exactly one declares this. Will the 'g' declaration accept more than one argument? Because simply defining the same face more than once would be declaring a new face (poly), according to the spec, even if it shared all the same vertices.
I had to check this, but according to my (old) copy of the spec, this is exactly the case: ******************************************************* All grouping statements are state-setting. This means that once a group statement is set, it alpplies (sic) to all elements that follow until the next group statement. This portion of a sample file shows a single element which belongs to three groups. The smoothing group is turned off. g square thing all s off f 1 2 3 4 ... Syntax g group_name1 group_name2 . . . Polygonal and free-form geometry statement. Specifies the group name for the elements that follow it. You can have multiple group names. If there are multiple groups on one line, the data that follows belong to all groups. Group information is optional. group_name is the name for the group. Letters, numbers, and combinations of letters and numbers are accepted for group names. The default group name is default. ******************************************************* Bill
That's an interesting thought, and well worth looking at, but my first thought is that I believe that Poser splits the mesh polygons and vertices into seperate body part meshes (with possible vertex duplication) according to the body part specific groups. Part of the reason for this specific partitioning (if it exists) may well be precisely to avoid any conflicts in poly membership to multiple body part groups. In this case, I would expect that either: Poser just takes the first group label and ignores any other labels, at least for this part of the processing, therefore it's "first come first serve" scenario and the poly only becomes part of one body part. or Poser duplicates the face in each of the new body part objects that it encounters an association with. Still, it would be interesting to see what results you come up with. Bill
It's my belief that the OBJ spec is just a source from which Poser has "borrowed" a convenient mesh format. As far as I know, only v, vt, g, and f are used, along with usemtl when importing. However, note the use of the terms "belief" and "as far as I know". Beliefs like that can sometimes be overturned. :)
Poser does infact, in my experience ingore secondary, tertiary, and so on group assignment for a polygon set. As a matter of fact, let's say you label a group as followed: g head lips If you did that for let's say, the lips in the P4Male, and saved a new cr2 pointing to the new geometry, you would notice that the head itself is still intact, and should (I believe) handle morphs just fine. However, you will also notice when clicking on the head and opening the group tool that a subgroup called lips exists.
Way back when Zygote released a pair of models with the full obj hierarchy in place from Wavefront. This was a mistake on their part, as the final step was supposed to be removal the overlapping groups, many of which are not available in poser. IIRC, I'm the one who pointed out to them the wacky OBJ files. They were loadable in poser, but acted sort of squirrelly. They also had VAST rsr files. They fixed them and shipped out ones with the multiple groups removed. I have the ones with all the groups around somewhere, but they are only of academic interest. The use of multiple groups is one of the tricks that zygote/DAZ uses to make their models, particularly morphs. This is also why you will probably not get DAZ to ever send you their internal use OBJ files.
Sorry to be late here, but from my experience, Poser doesn't particularly ignore any of the group assignments in an OBJ file. What it does do is correlate actor/prop declaratory names (geomHandlerGeom 13 head) to a matching OBJ group. I've seen this (literally): g owl wings g head owl and, dangnabit, Poser finds 'wings' and 'head', order-insensitively, to match the body part groups. Beware what you assume... Kuroyume
C makes it easy to shoot yourself in the
foot. C++ makes it harder, but when you do, you blow your whole leg
off.
-- Bjarne
Stroustrup
Contact Me | Kuroyume's DevelopmentZone
digs into her bag of tricks more deeply, and notes that while Poser does support the entire spec, it doesn't have active handles for everything listed. Poser 5 does import Rhino exported nurb meshes -- ie, with all them fancy splines and stuff. How much it uses I don't know. I'se only a fifth grader poser hacker...
thou and I, my friend, can, in the most flunkey world, make, each of us, one non-flunkey, one hero, if we like: that will be two heroes to begin with. (Carlyle)
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.
Attached Link: Wavefront OBJect File Format Specs
I was reading through te Wavefront OBJect file format specifications and came across something VEEEEERY interesting... (emphasis added) *Faces and surfaces can be assigned into named groups with the "g" keyword. This is used to create convenient sub-objects to make it easier to edit and animate 3D models. **Faces can belong to more than one group.*** What implications could this have on Poser model building? When a poly can exist smultaneously in two different groups? There is some other interesting stuff in there, that might crash poser or might be properly read by poser, like 'cstype' and 'surf' -- I don't know if any experimentation has been done with these.