Arthur wrote:
I looked over the code I thought I had re-done, and it was not what I remembered working on. Here is a working version that doesn't build up a massive string, but rather writes to a destination. If you need a destination, make a CStringIO and use it. It would be fun to try and mix this with the PyGeo code. OK, I sure mangled that explanation. I should have said: If you need a string, use a CStringIO as the destination and unpack when done.
I gave it a whirl with PyGeo.
About the furthest I've ever gotten into string processing (not fun to me) was my effort to follow and extend Ruth's povexport.py code. So that I am not sure I follow what you are accomplishing versus the "stock" code. ... Could you explain better the "use case" difference between your version and Ruth's? I have images with tens of thousands of truncated torii. The torii get turned into curves, and the resultant file is massive. Unfortunately, the N**2 effect of string concatenation was making these runs take a _long_ time.
2 BTWs:
1. I seemed to have needed to change AttributeError to KeyError on line 344. Most likely correct.
2. The functionality I would like to see is PovRay automatically called to render the exported code - rather than requiring a separate look for the file and call to PovRay. At a practical level, this would provide for a more coherent workflow - looking at what you got and redoing it until you have it as you want to see it. But I don't have the confidence that I could accomplish this sensibly in a crossplatform way, that would fail gracefully, not require config files (where is the pvengine executable?), etc. Any thoughts? I do know the pov-ray people have been pretty insistent on making sure nobody repackages it in a way you don't see their interface. I think we'd need to wait for the repackaging they are in the midst of.
-Scott David Daniels Scott.Daniels@Acm.Org