Announcing "povwriter" library (request for Windows / Mac testers)

monkstone

Announcing "povwriter" library (request for Windows / Mac testers)

in Library and Tool Development • 2 years ago

I have developed a library (entirely in the Linux environment) for exporting processing sketches to PovRAY format for ray tracing. The library uses an external template file (cf superCAD) so it is quite flexible. At present that template file must be called 'original.pov' and placed in your home folder ("My Documents" for windows I think), so that is in need of some improvement. However, at the output end I provide utilities for automatically opening the newly created file in jEdit, and running PovRAY from jEdit. It is possible to rescale/rotate/transform the processing sketch within the PovRAY scene as the entire sketch is encapsulated in a union{}. Processing colors are automatically translated to the povray format. Here is an example of my TTest sketch using my cornell box template. Download the library here . You will of course need to install PovRAY, I would go for the latest version PovRAY 3.7 Beta (which is multi-threaded). Please let me know how you get on...

Replies(20)

velvetkev..

Re: Announcing "povwriter" library (request for Windows / Mac testers)

2 years ago

This looks interesting. Have downloaded and will try and have a shot over the weekend- should give my new hex-core PC something to do!

velvetkev..

Re: Announcing "povwriter" library (request for Windows / Mac testers)

2 years ago

OK, I can confirm it does work on Windows 7 Home Premium, 64 bit. I will try and test it on my other computer which is Vista 32 bit.

The template file has to go in the folder C:/Users/UserName, but opening POVRay using open() works perfectly from the PDE once I found the right path. Will play some more and report back- cheers!

monkstone

Re: Re: Announcing "povwriter" library (request for Windows / Mac testers)

2 years ago

Thanks very much for that, I will now modify the documentation for Windows users. The open shortcut worked for me to a point, it launched jEdit, but not with the right file weird. I presume you can just launch the PovrayGui directly on Windows so the selection of file is not important ( PovrayGui is not an option on linux) whereas long form launched jEdit with the correct file.

cedrickie..

Re: Announcing "povwriter" library (request for Windows / Mac testers)

2 years ago

great, never used povray actually. but nice to see more and more ways to export processing data to render engines.

velvetkev..

Re: Announcing "povwriter" library (request for Windows / Mac testers)

2 years ago

This is very cool- works well with more complex geometry with no special treatment. It even copies ToxicLibs' normal shading as you can see! Also renders very quickly compared to Sunflow. Great stuff.

monkstone

Re: Re: Announcing "povwriter" library (request for Windows / Mac testers)

2 years ago

Glad you like it, I'm having second thoughts about the need for a chooser for the template file. Since the template file is a standalone pov file I don't think there is a real need for a chooser. As you have found rendering is pretty damn quick especially with a smaller sketch say 300*300. So my proposed method of working is open the templates for "preview" in PovRAY (jEdit intermediate step if you are a linux user) and save that file as "original.pov" in your home folder. I will endeavour to create some new templates including checker floor pattern that has a nice perspective look see something I did earlier.

ventai

Re: Announcing "povwriter" library (request for Windows / Mac testers)

2 years ago

Hi there,

This looks interesting. . I was just about to ask what the advantage may be over using something like Sunflow.

Would there be any other advantages? Can it render text easily? Does the camera match up with the Processing camera? (unlike Sunflow).

I'm also wondering if there's any difference in quality of rendered output (will test when I can).

Thanks!

______________________
www.systemarray.com

monkstone

Re: Re: Announcing "povwriter" library (request for Windows / Mac testers)

2 years ago

I think a big advantage over Sunflow is that PovRAY is actively being developed, using the radiosity feature shadows are now rendered more realistically ( than previous PovRAY), Sunflow rendering was originally more natural.

I don't think the cameras match up, and might actually be worse than Sunflow ( that was definitely the case with StructureSynth export, my main experience of using both renderers. Using StructureSynth was one of things that inspired me to produce this library). PovRay and processing have almost exactly opposite coordinate system convention, my library multiplies both Y and Z coordinates by -1. For text rendering see http://www.povray.org/documentation/view/3.6.1/65/ or my friend google. Currently my library actually only supports lines and triangle (mesh) objects, it would be cool to support primitives such as sphere ( which are actually rendered pretty well in povray) and box/cube ( StructureSynth does this as does the 'joons processing Sunflow renderer', and if memory serve me correctly camera match up in the joons renderer is better than the SunflowAPI renderer).

ventai

Re: Announcing "povwriter" library (request for Windows / Mac testers)

2 years ago

Cool - thanks for the info!

This is on my to do list :)

______________________
www.systemarray.com

velvetkev..

Re: Announcing "povwriter" library (request for Windows / Mac testers)

2 years ago

Hello!

Experimenting further, I'm getting occasional Array index out of bounds: 512 errors- it seems to be particularly with meshes with lots of detail and tiny triangles, and only when there is a fill set, not with wireframes. Having glanced over the docs I guess this is something to do with degenerate triangles? Is this just a limitation of POVRay?

Cheers!

monkstone

Re: Re: Announcing "povwriter" library (request for Windows / Mac testers)

2 years ago

