Quote - This was, in fact, my original intention.

My source code is still saved as 'ccrender.py', meaning Catmull-Clark Render.

I have a few other priorities right now, but you can expect to see this eventually.

The memory issue is not with render but with posing/preview. Why waste resources when you do not need them? Users of the apps you mention usually have something more than a home PC to work on. 

Quote - In my thread somebody said this

All the morphs are made from the base mesh.  The exporter would have to be able export out not only the sub-d mesh but all the morph deltas sub-d without changing vertex order.

That would be one solution, but it would require further action from DAZ which will not bring them much return; It would mean unleashing their Genesis figure in Poser and there would be no need for Poser users to ever start their DS front-end again.  

Note that with every subdividision step in the mesh, the number of vertex deltas and weights for Weight-mapped joints rises exponentially, and if you copy this rise again in the deltas and weights you end up with a memory hog. The rough low-res mesh+subdivision approach was necessary to keep memory requirements within limits. The consumer type user is DS (and Poser) bread and butter. 

The cunning route Snarly has now so kindly opened for us of course permits to work like DS does: subdivide only just before you render.  If the script is appended with  commands to kick start the renderer and upon completion delete the subdivided mesh and turn the figure visible again, you would have the transparant one-click solution.  

There is one issue of course, and that is connection. As said, there is not only the number of vertices, but subdivision causes drift in the geometry description. The original vertices are moved. So, if you subd one object, say the head, the geometry will no longer fit at the neck. So, you have to choose one single single mesh to maintain the connections.   

Just for those who have difficulty understanding: A cage is a 'mesh' of which the verrtices (usually called 'nodes') are attraction points, not surface definition points. Compare it with the positions of magnets when you try to pull a flat surface into a shape using a grid of magnets covering a certain local part of the mesh. So, if you want to model a local hump, you have to pull the magnet governing the spot far out, so, if you represent the magnet positions as a mesh, it will show a local peak. 

We are therefore looking not at a geometry definition, but at raw data that is intended to be used in a specific process to make a geometric definition. That this raw data very much looks like a geometric definition and in face can be represented as one if you take the node positions as vertex positions and take the cells between the nodes as polygons, can be convenient in some cases. The cage, so represented, even looks very much like the final geometry. 

Catmull-Clark subdivision (or rather interpretation of a mesh as a cage and generation of a new geometry from this cage) causes drift of the definition. The new geometry is not where the original vertices were. Look at the famous example of a cube transforming into a sphere:(http://en.wikipedia.org/wiki/Catmull%E2%80%93Clark_subdivision_surface) The corner points of the original box are not on the surface of the sphere. There are ways to fix this, of course, but those are to my knowledge not applied in DS.

For that reason this type of smoothing can not generally be used for any purpose where accurate interplation of the surface trough the definition points (which may be results of measurements) is required.

The drift of the definition (or the distance between the smoothed surface and the original definition point) is proportional to the ratio of the distance between the nodes of the cage and the average radius of curvature. A ring defined with a coarse cage may  disappear into a finger defined by a fine cage.  

Also note that when a surface is subdivided it loses detail. The only information used is the XYZ position of the nodes. Even the information in the normals is not used.  Depending on the distribution of distances and angles between the 'edges' of the definition grid, local exitation can occur and, yes, when used in a cunning way, this can be used to some extent to simulate detail. 

Quote - Yes, but there's also no thickness. If you want that you're SOL by doing it in the material room. For that, you gotta go to a modeler ;).

Not necessarily. Just wanted to emphasize that you do not always need to model the intersection to display it. ;)

Of course, while the IsInObject(xyz) node in the material room is pending, you need to model the intersecting objects both parametrically in the material room and in xyz space before you can do the logic.

Confirmed here. The link works. The site appears up and running again.

Presume new acivity in the WM front will follow.

Quote - Actually her buttcheeks are stitched together. :-D

Where? Buttocks are welded to hip and to nothing else.

I wish you were right. It would be a breaktrough if Poser could handle body parts welded to more than one parent. 

In my copy I have moved the 'iris' polygons to the left and right respective materials in the eyes (load the .obj in poser and re-assign the polys), then save the .obj (different name), throw away the .mtl.)

Then to fix the .cr2 open it in a CR2 editor (PhilC has one) or in a text edtor, remove all material definitions and fix the reference to the new .obj. Save the .cr2 with a new name and load it in Poser. If you then load it in Poser your figure will just have (a subset of) the V3 materials.

Loading an existing V3 MAT file will let you end up with all V3's body zones (SkinLeg, SkinFeet, and so on) in your figure. There is little you can do about that. In JudyV3 these are not assigned to polygons. All 'skin' is SkinTorso, or BodySkin for the alternate hip. The Genital material is specific for JudyV3. A template is attached.  

Judy always had an error in her original materials. Judy featured both a ToeNails material  actually assigned to Polygons and a Toenails material, an orphan in the .cr2. Case is important, in naming, so these are 2 different materials. This doublure of course disappears if you cut the materials from the .cr2.

For an EZSkin defintion for your new figure you can of course copy the V3 definition and select a shader for the genital material. In this elect forum I need not expand on the potential the special effects (wet, soapy) of EZSkin2 provide in this respect.

Here you are:

Trouble in the Runtime. Sydney for reasons women may understand better having words with Judy. But: We all know Judy can be a bitch when the Master of the Runtime has cast her to dwarf-form.

*Judy: Sally! skin for V3; EZSkin SSS shader and Koz's short bob. Sydney with native skin, EZSkin Judy's dwarf shape from some dusty box in my Runtime. *

Here's number 1: JudyV3, with Sally texture for V3, EZSkin sub-surface shading. No further morphs. Rest later.

Of course it is vulnerable. If you touch the joint centres just a bit, the length and the result will be different. It works when poses are made with the 'right out of the box' character. Fortunately, most pose sets are.   

The actor names may be more decisive. Apart from the buttock actors mentioned before, differences there are found in the feet and in the head (jaw, teeth, tongue). Also some female characters have breast actors. 

Hmm. One would expect the thighLength parameter was to serve as an identifier of the figure. 

For V2 poses I find: thighLength = 0.177885

For V3 poses I find: thighLength = 0.17748

For V4 poses I find: thighLength = 0.188311

Checking co-ordinates for Victoria3:
rThigh centre = (0.042, 0.372, -0.008)
rShin centre = (0.035, 0.195, -0.019)
Using Pythagoras Rule: length is 0.17747958, rounded off 0.17748

So, when in doubt, check thighLength 

Quote - I don't hang onto them (seamless). A few of the textures in my furniture shaders are seamless, and I made them that way just for grins, but we don't repeat them in our UV mappings.

I never meant you there, BB! 

Love that furniture!.  

Too bad though everybody hangs to these 'seamless testures'. Repetition is unavoidable and is noticed right away.

Would appreciate the real 3D stuff: An infinite 3D procedural definition from which the object would be 'cut' , so for wood moving into cross grain texture, etc. 

I remember good old PovRay did that.

Would welcome an application that would render the sections of a 3-D object with a 3Dwood texture into UV space, so giving 'real' pieces of wood you can move around. Poser is not very good at rotating and moving texture functions.