So do I, and it was when using the 'RunPythonScript' command that I encountered this behaviour.

I assumed that the poserStartup.py script was being run on poser initialisation, or when the default document was loaded (as in scene.SetStartupScript()). It invokes the main menu script, but that script actually sets the button members of the poser object, and doesn't necessarily display the menu window.

On a possibly related matter, I encountered some problems with the definition of polygons in geometry objects/props within a Python function, when the geometry/object was returned from the scope of the function. I thought I had fallen foul of the garbage collection, but it worried me because I couldn't see why the same thing shouldn't happen when the script terminates, and any prop geometries fall out of the script scope. This originally made me think that the poser Python object may have an application global lifetime (ie. it is only initialised on startup or document loading).

I'm still new to Python, but I'm an experienced enough programmer to know that I'm probably doing something stupid ;)

I haven't reproduced the problem, but I'll be keeping an eye out for anything similar.

Bill

Yeah, but the point is that I could.

I suspect the cause is something to do with the poserStartup.py script which imports poser and Numeric for you. If this isn't always (or consistently) applied, it could go some way towards explaining the odd on/off behaviour.

BTW although the absence of the script didn't cause a reportable problem for Python's interpreter, the script did simply stop mid execution, so my guess is that there was an invalid (or possibly uninitialised) reference to a poser object. And, I'm using SR3 if that's of any relevance.

Actually, I am still intereseted in whether anyone has MKParticles and if the Python script(s) are missing the import poser statement.

Bill

Actually you can export a mesh object from Bryce 5 (a tip from hogwarden in an earlier thread).

Bring up the edit window (E) then press CTRL-D. Beware of the high polygon count however. I don't have Bryce 4 installed anymore so I don't know if this worked in that version.

Also, to create a skee effect, I found it useful to create a clipped symmetrical lattice composed of a few irregular blobs in Bryce and export it as a low polygon tesselated object for use in Poser. This worked well when the resulting 'group' of rocks was half buried in a sand prop.

Here's a thought that I haven't tried, but one thing you could do is setting all the figure's materials to maximum (white or blue) ambience, rendering and saving, then pushing the camera forward or back slightly and changing the camera focal length, delete or hide the figure and re-render. This will give you two images which you should be able to composite together in a paint program, using the 'ambient' figure as an alpha channel. The slight difference in camera position and field of view in the second image, which replaces the figure in the first should give you some illusion of refraction! Watch out for anti-aliasing around the figure edges!

Just as a suggestion (especially if you are rendering yourselves); don't commit to a video compression codec just yet. Keep the animations in uncompressed format, to allow post production and editing and compress them once the final edit is completed and the scenes are ready for splicing.

OK these means a lot of off-line storage, but they do actually zip up quite tightly.

Currently DivX looks like a much better quality/compression codec than MS Video1, and in a year or so most of the community may be running on powerful enough platforms to handle the decoding.

Sorry I can't afford the time myself, you will need to split the workload some more, 4 - 8 hours a day is prohibitive, especially for when folk won't get full artistic control of their own output or financial renumeration. Even if people commit to that how are you going to ensure that level of commitment over the entire length of the project? Anyone who does volunteer for that extended commitment is probably deluded.

Parcelling out the work a scene at a time to a larger number of artists, along with a tight script and access to sample animations may be a better bet. Also allow yourself some leeway for non-delivery and unsatisfactory work.

Why not, in the first instance, aim for a short (3 - 5 minute) trial feature, just to see how things pan out?

Whatever becomes of this, best of luck.

I think it would be a bad idea for CL to exclusively tie themselves to a proprietry file format. Which one would they go for? Whatever they chose, the majority of people would be pissed. Plus there is always the problem with copyright infringements (aka GIF).

At the end of the day, the total amount of information (excluding headers) required would be the same whether it is packaged into one or more files, but with less flexibility in using some lower res components to save memory.

My vote is with the open file formats - do any of these support multiple layers?

No problems in any of these areas. So far as I am aware there are no backward compatibilty problems between ProPack and P4.

ProPack doesn't need to use .bum files, it can render bump mapping straight from a normal (.bmp, .jpg etc) file and doesn't perform a conversion. If, however, a .bum file is specified in the material, ProPack will use that in the same way as 4.03.

