kevinmackenzie / opalfalcon Goto Github PK

Something is wrong with renderPhotons . It does not have the same "zoom" level as the ray-traced version, so I am assuming this is an issue with the transformations (maybe they're being applied twice?) somewhere in the render function, but its also possible the ray-tracer isn't zoomed in enough?

Investigate

Monte-Carlo methods would improve the appearance of the images with the same performance. The problem is that random number generation is stateful and the current implementation of the ray-tracer is pure. We can isolate monadic operations to the top-level (traceRay, sampleLights) and keep most operations pure.

see https://en.wikipedia.org/wiki/Constructive_solid_geometry for reference.

• Cubes
• Spheres
• Cylinders
• general extruded planar surfaces (triangle, quads, CURBS, etc)

We should control the things we export from each of the packages since a lot of functions are for internal-use only, especially those that assume the context functions will be called in (since they are for decomposition and to support future external-facing functions).

Right now, the only light we get is that hitting the background is white, but we need to have real light objects in our system so we can calculate shadows.

We only have spheres and planes, but supporting arbitrary polygon-based geometry would be really nice

Dynamically debugging FP, especially haskell, isn't very easy, but writings tests is. It would be good do get a good barrage of tests before the code gets too unwieldy.

The only object collection is the ObjectList, but it would be really good to have BSP or kd trees for general use for bigger scenes.

We currently output to files, but it should have a real-time interface that supports:

• Scene navigation / camera control
• resolution control
• any MC settings
• dynamic resolution
• more stuff TBD

The way vectors were designed was to make vector operations easier to write to start with, but they may be inefficient. Even in a simple scene the render time is too high. Look into faster methods of doing this math that expose the same interfaces. Ideally, vector components won't have to be individually accessed outside of internal vector functions.

A key element to the ray-traced images being believable is a global-illumination model. Currently only direct lighting is supported. Photon mapping seems like a good candidate.

There are several instances where camera properties are required and passed ad-hoc, but it should be its own object in the scene containing.

The current material model is a good start. The concept of the AppliedMaterial is good since it gets around some of the troubles of general purpose materials for general-purpose geometry. Currently, the solution for materials is established on a per-object-type basis, but we should establish object-type materials that map to certain kinds of geometry. Textures would be nice for diffuse-only surfaces.

Make sure that the "incoming" vector consistently refers to the tip of the vector pointing into the surface or the "tail" of the vector pointing away from the surface.