Forum Coordinators: RedPhantom
Poser - OFFICIAL F.A.Q (Last Updated: 2024 Nov 18 10:25 pm)
That is pretty clever, if I understand you right. What you're thinking of distributing is:
If that's right, then yes I don't see why that couldn't be distributed. Would be much better if you could automate a way to load the arm and shoulder JCMs from the original DAZ CR2 if the user has it (so you don't have to distribute them but the user can still load them).
It's not that the groups are getting imported at all, but rather if you look at a cr2, in the actor declaration section (roughly the first third of the file) you'll see the figureResFile tag which will point to an obj. The obj's groups are then referenced in the individual actor blocks that follow. If you replace the lines that reference groups within the figureResFile obj with the objFileGeom statement and within that statement, reference your new geometry, then when the figure loads in it will ignore the original geometry and grab the new one. If the new has been built so that it's boundary vertices match up with the body parts both up and downstream, then Poser will weld them all together as though they were from the same original obj file. I really, really wish there were a way to just use multiple figureResFile lines so that you would just point to a an entire second obj with groups and access those groups, but from what I can tell there really isn't and it probably has something to do with the design of the file format and it's ability to save multiple figures together. For that matter, you CAN save two figures together and manually edit the cr2 to weld things across the two figures, but if you try to save it out Poser will spin it's head all the way around and spout pea soup at you. As it stands, to do something like the Lamia, you'll have to save out EVERY new body part as it's own obj and reference each of them in the actor declaration section, one by one. It's a little bit of a pain, but could be a lot worse and the results you can get with it are, I think, very much worth it. -Les
Thanks! I think I've got it now.
So instead of, say
actor hip:1
{
storageOffset 0 0 0
geomHandlerGeom 13 hip
}
you would write something like
actor hip:1
{
storageOffset 0 0 0
objFileGeom 0 0 ":Runtime:Geometries:MyFolder:alt_hip.obj"
}
for each modified or added actor?
That's good to know. It's annoying that every actor needs its own obj file, but it shouldn't be too hard to write a little program that splits the base mesh up into the required parts.
-- I'm not mad at you, just Westphalian.
That would be neat. You are aware that DAZ3D does have a Lamia morph available for purchase. Link:
http://www.daz3d.com/i/3d-models/-/creatura-serpenta-for?item=5984&_m=d
From what I can tell about their product, it doesn't work quite the same way as the development discussed in this thread. I'm guessing from the description that it is a conforming figure with transmapping to "blend" it to the host figure's torso. Not having the package myself, I can't say, and frankly I'm glad i don't: I prefer not to be too influenced by other products like that, especially when a development such as this is more experimental to begin with. I'm sure there are plenty of uses for the Serpenta product and many very satisfied customers. FYI: their package is far, far, far from being a "morph". There is no way to "morph" legs into something like this short of illogical theoretical math and/or black magic (same thing? maybe!). Also, just to clarify, this thread is about the method, not the product, but I'm sure they'll appreciate the plug. :p -Les
I certainly think so, and not only that, but it offers a different method of distributing such developments. There are some really crazy concepts I have in mind that can really bridge the gap between the crazy monstrosities I enjoy making and the dedicated V4 users. I could see this method opening up a whole new end of the market and I would love to see some real innovation come of it. -Les
Actually, splitting up the base obj into seperate parts doesn't renumber the vertices at all in terms of morphs, at least coming out of Maya. If you think about it, a group is a group is a group, whether it's within the context of the entire obj or as a single obj of it's own. For that matter, you can even use geom switching instead of the objFileGeom tag and morphs work there as well. We've actually released products before that had geom switching for large portions of the figure, with morphs included for both the original geometry and the geometry that changes with the switch. It works really logically too: when you have one geometry option turned on, the morph data that is applicable to the geometry will work. When you switch it, obviously that morph no longer works if the new geometry has a different vertex count, however a morph that is designed for that geometry won't work with the previous one. I think there is a lot of misunderstanding in the Poser world about what is and isn't or works and doesn't work as a morph and the Poser file format itself is probably the source of a lot of this. You'd be really surprised at the number of things you can do inside there. Point being, we've successfully done both the objFileGeom and geom switch method and had morphs work out fine in both. I've found both methods to be really handy and offer a world of development options that seem relatively untouched out there. You can be we'll be doing our best to change that because it's not just my goal to make cool stuff, but to get back to really pushing the envelope of what people can expect out of Poser content. -Les
Quote - Would be much better if you could automate a way to load the arm and shoulder JCMs from the original DAZ CR2 if the user has it (so you don't have to distribute them but the user can still load them).
Rebekah just reminded me of your post.... for the record, the V4 cr2 contains readscripts for all that stuff so the method I'm describing actually does include all the jcm's and for that matter all the empty channels and little bells and whistles included from the get-go. Essentially what it allows us to do is add entire new structures and geometries onto the figure while keeping the rest of the figure and it's functionality 100% true to it's original version. This will allow a user to have this drastically customized version of a figure but still be able to use any kind of injections on the parts that remain from the original form. -Les
Perhaps in part. Did you see this thread that I posted in early this morning? In it I posted this example of injecting a new geometry into an existing actor:
{
//INJ P4HeadGeom2.pz2
version
{
number 3
}
actor head
{
storageOffset 0 0 0
objFileGeom 0 0 :Runtime:Geometries:femaleHeadOnly:femaleHeadOnly.obj
bend 0
}
}
Of course, rather than injecting it from a pz2, you can edit it directly into the cr2. As I don't have any modelling skills, I have not really been able to take advantage of these methods.
As an alternative to using "objFileGeom", you can use a "geomCustom" block to carry the geometry directly within the cr2, so that no extra obj files are necessary. Using "geomCustom", works a bit differently to using "objFileGeom" in that if you save a file where "geomCustom" is used in any actor, Poser(above P4) will write out a new obj file for the figure, and place it in the same folder as the cr2 is saved to. I offten look at this as a disadvantage, but perhaps in some circumstances this could actually be useful. When using the original 'figureResFile' in congunctoin with 'objFileGeom' I am not sure if the whole 'figureResFile' is retained in memory, I guess it must be. The creation of a new composite obj out of the 'figureResFile' and 'objFileGeom' would resolve this problem if it exists.
Another neat trick that does not seem to be well known is that you can use a pp2 or cr2 file to inject a whole new actor into an existing figure. The file attached at the top of this post will inject a new actor into any figure that has a "head" actor. The new actor will be named "Head Cube2" and be a child of the head.
Here are the secrets of making this work. Start with a pp2 file in which the geometry (either objFileGeom or geomCustom) is in the right location relative to the figure it is to be injected into, then edit it as follows. The file should not contain a 'doc' or 'figure' section, if it did it would just be a prop or figure. The actor must be addressed as "actor" not "prop". The parenting line should use 'smartparent', (Poser will take care of the addChild stuf in the figure block). You may or may not want to edit the 'customMaterial 1' line to 'customMaterial 0' so that the actor looks for its materials in the 'figure' block. A downside to this method is that as you can't include a figure section in the file, you would need a separate pz2 file to inject joint parameters and welding for the new actor.
I can see where you're going there. I'll definitely have to tinker with some of that. From our experience, some of what you describe might have issues when trying to save it back to the library or as a pz3, but it's worth looking into again just to be sure. I've never been a big fan of using the geomCustom precisely because it writes new geometry out and I've seen it act really strangely with welding issues when loaded. Not that it does that every time, but it does happen so you have to be really careful. Also, one of the big pluses I find to the method I outlined at the start of the thread is that it negates the need for any kind of injection, but rather simply gives a library entry that to the end user is transparent and doesn't require any extra data to be injected later. I can definitely see where some of your suggestions could be useful though I definitely prefer to veer away from anything that has to do with injection in favor of giving the user a "one click" solution. -Les
Quote -
The beauty of this technique is that it allowed us to create a cr2 that is true to the V4 distributable cr2, but simply replaces sections with new joints and calls to original geometry that are loaded and welded by Poser on the fly.
Hmmmm, quite interesting indeed.
When Poser welds on the fly did you have to match the vertices of your tail up to the vertices of the body parts being replaced?
Hope you understand my question, let me know if you don't and I'll try another angle.
Great work by the way!
Comitted to excellence through art.
I'll look into it definitely... making no promises at the moment because I have revisions on some old contract work that is taking up some time this week, but I certainly want to do it and video tutorials on a number of other things as well. If you have any suggestions on the best methods for that, or could post a link to some good tutorials or software for it, I would really appreciate it because I have tried and tried for a long time and never been happy with what I've gotten. Been wanting to do a whole series of video tutorials on my Maya-Zbrush-Poser workflow but just never got results I was happy with.
Oh and Darkedge--- did you send email my way? If so, I never got it, so could you try again? Thanks! -Les
I've tried Cam Studio a number of times because it would supposedly do video screen cap while also recording audio but it never worked out quite right. What I would like to do is be able to get not only the video of what's going on but a voice over while I'm doing it so that it's more interactive and intuitive. We'll see... maybe I can use Fraps and be grabbing the audio via some of the recording gear we have here... just have to get down to really tinkering with it sometime soon. -Les
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: Attacking Lamia
Ok, not sure if this post will get me into trouble, but here goes....Been working on something that I thought might spur some interesting conversation. See, I've been thinking for a while about ways to add all kinds of extra or different parts onto existing figures in a way that allows that addition to be distributable without any encoding. Now, maybe I'm just stumbling onto something that has been done before and if so, just ignore this, but what I found, I thought, was pretty darn cool. Since you can, in theory, distribute a V4 cr2 so long as it doesn't contain any geometry data or anything that would preclude the necessity of V4, I decided to start tinkering with things a bit. What I wanted to do was turn V4 into a Lamia, basically a woman whose legs are replaced with a snake tail. Whle I know there are a couple of different solutions out there for this, I wanted something that was 100% connected to the mesh with nothing to hide any seam between the tail and hips. If something like that is out there, that's fine, but in the course of thinking about it, I came up with an approach that actually worked out really well.
Now, just taking a V4 mesh, lopping off the legs and adding a snake tail isn't all that hard for an experienced modeller. Cutting up said tail and rigging it isn't that hard either, nor is directly merging it and a v4 mesh. The encapsulated description of how to do this is simple: once you've added the tail to v4 and removed the legs, import the whole thing in poser, then go into the setup room where you then apply a V4 figure from the library, delete the bones for the legs, draw in the bones for the tail, name those bones, return to the pose room and save it all out. Sure, there are more little specifics than that, but that's the gist of it.
The tricky thing is this: if you wanted to distribute that, how would you do it? The new cr2 you would save would have inside it all the stuff that the v4 cr2 readscripts into it making it undistributable. So, here's what I came up with...
First, we saved a cr2 of that figure after tweaking all the jp's and adding easypose for the tail. Next, we went into the cr2 and removed the geometry references for all the tail parts so that if we loaded the figure in, there would be nothing showing up for the hip or tail pieces, but their bones would be present in the dropdown menus. The reason for this will be apparent shortly...
Next, we opened a copy of the actual v4 cr2 and removed all the entries for the leg parts. Then we openned alongside it a copy of the newly created cr2 with the tail rigging. We then copied the hip and tail parts from the new cr2 and pasted them where necessary into the copy of the v4 file. Of course, these call a different geometry than is referenced at the beginning of the v4 cr2 which poses a rather immediate problem. Here's how we dealt with that and why we removed the geometry references for all those tail parts....
Since a Poser file can't really reference more than one geometry for the "figureResFile" line, we decided to sidestep that by using the "objFileGeom" tag in the actor section to call the tail geometry. The annoying part of this from a development standpoint is that, unless I'm mistaken, only in the "figureResFile" statement can Poser read the groups from an obj. The way around this was to export each group from the tail geometry and then list them, one by one, with the "objFileGeom" call in the actor section for each body part.
The beauty of this technique is that it allowed us to create a cr2 that is true to the V4 distributable cr2, but simply replaces sections with new joints and calls to original geometry that are loaded and welded by Poser on the fly. I'm not sure if many other vendors are creating anything using methods like this, and if so I'd love to see what they're doing. If not, then maybe this concept is something that could prove helpful to others. -Les