Coder Social home page Coder Social logo

raytk's Introduction

RayTK

RayTK is a library of TouchDesigner components that construct raymarching shaders (and other types of shaders) with networks of COMPs using the TouchDesigner network editor.

RayTK consists of a set of operator (ROP) components, and a set of tools for working with them.

Getting Started

Check out this YouTube playlist for video tutorials!

Check out the Getting Started guide on the documentation website.

Troubleshooting

Check out the Troubleshooting Guide.

How RayTK works

Output ROPs

An SDF on its own is just a chunk of data. It needs to be sent to a special "Output" ROP, such as raymarchRender3d. These special ROPs take in one or more ROP inputs, construct a shader based on those inputs, and runs it in a GLSL TOP, to produce various types of image outputs. As the name suggests, raymarchRender3d uses the ROP network to build a raymarching shader, producing a rendered view of your scene, from some sort of camera. It's analagous to a Render TOP, which takes in some Geometry COMPs and renders them to an image.

Regular ROPs and Definition Tables

Each regular (non-output) ROP produces a single output, a DAT containing a data table describing that ROP and all of its inputs. They are known as "Definitions". Unless you are developing the core of the RayTK library itself, you will never need to deal directly with the contents of the definitions. They should be treated as an opaque data type. They're just the "thing" that comes out of a ROP.

Data Types

There are several types of data that a ROP function can return, including:

  • Sdf: An SDF result, including surface distance, material settings, and other properties.
  • float: A single floating point value. These can be used to drive the parameters of other ROPs, such as applying different amounts of rotation for different points in space.
  • vec4: A 4-part vector value. These can be used to drive the parameters of other ROPs, such as applying colors based on position in space.
  • Ray: A position and direction. These are returned by camera ROPs, to determine what direction the ray should march for each pixel of the output.
  • Light: A point in space, and an amount of color. These are returned by light ROPs.

There are several types of coordinates that a ROP can use:

  • vec3: 3D coordinates, which are the main coordinate type for SDFs and raymarching.
  • vec2: 2D coordinates, which are used in 2D SDFs, texture lookups, and screen UV coordinates.
  • float: 1D coordinates, which can be used for 1D vector fields.

Execution Chain

The Output ROP at the end of a chain of ROPs generates a shader along with things like uniforms, textures, etc. It then runs that shader in a GLSL TOP and outputs the results.

Each type of Output ROP has a block of GLSL called the "body", which contains the main() function. The body code will call functions from input ROPs for various purposes.

In the case of render2d (when using a vector field input ROP), it calls the input function once per pixel, to determine the color of that pixel.

In the case of raymarchRender3d, the main scene input is executed once per each step of the rays. In addition to the scene input, raymarchRender3d has an input for a camera function, which called for each pixel of output to determine where the ray goes, and a light function that is called by materials to determine colors.

How and Why Was This Created

The goal of RayTK is to allow artists without a strong knowledge of GLSL to render raymarched scenes, using the familiar elements of the TouchDesigner network editor. Raymarching has been around for a long time, but it is very different from traditional rendering, and it requires a strong knowledge of GLSL and vector math.

RayTK is a ground-up rewrite of a previous similar project, which was based on Patrik Lechner's TDRaymarchToolkit, which was based on hg_sdf and the work of Inigo Quilez.

License

RayTK by tekt (Tommy Etkin) is licensed under CC BY 4.0

raytk's People

Contributors

t3kt avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar

raytk's Issues

simplify handling of context types

Many ops don't really care about the context type. Ones that use an input can inherit from that, but ones that don't still need to specify a type. It should be possible to have ops that can be called with any type of context and just pass it along to their inputs if applicable.
There aren't yet any ops that use context type to determine things like parameter lists. So it should be easier to defer downstream compared to coordinates or input return types.

Improved validation for rop networks

Currently ROPs have input type validation, but it only shows up as script errors on inner comps inside them.

It would be good to be able to have a comprehensive view of all validation issues in a network.

magnet op

use vector field or metaball distance to distort space

export combined docs during the build process

Gather the help text for each category and ROP and generate a single combined file, or possibly a folder structure. It would use either Markdown (which is what the docs are currently written in) or html. The html option would be useful for having a generated website, using github pages.

icons for ops

Need to consider whether it's worth the use of gpu memory and/or tox size.

Developer documentation

Topics:

  • Using raytk-development.toe and the devel tools
  • Modifying a ROP type
  • Creating a new ROP type
  • The build process

Get rid of `Use Field` and similar toggles

Instead just rely on whether that input is connected.
Note that this could be a breaking change in a case where an op has an input connected but has switched it off with this parameter.

Better in-app help for ops

This could potentially be pulse parameters to launch the relevant help site page. Or some kind of TD-based UI.

shader export (ShaderToy, ISF, etc)

Consolidate a network of rops into a self-contained shader that can be used without the raytk framework.
ShaderToy export would require switching the params to global constants / macros.
ISF export would let parameters be specified as actual parameters.

way to move rop masters while still supporting version updates

Sometimes it makes sense to move or rename a ROP type without changing the actual functionality. Anything that was using that old one would then have a broken master path. That isn't really a problem for end user scenes, but if there's automated version updates, there would need to be a way to determine what the new path is. It might require keeping a table of old -> new names.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.