Point cloud experiments with Sunflow
This is just a quick heads up about my ongoing efforts to create a Processing library to integrate Sunflow, an opensource global illumination renderer, into my toolchain. Initially, I'm only after exporting generated 3D scenes/geometry, shaders and various render specific settings to Sunflow's scene description format.
This series and the previous images (with the random triangles) were fully rendered outside Processing. Currently this is far more flexible than my other plan to have Sunflow wrapped in a PGraphics. For one, the export option allows for easier tweaking the scene parameters (the global illumination lighting models have a lot of parameters and options to explore) as well as batch rendering frame sequences from the command line. This is far more resource friendly and efficient than handling the rendering directly from within a PApplet context, especially with high quality rendering times often lasting several hours per frame (you can get decent preview within seconds/minutes though).
So the library currently only supports triangulated geometry and I still need to make a decision & come up with a better mechanism to support various Sunflow primitive object types. This decision might involve breaking away from the restrictions imposed by my current implementation, which is based on Processing's
By popular demand, here's some more background info about the making of the 3 images above.
The lastest version of Sunflow (still unreleased, need to check out from SVN) is featuring a new ParticleSurface object primitive, which is the basis for the images above. Reading through the source code, I quickly figured out this type of object is only based on 2 parameters: a "point cloud" of 3d particles and a global radius size used for each particle. In order to quickly test drive & define some point clouds of my own, I wrote this absolute basic generator script below:
The next step then is to reference this generated data from a Sunflow scene file (You'll need to edit the file name near the end)...
Save this file using the ".sc" extension and open it in Sunflow. Use the "IPR" renderer for easier previewing. You might need to adjust camera settings to better fit your generated particles.
If you end up successfully rendering something and have a flickr account, please do submit images to the newly created Sunflow group pool. Thanks!
Finally, I'm no expert in global illumination (in fact playing around with Sunflow are my very 1st baby steps with that technology). Everything I know so far about the SC file format is collected from examining the source code of the SCParser class and the demo files you can download. If you have any questions about rendering with Sunflow (not related to the tie-in with Processing), please check the official forum @ sourceforge...
![]() using a glass shader | ![]() ambient occlusion (AO) | ![]() AO & depth of field |
This series and the previous images (with the random triangles) were fully rendered outside Processing. Currently this is far more flexible than my other plan to have Sunflow wrapped in a PGraphics. For one, the export option allows for easier tweaking the scene parameters (the global illumination lighting models have a lot of parameters and options to explore) as well as batch rendering frame sequences from the command line. This is far more resource friendly and efficient than handling the rendering directly from within a PApplet context, especially with high quality rendering times often lasting several hours per frame (you can get decent preview within seconds/minutes though).
So the library currently only supports triangulated geometry and I still need to make a decision & come up with a better mechanism to support various Sunflow primitive object types. This decision might involve breaking away from the restrictions imposed by my current implementation, which is based on Processing's
beginRaw() mechanism, just like the existing DXF/PDF export libraries. What's fine for these other formats is not quite good enough for my case. For example, using sphere() together with beginRaw() in Processing will currently export a triangulated version of the sphere, not the pure mathematical surface. The problem is, there don't seem to be any API hooks in PGraphics for various drawing commands and or state changes (box() is similar, but not problematic in this case). Unless I'm really missing something quite obvious, "recorder" PGraphics classes only get involved with and get access to the final, world transformed geometry. For my purposes I'd also like to get access to the current fill/stroke colours and transform matrices. Because PGraphics has "protected" access and doesn't provide any getters for these properties, users are currently forced to duplicate some of these drawing commands in order to keep the library in synch with the "main" PGraphics instance used. So am still wading through the source(s) and trying to come up with a more user friendly solution...By popular demand, here's some more background info about the making of the 3 images above.
The lastest version of Sunflow (still unreleased, need to check out from SVN) is featuring a new ParticleSurface object primitive, which is the basis for the images above. Reading through the source code, I quickly figured out this type of object is only based on 2 parameters: a "point cloud" of 3d particles and a global radius size used for each particle. In order to quickly test drive & define some point clouds of my own, I wrote this absolute basic generator script below:
// point cloud generator for
// Sunflow's (v0.7.0+) ParticleSurface primitive
void setup() {
try {
FileOutputStream fs = new FileOutputStream("c:/molecule_"+(System.currentTimeMillis()/1000)+".pointcloud");
DataOutputStream ds = new DataOutputStream(fs);
float x=0,y=0,z=0; // start at origin
float scl=0.25;
float dim=50;
for (int i = 0; i < 250000; i++) {
// randomly progress within the bounding box
x=max(-dim,min(dim,x+random(-1,1)*scl));
y=max(-dim,min(dim,y+random(-1,1)*scl));
z=max(-dim,min(dim,z+random(-1,1)*scl));
// write out coordinates as raw floats
ds.writeFloat(x);
ds.writeFloat(y);
ds.writeFloat(z);
}
ds.flush();
ds.close();
println("done.");
}
catch (Exception e) {
e.printStackTrace();
}
}
The next step then is to reference this generated data from a Sunflow scene file (You'll need to edit the file name near the end)...
/*
pointcloudtest.sc
sunflow test scene skeleton
2006-12-13 toxi.co.uk
*/
image {
resolution 768 432
% resolution 1920 1080
aa 1 2
}
background {
color 1 1 1
}
accel kdtree
filter gaussian 2 2
bucket 128 hilbert
%% camera definitions
% uncomment this one to enable depth-of-field
/* camera {
type thinlens
eye 0 10 70
target -20 -20 0
up 0 1 0
fov 60
aspect 1.7777777
fdist 27
lensr 0.85
} */
camera {
type pinhole
eye 0 10 70
target -20 -20 0
up 0 1 0
fov 60
aspect 1.7777777
}
%% define a simple area light for soft shadows
light {
type meshlight
name l1
emit 1 1 1
radiance 48
samples 32
points 3
-60 20 60
0 60 -60
60 20 60
triangles 1
0 1 2
}
shader {
name a
type amb-occ
bright .4 .9 1
dark 0 0 0
samples 128
dist 16
}
object {
shader a
type dlasurface
% need edit this file path
filename c:/molecule_1166058556.dat
radius 0.125
}
Save this file using the ".sc" extension and open it in Sunflow. Use the "IPR" renderer for easier previewing. You might need to adjust camera settings to better fit your generated particles.
If you end up successfully rendering something and have a flickr account, please do submit images to the newly created Sunflow group pool. Thanks!
Finally, I'm no expert in global illumination (in fact playing around with Sunflow are my very 1st baby steps with that technology). Everything I know so far about the SC file format is collected from examining the source code of the SCParser class and the demo files you can download. If you have any questions about rendering with Sunflow (not related to the tie-in with Processing), please check the official forum @ sourceforge...




5 Comments:
Sunflow looks amazing. As you know, I've been looking more at 3D object output recently. I'm interested both in rapid-protoyping and static hi-quality renders. Takes me back to the days of hacking with POV-Ray, my first love.
How difficult would it be to get triangle data from Processing into SunFlow? I've written a RawSTLWriter for Processing to deal with the STL format, which I'll release soon.
POVRay was also my first encounter (not quite a love!) with "real" 3D. The thing I like most about Sunflow's is its comprehensive Java API, so you can generate geometry, define your own shaders and extend the renderer itself directly in Java... that's great!
Anyway, triangle export is kinda working already and I will post it ASAP. I'm off from work this week, so hopefully will get (more) stuff done on this front.
how do i change particle type to a 3d model instead of a point?
Hey I was looking trough your blog and I am wondering if you managed to use sunflow on the sun grid. I was thinking that it would be a good idea and I want ot know if you have anything work out. I love your stuff and I am looking to this processing sunflow library.
Is this Processing example meant to output a text file or binary? I get the dat file, but when I try to loas the sc file into Sunflower, I get this error:
Warning: [API] Unrecognized object type: dlasurface
Thanks!
Post a Comment
Links to this post:
Create a Link
<< Home