What are the limits of PoserPython's potential? Could it be used to introduce ray tracing, collision detection, cloth effects, particle effects, vertex editing, or a work-around for the circular IK limitations? Or is it suited for smaller, less fundamental improvements to Poser? Knowing almost nothing about programming and code, I am extremely curious....

Good question and one that's going to take quite some time to answer fully. Python has be around for years and has been used to create some extremely complex systems. So far, I haven't run into any roadblocks that would make any of the situations you mentioned impossible. Only time will tell on this though.

Thats really dependant on two things: 1 speed and 2 how many hooks Curious has put into pro pack for us to access. The speed issue is from the fact that Python is interpreted. This means you're not going to use python to write a high speed video game. The other issue is simply how accessible the poser system is through the call backs and functions Curious has provided. Python is very powerful and provides most of the other programming features needed to writesome pretty high end functions.

I'd agree that the 'hooks' might be a limiting factor. The speed problem may not actually be there though. For high end apps, like the ray-tracer, you can get by Python's limitations by writing a .DLL in C or C++. There are already freeware packages available for doing image processing in Python using this method. One that comes to mind is the Windows version of the Python Imaging Library (PIL).

From what I've seen there isn't direct control of the rendering, so no ray tracing, at least not in the main poser window. Collision detection, cloth effects, particle effects, vertex editing are all doable dos. I am impressed by the speed of Poser-Python so far. The interpreted language issue is real but the way around that will be to code smartly and make maximum use of Numpy. The work around for the circular IK is an interesting problem. I've been trading emails with CL on some issues in the ProPack, like currently there is no direct access to vertex UV coordinates, and they have been very interested in any feedback on poser python.

Done a bit more reading (got a Kindergarten level book on Python).... I assume that python scripts would not be able to run in the background, so collision detection seems like it could only funtion as an alert to the user, pointing out where geometries intersect. Not too useful in itself, but I imagine that this could be built upon to facilitate the development of cloth effects? Am I off-base? Would it be possible to link a python script to an external raytracer, like POV-Ray, to run the raytracing program within Poser, side-stepping Poser's internal rendering? Or is that outside of the realm of possibility? What about making the "hair" feature renderable? What about using Python for new import/export features? Unlikely?

Again a ray trace means you'd have to gain access to the geometry info. Now this may not be a problem. You could do this IN SPITE of poser itself. For example, in Morph Manager, I read in the obj file and parse it into faces, materials etc. This code could be converted to python (if someone already hasn't) and the obj file could be read externally. Of course all the joint inof would need to be accessed plus the method by which Poser stretches vertices would need to be duplicated. I'm looking into converting Morph manager into a Python script that could even stand alone so that MAC users could use the thing. My first project right now is to make a more useful material editor.

Mason - Maybe I'm not understanding the problem here. From my reading of the PPP docs, I thought there is a function that will give a list of vertices for the actors in a figure. If you have the vertices then you should be able to construct the faces and normals. I would think you'd want to do that anyway so that everything would be compatable with the (yet to be built) ray-tracer. I'm probably missing something major here so please point it out. This isn't meant to be an arguement, I'm just curious.

If you see that function then I'm wrong. I must have missed it. If you have access to their geom data then you're set to go. Does it provide pre or post vertex info ie does it allow you to get the vertex info after poser has applied all MTs and joint welds? What I was thinking was to bypass Poser PPP altogteher and just write a straight Python app that read the info and rendered. Also, to render the figure you need to mimic how Poser deals with joints and mesh deformation (welds). The info is there in the channels section but how it is implemented maybe a more complex issue. I just haven't researched the python function set enough.

Attached Link: http://www.3dluvr.com/subagio/domelight/HDRdome.html

Attached Link: http://www.3dluvr.com/marcosss/morearni/

Attached Link: http://www.3dluvr.com/marcosss/morearni/tkm23.jpg

What I would love is if Curious would allow us to write our own DLLs so we can add rendering features to the engine ourselves. Let 3rd party people put a ray trace together for you.

Traded an email with CL today. Word I got back is the Python interface as it currently is will not allow you to get into the rendering pipeline, ie that which happens after you do a scene.Render() is outside of the Python access. Easiest thing to do would be to write a file exporter to export the scene to another package. Might also be possible to tie the Poser scene data into another renderer via a Python script by having Python get the scene data and pass it to the other renderer if the other renderer has some kind of interface exposed that the Python script could get to. The other renderer would have to have it's own window, and you wouldn't be rendering back into Poser but rather into the other renderer. You theoretically might be able to tie them together so that changing the Poser scene would be reflected in the other renderer. If you really, really want to do something like this and you have source code for the renderer and a compiler you could also theoretically compile up a Python extension DLL using the renderer source code that would pop up a separate window using your renderer and feed it the data from the scene. This would probably be double ugly (double ugly being worse than coyote ugly) to try and implement but it is in the realm of the theoretically possible. I would suggest someone start a Poser-Python wish list somewhere and we collect gripes and suggestions for a few months then send it off to CL.

Attached Link: http://www.lightflowtech.com/

Attached Link: http://www.stmuc.com/thbaier

Downloading Lightflow now. Will take a crack at it when I have a spare minute.

OK, I did a search through the PPP docs and found that it is possible to export lists of vertices, polygons and normals. Exporting normals was the big one since that controls how the textures will fit. This appears, from what I've read so far, to be true for actors and morphs. Given that, I think that you could save a static view of the scene to be rendered as a file then use the file as input to a render engine. Yes, it would have to be to a new window opened using TkInter or more likely PIL. Using a static view addresses the concerns about current geometry since rendering would be more like importing the figures frozen into Bryce. The flow would look something like this: Save the vertices, polys and normals for a figure to a file. Save the current MTs for the figure to a file. Save the current camera settings to a file. (This is iffy since it would be able a new camera view in the rendering engine) Save the current light settings to a fine. Ditto Use the delta values in the list to change the actor geometries. Convert the light lists to something the new render-engine can use. Convert the camera lists to something the new render-engine can use. Apply the currently connected textures and bumps. Another 'iffy' since I haven't figured out a way to do this one. Render in a new window. Granted, these are broad strokes and very speculative but I think it will work.

Bushi- You're on the right track. In the current interface you can access everything geometry and material related EXCEPT the texture coordinates. I've emailed CL on that one and they're going to include that in an updater sometime in the future. Have not looked at cameras and lights yet but I will. Downloaded LightFlow and found it will only work with Python 1.5.1, the one they have on their website, as it wants to have a Python 1.5.1 dll in the path. (double ugly item #1). I'll try it again as soon as I finish downloading their Python 1.5.1. FYI, Poser uses Python 1.5.2 so of course the versions would be incompatible (Murphy's Law of Programming #5- Versions will be different and incompatible). That could probably be fixed but will require someone somewhere to recompile the source. I emailed the Lightflow dude to see about getting it working with 1.5.2. In the short term could export the scene to a file and read the file into a Lightflow Python script and render it that way. FYI to get the python version run this script: import sys print(sys.version+'n') For those of you who haven't coded in the past the most important programming phrases to learn and master are: "Why isn't this !&^%$#@#%@ thing working!!!!" "Why did those &^$@)!*% idiots do it that $%&Q@$& way!" If anyone wants a custom file exporter the main thing needed to implement it will be a spec for the file format. Python can write out to both ascii text and binary files.