Back to those "neater ways". I think that I understand the basic principles of edge loops, etc, but applying them in a practical situation is another matter!

EnglishBob: that link's great (you won't remember, but you sent me there in November last year from the "WIP-Modeling a Bellydance Costume Grp. Project" thread over on the DAZ forums).

Following on from that I've looked at lots of stuff about poles, edge loops, quads and triangles. I think I understand the basic principles. One of the simplest, most enlightening things I read was this one, Keep it simple. Four verts good, three verts bad...usually, and it's the advice I try to follow.

However, I spent a long time trying to use quads to join the square parts of this model to the rounded parts. But every approach I tried seemed to add unnecessary complexity to the model. That's why I went with the triangles.

But I'm intrigued - it must be possible to do with quads?

"Check your normals" - sound advice! I got caught by that one very early on, so I now usually recalculate normals before saving my work / exporting my .obj. Having said that, those problem faces on the Poser render could be inverted normals - I'll feel rather foolish if that's the case, better go and check!

The sharp edges (marked in green on the new image here) aren't my major concern, but I appreciate the comments:

• I can see how adding a bevel would improve the appearance, make it look more natural - might try that.
• I've set "creaseAngle 45" in the .pp2.  Agreed, the DS/Poser end user can play around with the crease/smoothing parameters, but it looks more professional if the default settings work. (I noticed that DS3 seems to set smoothing angle to 89.9 degrees, ignoring the creaseAngle in the .pp2?)

You mention "neater ways" - any good links? Don't just leave me hanging here with that tantalising hint!

I started this model by *"Just shoving primitives together"*h - the crescent, sphere and teardrop on top are left that way since I reckoned (a) it was too much effort and (b) hey, nobody would notice up there!

I guess that if you know how to do things properly, then sloppy work is a matter of personal choice, not necessity!   ;o)

It's a good idea to learn to walk before you try to run - I'm still trying hard just to stand up!   ;o)

Thanks again bob1965, that highlighted what I'm doing wrong!

The original CR2 is something I cobbled together in a text editor with just the dials I wanted (and therein appears to lie the problem). But since I'd included all the standard rotate/translate/scale dials for the BODY part, I followed your step-by-step advice and played around with them. It works exactly like you said it would - same dials behaviour in both Poser and D|S.

"...so be real sure you understand what you are altering..."

Sage advice - but at present I'm playing around with the CR2s precisely to try and understand how they work (I'm using Kuroyume's unofficial CR2 spec as my main reference).

I'm aware of the comment syntax, and also how easy it is to mess up a Poser file (I do it regularly!) But even so, at this stage I prefer to do most of my file editing longhand in a text editor. The files are pretty small at present, and each mistake  I make and  fix is a new lesson (sometimes the same lesson again!)

Thanks bob1965 - I've added that link to my bookmarks.

I think my question was phrased wrongly though. The problem I'm actually concerned about is that the default status of the X/Y/Z rotate/translate/scale dials is different when I load this model into Poser and when I load it into DAZ|Studio.

In the cr2 I've ONLY included the channels for the specific dials I want on the Cradle, Hoop and Globe parts, i.e. Rotate Cradle (Z), Rotate Hoop (Z), and Spin Globe (Y).

When I load the figure in Poser and look at the parameters for these parts, only the ones I've set appear (which is what I want).

But when I load the figure in D|S and look at the parameters I see all the other X/Y/Z rotate/translate/scale dials too.

I tried to get D|S to do the same as Poser by including all the other channels with the following format (just the four lines per channel):

rotateX xRotate
     {
     hidden 1
     }

This got D|S working as intended, but now Poser displayed all the other X/Y/Z rotate/translate/scale dials too!

3D Cheapskate

I should mention that the usage rights have been reduced from "Unrestricted Use" purely because of the planetary textures - see the readme. Everything apart from those textures is my own work, and has "Unrestricted Use" rights.

Version 2 now uploaded at the original link, with the Poser problem fixed. Various other improvements included, among them textures for the planets in the solar system.

I'll also be uploading the globe to the Renderosity freestuff area later today

3D Cheapskate

Bobby - simply that I wasn't aware you had a hosted freestuff area! I'll bear that in mind in the future (is it okay to upload freestuff to your hosted area and the other site as well?)
But also, since a large proportion of the free stuff I've downloaded in the past has been from the other site, it seemed a fair place for my first upload.

Laurie - the dials 'problem' only occurs in D|S for the released model (see the known issues in the readme).
The dials I'm referring to aren't morphs, they're just the basic XYZ scale, rotate, and translate dials on the Base, Cradle and Globe parts. Other than the 'Rotate Cradle' (Z rotate on the Cradle part) and 'Spin Globe' (Y rotate on the Globe part) they are unnecessary.
It's not really a big problem though, and it just means that if you accidentally spin the wrong dial the globe breaks apart! Simple for the end user to fix, just reset the dial you accidentally spun.

