Skip to main content

Print-Quality Screenshots

For high-quality prints you need high-quality screenshots. This means very high resolution, and nice anti-aliasing. Just grabbing the screen produces rather unpleasant results (screenshot, 80 KB, 800x600 pixels). With normal OpenGL rendering you get rarely more than screen resolution, and anti-aliasing quality very much depends on your graphics board. So what to do? Tiled Rendering comes to the rescue. Instead of rendering the whole image at once, we render smaller portions of the scene, and then arrange the tiles into a large picture. However, just pointing the camera at each tile will not work as intended, the perspective would change from tile to tile. What is needed instead is to construct partial viewing frustums that together exactly recreate the whole frustum. This sounds like a lot of math, but actually it is quite simple:
gluPerspective: fov aspect: aspect zNear: near zFar: far tile: rect
    | cotangent radians  w h |
    radians := (fov/2.0) degreesToRadians.
    cotangent := radians cos / radians sin.
    h := near / cotangent.
    w := h * aspect.
    self glFrustum(rect left*w, rect right*w, rect bottom*h, rect top*h, near, far).
So I just extended the existing gluPerspective:aspect:zNear:zFar: method with a tile argument that gives the sub-rectangle in the viewing plane, where the whole picture ranges from -1 to 1. The only problem is to hand down that extra argument into the method. I ended up copying all the methods in the call chain, adding a tile: parameter. With the methods in place and a utility method to construct the right sub-rectangles, I could render the image from the first screenshot again:
| m c f |
m := CroquetGlobals theTeapotMorph.
c := m activeCamera.
f := c root snapShot: m ogl camera: c tiled: 12.
f := f magnify: f boundingBox by: 0.5 smoothing: 4.
JPEGReadWriter2 putForm: f quality: 90 progressiveJPEG: false onFileNamed: 'croquet-bf-4800.jpg'.
Instead of 800x600, this renders 12x12 tiles, creating a 9600x7200 pixels image. The result is scaled down with smoothing to yield an anti-aliased 4800x3600 image, finally compressing as JPEG gives a 1.5 MB hires screenshot. Beauty, eh? Never noticed that guy on the bridge before ;-)

Comments

Anonymous said…
yeah, nice detail. Looks like a soldier with his machinegun. But when it's so, there is a soldier on every treepeak...scary vision
Anonymous said…
Okay, I've added the tile:rect parameter to the gluPerspective and all the methods in the call chain. How is the rect passed from snapshot:tile to the lower level calls? Is there additional code that's missing or left as an exercise for the reader :)

I'd love to be able to take hi-res shots.
Vanessa said…
Well, TSpace snapShot:camera:tiled: calls
TSpace snapShot:camera:tile: for each rectangle. Then it goes down like this:
TSpace doRender:camera:tile:
TCamera initFrustum:tile:
OpenGL initFrustum:bounds:zNear:zFar:tile:
OpenGL gluPerspective:aspect:zNear:zFar:tile:

And because that is so ugly and boring I didn't want to post it. The only slightly interesting part is the construction of the sub rectangles from the integer tiles parameter:

ext := (2.0@2.0) / tiles.
0 to: tiles - 1 do: [ :x |
0 to: tiles - 1 do: [ :y |
pos := (x@y) * ext - (1.0@1.0).
snapshot := self snapShot: ogl camera: cam tile: (pos * (1@-1) extent: ext * (1@-1)).
...]].

Hope that helps?
Anonymous said…
Thanks. The missing piece was the construction of the sub-rectangles. I managed to compose the snapshots into a single Form and the result is a beautiful hi-rec picture.

Many thanks.
Anonymous said…
Thanks. The missing piece was the construction of the sub-rectangles. I managed to compose the snapshots into a single Form and the result is a beautiful hi-res picture.

Many thanks.
Howard Stearns said…
In the titled pictures, there are some discontinuities in the water. I assume these are at seams between tiles, and that they occur because each tile is rendered at a slightly different tea time?
Vanessa said…
The particle rendering in the waterfall is hacked to take rendering time into account for speed reasons (fewer particles are shown on a slower machine). If it was purely tea-time based there should be no discontinuities.

Popular posts from this blog

Frontend-only Multi-Player. Unlimited Bandwidth. Or: What is Croquet.io, really?

A multi-player web app needs a backend, right? What if I told you, it doesn’t? Read on for how Croquet gets rid of servers. No, really . Instantaneous Shared Experiences  is how we describe Croquet on our website. And while that excellently describes What Croquet does, as Croquet's Chief Architect, I wanted to share a bit about How we do that. So I wrote a Twitter thread . Here it is in blog form, slightly extended. Click the animation above if it does not play automatically Croquet lets you build completely client-side multi-user web apps. Read that again. Client-side. Multi-user. No I’m not kidding. I built it, I know it works. 😁  Croquet apps run completely client-side: can be hosted as a static web site no server-side code needed no networking code needed  Croquet is literally virtualizing the server: Instead of running code on a server (or in a serverless function) we run it as a virtual machine (VM) on each client.  Croquet carefully controls the inputs to these identi

Deconstructing Floats: frexp() and ldexp() in JavaScript

While working on my  SqueakJS VM, it became necessary to deconstruct floating point numbers into their mantissa and exponent parts, and assembling them again. Peeking into the C sources of the regular VM, I saw they use the  frexp ()   and ldexp () functions found in the standard C math library. Unfortunately, JavaScript does not provide these two functions. But surely there must have been someone who needed these before me, right? Sure enough, a Google search came up with a few implementations. However, an hour later I was convinced none of them actually are fully equivalent to the C functions. They were imprecise, that is, deconstructing a float using frexp() and reconstructing it with ldexp() did not result in the original value. But that is the basic use case: for all float values, if [ mantissa , exponent ] = frexp (value) then value = ldexp ( mantissa , exponent ) even if the value is subnormal . None of the implementations (even the complex ones) really worked. I

Connecting fields

Quick Recipe To connect field a in obj1 to field b in obj2 , use this: obj2 startScript: #b: when: {obj1. #aChanged} Now for the whole story ... Problem A colleague of mine wanted to make a drop-down list, where the options are not just set once, but provided and updated by the application. So, of course, when the options in the application changes, the items of the list widget have to be set to this new value. Nothing easier than that, just write a handler: onOptionsChanged     <on: optionsChanged in: app>     listWidget items: app options HOWEVER, he wanted to build this programmatically, not using a separate method. So, he easily came up with the following: listWidget startScript : #items: withArguments: {app options} when: {app. #optionsChanged} HOWEVER, this does not work as intended because the arguments to the script are evaluated only once, rather than every time the script is triggered. Well, this is what blocks are for, right? So this indeed works as intended: listW