CajunBeauty posted at 1:33PM Wed, 01 April 2020 - #4385046

How come there are free products to get G3F and up into Poser, but not for bringing in Poser only figures into Daz? I have a chance to get a cute character for free, but he is Poser only and I can't afford Poser to use him. This brings many sad days for artists like me.

It's quite simple really, it's called business, DAZ have a captive audience, the only figures/content they care about us using is their own.

They don't have any problems with us using their products in other software, as they have made it relatively simple to do just that. The problem is going the other way, the PZ3 Importer plugin can't see P7+ rigging, some DAE I have and so far every FBX I have explode if there are any bones in the files.

Basically if you want to use 3rd party figures in DS you need to start with the mesh, and rebuild it from the ground up using the tools built into DS, and for about 90% of the user base a total nightmare.

KK most of them should be, after all the system is meant to be conformers that you can drape aka hybrid, the main problem is far too many people thing that rigging in DS ends with the Transfer Utility, so end results really depend on how much work the content creators are willing to put into the rigging.

Probably a typo Sam, there are two textures called MakeupTrans one JPG the other PNG

W10 has a different folder structure for "Users/Public" than older versions of windows, if the devs are still using W7 for instance then they wont have any idea it's been changed, that's probably what's causing that error.

an0malaus posted at 4:00PM Mon, 12 August 2019 - #4359139

My understanding is that geografting is much more involved than just geometry switching, since it involves welding seams between the geograft and the parent actor. Certain facets of the parent must be hidden where they overlap the graft and texture UV maps must be interpolated if the graft has higher UV resolution than the replaced area of the parent actor's UV map. The Genesis figure range's genital props are geografted to the hip, but are not a complete hip replacement.

Not as much as you might think, the main difference is in the two figure systems, I said what a Poser figure was in my last post.

To keep it simple in DS a figure starts as a "Null", an anchor point that lots of stuff can be parented to, parented to this null is the mesh, doesn't even need to be grouped, just welded. Also parented to the null is the root node of the skeleton, the bone parent/child takes care of the rest, this basically means the mesh and skeleton are kept separate, so unlike Poser you can work on as much or as little of the mesh as you need.

About a year ago NetherWorks explained to me that a Poser figure can be setup in a very similar fashion to a DS figure, if that's the case then probably with a "bit" of help from Python, Poser could have a very similar system to Geo-graft.

I'm a DS abuser rather than a Poser abuser so you'll have to ask some of them if any of that last bit is possible.

Penguinisto posted at 12:20PM Sun, 11 August 2019 - #4359114

SamTherapy posted at 2:48PM Sat, 10 August 2019 - #4359096

FWIW, I tried to export LF's hip to take it to Wings for a (no pun intended) fiddle around. For some reason I couldn't get it to load in. First attempt crashed Wings, all subsequent attempts loaded nothing at all. Couldn't be arsed to try again but maybe I'll take a look some other time. Meanwhile, best of luck in your quest.

That brings up a fun technical question... can Poser do something similar to geo-grafting? What I mean is, make a conformer, slave it to the hip/pelvis, 'lift' the texture off the torso, etc...?

It's called geometry switching, and it's something Poser has been doing more or less from the start, basically a figure in Poser is a collection of props bolted to the bones of a skeleton, and all geo switching does is replace one or more of those props for new props.

@ tguncss, auto conforming is something most non DAZ vendors go to great lengths to avoid, because if you want to avoid CrossTalk then you can't have more than one figure in a scene.

The problem is the ERC code (valueOpDeltaAdd, Figure, BODY, PBMThighsTone) you listed, it basically points to the figure with the internal identifier of 1. So if you have 2 V4's in your scene then they both have the identifier of 1 (it's in the CR2), with the first one loaded taking priority. So any auto conformers loaded onto the first V4 will take the dial settings from that figure, but any auto conformers loaded onto the second V4 wont take the dial settings from that figure, instead it takes it's settings from the first V4, which is why it's called CrossTalk and why most users curse it's very name.

In a nutshell, Posers figure handling system and it's internal identification system, are garbage and should have been tossed in the trashcan at least 15 years ago.

ROFLMFAO

Got one of them myself, finding my user name on it threw me at first, but as I don't have a web cam it quickly dawned on me it was fake.