I think (but can't remember now) that ProPack converted all of the library .rsr files into .pngs on installation. Either way, I now have library directories that have both .png and .rsr files for the same objects, Propack seems happy using either. The main reason that a lot of people delete the .rsrs is simply to save disk space.

The only downside is that if you are distributing objects from a ProPack installation you may have to convert the .pngs to a .rsr format in order to allow P4 users to access them.

In ProPack you can animate diffusion colours, highlights and transparency levels, but not the maps, ie. you can't blend from one texture/bump/transparency map to another.

I tried material animations in the original ProPack release, and it caused me a few problems. I haven't tried it since SR3 was released.

Mark is right, the majority of Poser users don't care about this, or at least about the underlying technology, but obviously I am curious, which is why I posted the original question :)

Incidently, the reference to a 'Renderman compliant raytracer' still doesn't make sense to me. Again this is an import compliance standard that Kupa referred to, not an export standard.

As an aside, my main concern in the previous thread was that CL have probably based the decision to implement a raytracer at least partly on feedback from their customer base, and, for most of those concerned, the term 'raytracing' is probably synonymous with 'high (or better) quality rendering' which is what they really wanted.

So CL may well face some level of dissatisfaction if raytracing performance has a significant impact on rendering times, as I suspect it will for the first generation of a new product.

Personally, I think that for the majority of users, CL would have spent their development budget on improving the scanline rendering technology, and there is plenty of scope for improvement in that technology. Kupa stated that the scanline renderer would be retained, but gave no indication whether there would be any improvements.

Acknowledged, I am making assumptions here on what people really want, but it has been fairly obvious from many of the forum postings that there are a lot of people who don't understand (and for that matter don't care) about the technologies or terminologies so long as they get the results they want.

Beware of what you wish for...

A lot of artists are doing the posing/character work in Poser, then exporting that into another 3D application to add additional elements and perform the rendering.

Are you using the RenderToNewWindow() method instead of the Render() method? According to the documentation this renders the image to the current view, which is from where 'SaveImage()' should dump the .bmp

Yes RIB exports will probably be essential for all the elements that P5 can model and animate, but that's actually fairly easy to achieve. It doesn't need to include anything P5 itself doesn't represent and extracting the data from the internal structures and formatting it in the RIB ASCII description is pretty straightforward in programming terms.

However the 'compliance' issue and the original posting describing the rendering engine as Renderman compliant is a reference to import capabilities of the renderer itself, whereas ensuring that the RIB export matches the P5 scene is an export (and hence not a compliance) issue.

As I said at the start, I am dubious about whether the 'Renderman compliant raytracing engine' statement was accurate since it would require putting a lot of work into a feature that few people, if any, would find a practical use for, despite what they might think.

Note that, so far as I am aware, the only Renderman compliant applications on the market at this moment are standalone renderers.

Interfacing with a third party engine as suggested by MadYuri would explain this.

It could be possible to import additional scene elements from other apps, but the suggestion would seem to be that these elements would go straight to the renderer, and couldn't therefore be manipulated/animated in the main app. Additionally, the Python interface could be expanded to allow Renderman API calls and add elements during the rendering process, now that would be useful for me, but I don't know about the majority of users.

Just to clarify, Poser only exports a small subset of the Renderman standard, specifically, only polygon information for describing Poser's mesh models. In order for a renderer to describe itself as Renderman compliant, it has to be able to import the full set of Renderman API calls, and implement a basic subset, including splines, Bezier patches and NURBs.

P5 may implement a few of these features, but even then, in order for the rendering engine to gain Renderman compliance from Pixar, it would still have to be able to import and render all of the required features, regardles of whether they are available or usable in the main app.

Renderman is not an application or a rendering method, its an interface standard (API and file) that allows seperate applications to share scene descriptions - Renderman compliance is import standard. Implementing it and gaining a compliance licence would seem to be extremely inefficient where most P5 users would either be rendering from within the application or exporting to third party applications or high end renderers.

In the Window menu there is a Document Window Resize... option [last item]. That should do the trick.

Or save the whole character in the Figures library.