I'm not sure unfortunately I'm no sort of export on PovRAY ( very much at the experimenter stage myself) if you were using radiosity try not using that. Generally if there are degenerate triangles PovRAY, explicitly complains about that (however often you can just ignore these warnings, I've mostly seen the degeneracy problem with spheres, particularly small spheres). I have experimented with a higher limit for my degeneracy filter, but if you are not careful you start to get holes in the mesh, and that is a disaster.

Were you using stroke ( ie not suppressed by using noStroke())? Here is a example just using stroke ( noFill(), the processing rendering looks crap), you need to beef up the PovRAY line width declaration (to 20 in this case). Below image is rendered as a collection of PovRAY primitives ie cylinders. I would like to implement spheres primitives (StructureSynth does this), but that is a very long way off. PS credit is due to Guillaume LaBelle and his superCAD library for the idea to use cylinders for line.

velvetkev..

Re: Announcing "povwriter" library (request for Windows / Mac testers)

2 years ago

OK, testing further, it looks like the problem I'm having is something to do with how povwriter handles beginShape()/endShape() calls when a fill() is set, and not size. For QUADS the limit seems to be 512*3 vertices, after which point it throws the array of bounds error. I assume this isn't expected behaviour?

I'm going to try the other modes and see if I can see some sort of pattern.

Cheers!

monkstone

Re: Re: Announcing "povwriter" library (request for Windows / Mac testers)

2 years ago

I think it is probably memory issue (probably on account of my libraries intermediate storage of object data) I just re-created the issue using a Hemesh example that worked OK with my modified superCAD where triangle line is written to file on the fly. Bumped my processing memory to 2048 MB, and it seemed to work OK again, I think there should be way to fix this via serialization of object data (the PovRAY output will take some time to render though even my Hilbert above took close on an hour to render at 700*700).

There is an even easier solution which is to revert to a earlier version where my objects are written on the fly and only the color declarations are appended to end of file (would just requires a manual edit, by cutting the color declarations and pasting them ahead of the processing bit of the pov file). Thanks for the testing/research by the way

Update 13 April 2011, interestingly I have now made the Hemesh example my test case within NetBeans and it runs fine (unchanged), profile suggest only 197MB of a maximum of 323MB used on heap. I wonder could this partly be a processing ide thing (I'm using version 0195 and 64 bit jdk1.6.0_24). Anyway I'm pressing on with modifying code to use a tmp file to store intermediate object data in pov format (ie Strings not serialization), which should reduce memory load further, I hope to avoid going back to the cut and pasting of color declarations.

monkstone

Re: Re: Announcing "povwriter" library (request for Windows / Mac testers)

2 years ago

I've just uploaded a possible bug-fix version which I would be grateful if you could test.

David Wil..

Re: Announcing "povwriter" library (request for Windows / Mac testers)

2 years ago

This is so amazing, DKBTrace and PovRay is where is where everything started for me - Thanks for this.

monkstone

Re: Re: Announcing "povwriter" library (request for Windows / Mac testers)

2 years ago

Hi. The chances are that you've a great deal more experienced with PovRAY than me, any comments on my templates (or template offerings) would be most welcome. I came to PovRAY via StructSynth, so I am very much reliant on on-line tutorials rather than any hard won experience.

velvetkev..

Re: Announcing "povwriter" library (request for Windows / Mac testers)

2 years ago

OK, that makes the example with 512*3 vertices as quads work, but I still get the out of bounds error with more complex examples. Confusingly, there seems to be more to it than just numbers:

Using ToxicLibs' mesh subdivision, I created a shape with 69,302 vertices, and 198,000 faces (which ToxicLibs renders as Processing triangles, as far as I know). This wouldn't record. Java's RAM use was under half a GB.

I then tried using a simpler sketch generating random points and making triangles from them. That will record 2,079,060 (69,302*30, since you ask) points (just over 693,000 triangles) without a problem. According to Windows, Java was using about 1.3GB of RAM at that point, out of 6GB I've allocated Processing in the preferences.

I hope that's of some use to you. Alternatively, feel free to tell me to stop abusing your code so cruelly!

monkstone

Re: Re: Announcing "povwriter" library (request for Windows / Mac testers)

2 years ago

Thanks for doing the test, your original findings just forced me into doing some re-factoring I should have done anyway. I have an idea for you to test, try exporting the sketch as an application before running it. Another thought that occurs to me, is there are issues with Windows and memory, somewhere I wrote diatribe (on the processing forum) about Microsoft short-changing Windows users (such that there are some issues with Java memory and Windows). I don't know whether that is relevant here, I know you've got 64 Bit system but I have lingering doubts about Microsoft ( ie they want to encourage you to buy Windows Professional how do they do that?), there might still be issues.

PS: For the two people who downloaded version 0.55, please note I have reloaded it with absolutely minor change ( texture for triangle is now all on one line), this helps with post edit of PovRAY file, as you now have option of changing texture by objects color, it is a feature I needed.
Everyone with versions prior to version 0.56 should download that version for enhancements/bug corrections (update 21 April 2011).

monkstone

Re: Re: Announcing "povwriter" library (request for Windows / Mac testers)

2 years ago

I think I might finally have cracked the problem, and the solution was very simple (zeroing vertex count outside of my degeneracy check).Version 0.56 of the library is now available to download, be sure to download the resource.zip, you will need this for the new improved library features. Many thanks for the testing, I think the following the SuperEllipsoidMeshBuilder by toxi is one of the sketches that would have failed previously:-

velvetkev..

Re: Announcing "povwriter" library (request for Windows / Mac testers)

2 years ago

Tried as an application, same result; at least, it failed at the same point- I don't know whether it is possible to access Processing console messages from an exported app?

It doesn't seem like a memory error to me, to be honest; I share your lingering doubts about MS but surely if it was just an out of memory error Processing would register that, rather than the array out of bounds? I've certainly hit specific out of memory errors before.

I'm well out of my depth here technically so I stand to be corrected.

Top Reply