Probably should have just hacked his bit coin address but I deleted the email before that thought had dawned on me.

Auto conforming - Super conforming - Crosstalk (go on swear ya know want to :P), it's called different things depending on software and age.

Basically the valueParm sections in the outfit has to exactly match the names of the valueParm sections in the base figure, one example from the MidiSweater.cr2 is "valueParm PBMGlutesSize", this is identical in name to the valueParm in V4, as a result V4's valueParm dial will take control over the valueParm in the outfit once it's conformed to the figure.

Problem is that Poser has a really crap way of identifying the components of each item you load into a scene, they get added into the CR2 when you save it back to the library, these identifiers will stop the item "auto conforming" if they don't match, they are also the direct cause of Posers dreaded CrossTalk.

Richard, no point in bug reporting this, take a look at the feet in both images, they are posed, if that is how G2F is loading then several files have either been overwritten since they were installed, or the OP has installed something that has changed/replaced them.

The following files are the ones that cause me problems.

Atlantis_stargate.obj - appears to load but nothing shows in viewport

event_horizon.obj - crashed my graphics drivers at the same time as crashing DS

OBJ08_transporter.obj - crashes DS due to garbage and partial face data

storage_room_wall.obj - crashes DS due to garbage and partial face data

I've gone through every .obj and most of them have garbage of some sort in them, not enough to cause loading issues but it's there none the less, and the cause of all this, UVMAPPER, it's adding junk into the files. The partial face data in two of the above files doesn't come from those mesh, UVMAPPER is holding onto data from a previous mesh, and adding it along with all the garbage when you save out the current mesh.

Having said all that I have gone through every .obj and cleaned out all of the garbage, so it all now loads into DS (except for the Poser primitives used in the PZ3, as I don't have any of my Poser stuff installed).

Right back to the OP.

Exporting all of it from Poser is a bad idea, as you now have a single mesh instead of multiple mesh, that will make setting up cameras and lights a pain, as you won't be able to hide walls like you can if you loaded the Poser files, especially when you realise that Poser lights and cameras are a waste of HDD space to a DS user.

As for textures, the settings in an .MTL file are basically the same as P4 material settings, as a result a lot of the textures used in the material room won't show up in an .MTL, DS has the exact same problems as it can only see the P4 material settings in a p5+ material file.

One main issue with this item is the large amount of texture tiling going on, Posers U & V scale is a P5+ setting and as such wont show in an MTL or in DS. Studio does have texture tiling, iirc most of the shaders people use in DS have it, it just doesn't use the same system as Poser.

Horizontal Tiles = 1 divided by U_Scale

Vertical Tiles = 1 divided by V_Scale

If this is the Atlantis gate room in the freestuff then forget what I posted in my other post, a couple of the .OBJ aren't right and either aren't loading any mesh or are crashing, and not just in DS, the OBJ08_transporter.obj crashed Hexagon.

Checking a couple of the files in a text editor shows that there is garbage in them, not sure if the garbage has deleted any of the polygon data from some of the bad files, but it's mangled the data for roughly 20 polygons in OBJ08_transporter.obj, and it's that mangled data that's causing the crashes.

Knowing Poser's mesh handling system it hasn't even seen the garbage, and loaded the mesh minus any missing polygons, however even it wont have liked the mangled polygon data in OBJ08_transporter.obj, and will have either not loaded the mesh or only loaded part of it.

It's already in Poser format, so just loading the PZ3 from within DS will get all of the mesh loaded, getting it to look even remotely similar however will be a total nightmare, DS can't read anything in a Poser material setting from the shaderTree line, so the few textures it can load from the P4 settings will make it look crap, basically you are looking at a total rebuild of every single surface setting using DS shaders.

Even using an .mtl or fbx or dae wont help, mtl has pretty much the same settings as the P4 materials, and fbx and dae importers in DS mean they aren't much better.

It's called the Shader Mixer in DS, and we have had it since DS 3.0

It's something that's been happening since DS 4.0, the "default value" of the morph is set to something other than 0.00, as a result the figure always loads in with that morph pre-dialed. Some times it's the creator of the morph that's made the mistake, but just as often the end user has some how managed to change the "default value".

Oh and "currently used" only shows dials that have been spun to something other than the "default value".