Nice one slinger :-)

Additionally, the script applies one MAT pose at a time to each material which may appear to take an inordinately long time, but prevents crashes on the Mac which occur in complex scenes with large numbers of materials and shader nodes if all of a figure's materials are overridden at once by one MAT pose application. The script also sets the P4 materials (though they're overridden by the MAT pose application) as a further means of visual feedback on progress. That part could work sufficiently well on unparented props as long as they don't have any shader nodes defined (If you've never looked at them in the Material Room, for instance). If you like, you can uncomment the section which deals with unparented props and try it out. If anyone's interested in helping to deal with temporarily parenting props to allow MAT pose application, I need a dummy figure CR2 file that can be loaded into the scene, have the unparented props temporarily parented to it, then be deleted once the props have had their MAT pose applied and been unparented.

OK, finally, here's the script ClearAllMaterials.py. The caveats are as follows: # This script will clear all of the materials for each figure in the scene. # It will also clear materials for props parented to a figure. # At this time Poser 5 does not support applying MAT poses to unparented props. # Some future revision may temporarily parent props to overcome this. # # NOTE: the test for whether a Body Part has a separate list of materials is # only cursory and not definitive. It is assumed that if the Body Part has the # same number of materials as the parent figure, it is the same list. This may # not be the case, but is the simplest way I could find to distinguish # inherited materials from those belonging only to that body part.

AntoniaTiger, that's been exactly my observation. I switched to completely ray-traced lights just to avoid that protracted period of no progress reports or visible bucket outputs while the shadowmaps are loaded. This was particularly painful when using many shadow mapped lights to simulate GI.

That's great Ockham, P5's decided to play silly buggers again on me, but I think the additional info from the strings extracted from the binary implies that: kParmCodeGEOMCHAN = 43 kParmCodeCENTER = 44 kParmCodeCURVE =45 kParmCodeHAIRDYNAMICS = 68 kParmCodeDYNAMICPARENT = 69 kParmCodeCLOTHDYNAMICS = 70 I thought it should be possible to just print these constants if the poser library has been imported. Unfortunately not. It may be that the string is used as a dictionary lookup for a method, but without access to the python interface declarations, it's impossible to tell. It's also possible that the last three fill the missing gap at 37, 38, 39.

Here is the list I've extracted from the P5 Mac OS X binary. kParmCodeXROT kParmCodeYROT kParmCodeZROT kParmCodeXTRAN kParmCodeYTRAN kParmCodeZTRAN kParmCodeXSCALE kParmCodeYSCALE kParmCodeZSCALE kParmCodeASCALE kParmCodeFOCAL kParmCodeHITHER kParmCodeYON kParmCodeTAPERX kParmCodeTAPERY kParmCodeTAPERZ kParmCodeKDRED kParmCodeKDGREEN kParmCodeKDBLUE kParmCodeKDINTENSITY kParmCodeDEPTHMAPSIZE kParmCodeDEPTHMAPSTRENGTH kParmCodeTARGET kParmCodeGEOMCHAN kParmCodeCENTER kParmCodeCURVE kParmCodeGRASP kParmCodeTGRASP kParmCodeSPREAD kParmCodeWAVEAMPLITUDE kParmCodeWAVEFREQUENCY kParmCodeWAVELENGTH kParmCodeWAVESTRETCH kParmCodeWAVESINUSOIDAL kParmCodeWAVESQUARE kParmCodeWAVETRIANGULAR kParmCodeWAVETURBULENCE kParmCodeLITEFALLOFFSTART kParmCodeLITEFALLOFFEND kParmCodeLITEATTENSTART kParmCodeWAVEPHASE kParmCodeWAVEAMPLITUDENOISE kParmCodeWAVEOFFSET kParmCodeVALUE kParmCodePOINTAT kParmCodeLITEATTENEND kParmCodeHAIRDYNAMICS kParmCodeDYNAMICPARENT kParmCodeCLOTHDYNAMICS I'm just coding a script to see if I can verify whether there are any allocation holes in the list or whether this is the full enumerated type.

From memory, the standard Transform TypeCodes seemed to go up to about 36 or so. It seemed a good indication to me that a consistent 49 on all the deformerPropChan parameters was not just - Unknown or Unassigned. I also noted that the x,y,z values of parameters that comprise a tuple all returned the same code. I once trawled through the resource fork of Poser 4 when I was running Mac OS 9 looking for strings to flesh out my knowledge of the CR2, etc. file formats. I found some interesting things like deltaMulDelta and deltaDivDelta in addition to the standard deltaAddDelta used in JCM/ERC. It might be worth having a look for other kParmCode strings.

Removing the shader tree for a material is both as simple and as difficult as loading a MAT pose file. I have a script which creates a MAT pose file for all the materials of a selected figure then applies it. As with loading an MT5 file in the material room, loading a MAT pose will completely replace the existing shader tree. This could easily be extended to process all figures and visible, non-light prop actors in a scene. In most cases this will work well, but if any figure has a complex shader node setup, a la Real Skin Shader, Poser 5 (at least on the Mac) shows the holes in its garbage collection and memory management routines with a very nasty tendency to crash. When my P5 is free from rendering tomorrow, I'll hack up the script and post it here. I would advise saving your scene before running the script, though.

I've been habitually rendering images at 1600x1600 (matches the width of my monitor) I've just started using face_off's Real Skin Shader and even node heavier shader variants with raytraced lights, displacement maps, reflection and refraction. Never had any rendering problems other than Firefly artifacts caused by floating point underflows due to scene scale. A few weeks ago I switched from using a bucket size of 128 up to 256 and noticed substantial render time improvements, but also render crashes on denser scenes. Going to a smaller resolution 1200x1200 allowed these renders to work, but I finally gave in and set the bucket size back to 128 and now I have no problem at the 1600x1600 resolution again.

[Wipe drool off chin] [Inhale] [Hold it]

As I sit in the cooling breeze from my window rattler, sipping a rather nice red from the Hunter Valley Wine Society, and escaping the seasonally typical temperatures in Sydney, I remember with fondness the abundant and easily accessible beaches in Newcastle, at the mouth of the Hunter River, where I grew up. Wherever you settle in OZ Gwendolyn, you will certainly find a WARM welcome at this time of year :-) and especially from fellow CG enthusiasts. Enjoy your travels. Geoff

It should also be noted that on the Mac, the alpha channel in the PNG file needs to be black in the areas that the thumbnail has visible pixels. A lot of PC generated PNG thumbnails are distributed with completely white alpha channels. I use graphic converter to invert the alpha mask on these and then the thumbnail shows as intended in P5. For P4, the RSR file will need to be combined with the CR2 or PZ2 file using PoserMacConverter. Once that's done, the thumbnails are usually fine in P4. If they're not, the PICT in the resource fork (from the RSR file) may need to have its alpha channel inverted - should be all black, not white.

Ha, I think I've just answered my own question :-) There is a parameter method TypeCode() which seems to consistently return a value of 49 for deformerPropChan Parameters. This value appears uniquely different from any of the typecodes returned for the standard Transform parameters (scale, xROT, yTRAN, etc). There's no obvious kParmCode for this and I haven't seen any way to do a reverse lookup starting with the value, so I'll just plug the number in. This might be a useful augmentation of Ockham's original zeroMorphs.py script.

[bookmark]

grnbriar, this looks great! What development environment are use using and is their any prospect of a port to Mac OS X?