Export 3D geometry to PDF

tessa

Hi all,

For the sake of printing my work, I need to have some high quality screenshots of my sketch. Especially the 'high quality' part has been a hassle, so I decided to export the 3D geometry to pdf, so that I can post-edit it in illustrator.

At first this seemed to be fine, but after taking a closer look, the order of the geometry looks different in PDF. I mean: cubes that are supposed to be behind other cubes, are now in front.

This is what it looks like in Processing:

This is what it looks like in PDF:

This is the code I use for recording:

    public void draw() {
        if(record){  
            beginRaw(PDF, "C:\\Users\\Public\\Documents\\EmTech\\Dissertation\\2014_interface\\140831_exp3_docu\\screenshots\\screenshotsoutput.pdf");
        }

        background(255);

[....] this is where I draw the cubes [...]

    if (record) {
        endRaw();
        record = false;
    }
}

As you might be able to see, the images above are quite blurry - they are screenshots (made with a software called ScreenPresso). So question: How to create high res images of my sketch? If it has to happen with PDF - how do I solve this problem?

Help me! Thank you!

Tessa

tessa

I'm using the library IGeo, and realised it might be more of a Rhino problem.. does anyone have experience with that?

koogs

with 3d you're getting depth sorting done by the z-buffer. so things that are nearer will obscure things that are further away.

with the pdf there is no z-buffer and things drawn later obscure the things that were drawn earlier. so you'll have to do it yourself - sort everything using distance from viewpoint, draw the furthest away first (painters algorithm).

distance can probably just be 3d euclidean distance of the centre of the cube (assuming everything is a cube, can't quite make it out in the resized picture). you can skip the sqrt to speed things up a bit.

screenshots (made with a software called ScreenPresso)

what's up with saveFrame() ?

tessa

Thank you for your reaction! I thought exactly the same.. must be it. But I checked many many times:

Before being drawn, the bottom squares of the cubes are sorted on their distance from the origin. The origin is the upper left corner of far upper left square, on the 'ground floor'.

Every cube is created by first drawing the square (^ in the order of this sorted list), then copying that square a bit higher, and then filling up the surfaces on the side, in between the two squares.

However, in the pdf's, it's often the bottom square and the side-surfaces that are the furthest away, that are displayed in front..

So I don't think that should not be the problem.. Do you think it's possible there's another cause?

Sorry, was that a legible explanation?

tessa

Oh, saveFrame() gives even worse quality..

But if there is something I can change about that, please tell me! Then all this hassle wouldn't be necessary.

koogs

that sounds ok, but the details are important. sorting by distance from origin is not necessarily the same as sorting by distance from the viewpoint. and the 2d distance isn't necessarily the same as the 3d distance. and the sides will also need sorting as some of those will be 'further away' than the top. best be safe and recalculate. you only need to do this for the frame you are capturing.

it's getting to the point where the code would be useful.