https://github.com/codeanticode/planetarium

A Processing library for dome projection.
https://github.com/codeanticode/planetarium

dome java processing-library shaders

Last synced: 2 months ago
JSON representation

A Processing library for dome projection.

• Host: GitHub
• URL: https://github.com/codeanticode/planetarium
• Owner: codeanticode
• License: other
• Created: 2014-01-08T16:45:52.000Z (almost 11 years ago)
• Default Branch: master
• Last Pushed: 2019-07-28T19:14:53.000Z (over 5 years ago)
• Last Synced: 2024-05-13T14:32:19.059Z (7 months ago)
• Topics: dome, java, processing-library, shaders
• Language: Java
• Homepage: http://processing.andrescolubri.net/libraries/planetarium/
• Size: 1.27 MB
• Stars: 49
• Watchers: 12
• Forks: 14
• Open Issues: 9
• Metadata Files:
  • Readme: README.md
  • License: license.txt

Awesome Lists containing this project

README

        
The planetarium library is intended to project 3D Processing sketches on spherical domes, with minimal changes in the code of the sketch.

It is based on the FullDomeTemplate code from Christopher Warnow, available at https://github.com/mphasize/FullDome

### Work in progress

**DONE:**

- More accurate rendering.

- Variable aperture.

- Debug grid (shader-based).

- Toggle rendering of cubemap sides.

- 2D overlay image rendering in post. (has unfortunately a noticeable performance penalty).

**TODO:**

- Improve cubemap resolution (or at least visual quality).

- Implement rendering into background (2D) layer. (Possible implementation would be to send PGraphics as sampler into the shader, but it collides with the samplerCube, haven’t found a solution yet).

- Custom sweet spot.

- 4 sides should suffice for fulldome, need to rotate cubemap by 45° for that.

- Implement picking?

**CHANGES:** (technical)

- Switching to a raycasting approach in the cube map rendering stage. Uses quad with ray-casting instead of hemisphere.

- Cubemap sampling set to linear.

### Overview (original)

A brief descrition of how it works: a 360° view of the scene is generated by rendering the scene 6 times from each direction: positive x, negative x, and so on. The output of each rendering is stored inside a cube map texture, which is then applied on a sphere representing the dome. Hence, the library calls the draw() method 6 times per frame in order to update the corresponding side of the cube map texture (in reality, only 5 times since the bottom side of the cube map is not invisible on the dome).

So, it is important to keep in mind that if you need to perform some calculation only one time per frame, then the code for that calculation should be put inside the pre() method. Similarly, calculations that should performed only once after the rendering is concluded should be put in the post() method.

The library currently assumes that the the projector is placed in the center of the dome, the output will be incorrect if the projector is not centered. Multiple projectors are not currently supported.