importing a created object. obj file.

It's been a while since I imported an object so...

when importing a created object(shoes) how does one go about doing so, so that the shoes are left and right and not one big object/blob? I did it before; I know, but it's been a while.

right now I am importing the obj file; I run the EDIT->OBJECT->TRANSFER UNTITILY... and nothing happens; the shoes are one item and I can not select the Actor, can use the panel on the right to move parts of the actor that way.

maybe because of 4.10. it was 4.9.   

mistake on DAZ; you can't go from 4.9 to 4.10. 4.99 yes not 4.1.; or 4.09 to 4.10.  but daz had 4.9 next number is 4.99 or 5.0 .

Comments

  • Version numbers are not dec9mals, they are four integers separated by dots (as is the common going on universal practice in software) - 4 dot ten dot zero dot 123.

    Do the shoes line up with the figure in its zero pose and shape? Transfer Utility should work then, though some more work may then be required to tidy up (especially for heels or platforms).

  • If the shoes were made as a single grouped object, they will import as a single object. 

    Use the Geometry Editor to select one, hide it, then delete it. Export the remaining one. Repeat the process for the other one.

     

    As for DS' version numbering, just be glad it's not Skyrim mods on the Nexus, with version numbers like 4.1.0.3a, b, c, d, e, f. Honestly it's ridiculous. Just go to 5. It's not like there's a shortage of numbers.

  • artxtapartxtap Posts: 158

    it's been a year maybe close to two since I touched daz or blender. so; many thing have been forgotten.

    xmas vacation these days.

    I remember this gym shoes had lettering on them so the lettering had to be fixed, because they were created by mirror, and looks like that is where they were left off, the texture was fixed but the shoes were never save as a wearable asset.

    they are not the best shoes (2nd or 4th try at content creating), but good old free regular shoes were hard to find.

    I know it was done in 4.9, because I have a render of the bad mirrored[text] shoes.

    the EDIT->OBJECT->TRANSFER UTILITY has a SMART LEFT/RIGHT FILTERING check box and I have it checked, but maybe it's not working?

    and again after the object transfer the Actor can not be selected with the mouse, even after the shoes are deleted. and the shoes can not be FITTED to the Actor, that option is available when you right click after OTU.

    oh, in blender it looks like the parts that make up the shoes can be selected. on both the right and left shoes.

    ren_sho_small.png
    286 x 357 - 76K
  • No idea on the Transfer Left/Right thing. Do the shoes have to come in with L/R data embedded? Is there a Blender to Daz script you have to run when you export? 

    It's odd that the actor cannot be selected with the mouse in the main view. Then again, I've been having an issue with the Geometry Editor where it stops selecting polygons, and I have to click off and back onto the figure in the Scene view to get it fixed, so maybe this is just another bug?

  • The n.n.n.n convention was (mostly) invented by IBM way back in the 1960s-70s. I was there.

    As correctly noted above, the individual numbers ARE integers absolutely unrelated to each other in any mathematical sense, except that they usually increment. Assume it is like q.h.w.p where each of those means the following:

    The first number represents a VERSION, each increment is either a rewrite or at least a MAJOR increase in functionality. Each version is defined and differentiated by its functional specs.

    The second number is a RELEASE, each increment is an improvement or correction to existing functionality in the current version, or a minor enhancement, not always driven solely by bug reports, but usually as a result of customer feedback.

    The third number is a FIX LEVEL, each increment is an arbitrary aggregate of individual fixes to bugs previously reported by customers in the current release, what IBM calls APARs. This is sometimes called a CANDIDATE build.

    The fourth number wasn't there originally, it has been added since, in those days IBM never exposed this level of granularity, and rarely does today. It is usually used to denote individual nightly or weekly development builds.  Any one of these builds can be promoted to a CANDIDATE build, or even to a RELEASE, but usually only if the build was predefined (by management) as such. Some other uses for this fourth number are also found, but are difficult to pin down as to exactly what they are.

    There is a "vanity" component to all of it. Who knows, one day someone might see fit to add a fifth number, just to look important.

    (34 years in software with IBM)

  • "But that's the way we've always done it" is not the same as "this is the best way".

    It's certainly better than calling every little bug-fix and general service patch a full version-step, but it's a bit late in the game to say "oh, yeah, well, see, ....uhhh... all those 4.9 revisions were actually 4.0.9....yeah. that's the ticket...".

  • SpottedKittySpottedKitty Posts: 7,232

    all those 4.9 revisions were actually 4.0.9

    You're missing the other point made; these version numbers are not (and never were) decimal digits, there's nothing stopping the sequence going from "four point nine" to "four point ten".

  • ChoholeChohole Posts: 33,604

    The n.n.n.n convention was (mostly) invented by IBM way back in the 1960s-70s. I was there.

    As correctly noted above, the individual numbers ARE integers absolutely unrelated to each other in any mathematical sense, except that they usually increment. Assume it is like q.h.w.p where each of those means the following:

    The first number represents a VERSION, each increment is either a rewrite or at least a MAJOR increase in functionality. Each version is defined and differentiated by its functional specs.

    The second number is a RELEASE, each increment is an improvement or correction to existing functionality in the current version, or a minor enhancement, not always driven solely by bug reports, but usually as a result of customer feedback.

    The third number is a FIX LEVEL, each increment is an arbitrary aggregate of individual fixes to bugs previously reported by customers in the current release, what IBM calls APARs. This is sometimes called a CANDIDATE build.

    The fourth number wasn't there originally, it has been added since, in those days IBM never exposed this level of granularity, and rarely does today. It is usually used to denote individual nightly or weekly development builds.  Any one of these builds can be promoted to a CANDIDATE build, or even to a RELEASE, but usually only if the build was predefined (by management) as such. Some other uses for this fourth number are also found, but are difficult to pin down as to exactly what they are.

    There is a "vanity" component to all of it. Who knows, one day someone might see fit to add a fifth number, just to look important.

    (34 years in software with IBM)

    If you want to know what each component in the Daz Studio version number is (Major.Minor.Revision.Build), look at the documentation... http://docs.daz3d.com/doku.php/public/software/dazstudio/4/referenceguide/scripting/api_reference/object_index/version_dz#detailed_description

Sign In or Register to comment.