The bigger issue for Poser is the origin for the cradle rotation. In the four sample pictures the one with the grey background is a Poser render, and you'll notice the attachment point between cradle and base is wrong - the globe would topple over.
I know this is an issue to do with the origins of the various parts, but haven't solved it yet.

3D Cheapskate

I made a simple prop (obj,pp2,texture) with 28 vertices, 8 texture vertices and 12 faces.
It appears as six stacked items, top to bottom:

One face - square, planar.

Two faces - square, planar, same vertices, opposite winding orders.

One face - quad, non-planar.

Two faces - quad, non-planar, same vertices, opposite winding orders.

Two faces - rectangular, planar, at 90 degrees to each other (2 vertices shared).

Four faces - you can work it out...

Each face is texture mapped to make it easy to work out what's what on the renders.

The phrase "SINGLE FACE" on a red background

"DOUBLE FACE (FRONT)" on green

"double face {back}" on yellow

I've numbered each render - here's the key:
1 - Poser6, with default settings
2 - As render 1, but with "Normals Forward" set for the prop.
3 - As render 1, with "backfaceCull" set to 1 in the .pp2 file for the prop.
4 - As render 1, close-up to show the effect on the middle face.
5 - DAZ|Studio 3 render. Similar effect, very obvious on the warped face.

Suffice to say that in every case, two coincident faces with opposite winding orders cause a problem.
Neither "Normals Forward" nor "backfaceCull" seemed to have any noticeable effect, which was a big surprise.

The last two renders were done to try and understand "Normals Forward". The Poser Reference Manual states:
"Checking the Normals_Forward checkbox will flip the surface normal to point towards the camera (or towards the ray in case of raytracing). Use this option to avoid shading artifacts on doublesided polygons."

Renders 6 and 7 show that it does something. These are the props for these two renders, top to bottom:

Single square face

Single square face rotated 180 degrees about the y-axis

Two square faces, same vertices, opposite winding order.

Two square faces, same vertices, opposite winding order, rotated 180 degrees about the y-axis

Texture map:

"FRONT" in red on a white background

"BACK" in blue on a white background

 
6 - P6, default settings, but with a reddish lamp to light up the front, and a bluish lamp for the back.
7 - As render 6, but with "Normals Forward" set.

Any thoughts or comments anybody?

Next step, try English Bob's displacement suggestion.

Just to be sure of the terminology - a true double-sided face is created from a single face in the object file? A double-sided mesh could be made up of double-sided faces, or pairs of single-sided faces, each pair having the same vertices but opposite winding order?

Thanks dadt - I'd searched the manual and could find nothing.

English Bob - "Horrible artifacts when rendering" doesn't sound nice. So now that I know how to enable double-sided polygons, here's a good reason to avoid doing it! Isn't there a note somewhere about only doing cloth simulations "with single-sided, uncapped objects" - I'm sure I read it recently, but I can find it again! (That's one of my big problems - I've read loads of stuff over the past few years, but don't know what's good and what's rubbish, and can't put my finger on where a particular nugget came from to double-check it!)

I read somewhere about "giving thickness" to items, as you suggest, if you wanted them double-sided. It said that the thickness should be added "in the direction of the normals" (or inverted normals, depending on whether you want your original surface to be the inside or outside) which makes good sense - so it's back to the modelling tool's manual for that.
I see your point about it not working in the cloth room, what with the item turning itself inside out as it slides down the figure.

Thanks again - all input greatly appreciated!

Thanks for the correction English Bob (you weren't kidding on your site when you said you can be found hovering at most poser-related forums).
I'd noticed that some .objs intended for Poser have the normals explicitly defined and some don't (should have realised at that point!) - I'd actually scribbled down a query "f 1,2,3,4 ≠ f 4,3,2,1 ?", so I think the fact was there in the back of my head.

On the subject of single/double sided faces - I've noticed with dynamic cloth simulations that I often end up with faces from the inside of the cloth towards the camera. These, of course, are not rendered (a double-sided mesh would render correctly).
I suppose that if you created a mesh with all normals pointing outwards, then duplicated it, inverted the normals, merged duplicate vertices and exported an .obj then, when rendered in Poser/DS, it should appear as if it was a double-sided mesh? Is this the a sensible way to get over the problem?

Regarding the .pp2/.cr2, I'd already come across Kuroyume's unofficial file CR2 format spec (.pp2, etc seem to be a subset of this?). Although perhaps not quite up-to-date it seems to be a very good explanation.
Guess it's time to consider the .obj and .pp2 files together., and try adding it as a prop rather than importing it as an .obj