A Photon Driven Economy

By Jules Urbach

Building on our introduction of the RNDR token, this post explores key concepts of monetization and value built into the RNDR token economy:

• RNDR is more than a decentralized exchange of rendering power across the blockchain. It is also a foundation for monetizing authorship in a marketplace where virtual creations and ideas are exchanged with meaning and intent as their main sources of value — added on top of a base “manufacturing” cost.
• These base “manufacturing” costs in our system are measured in units of virtual RNDR token energy spent bouncing photons of light through an object or scene, until it appears completely real inside our fully simulated world, backed by the actual laws of spectral physics (up to the diffraction limit of light).
• The semantic history of every photon rendered and every surface evaluated in a render job is encoded in the blockchain and can be used to validate the original ORBX package file, scene graph, creator defined input/output limits per graph node (e.g. runtime eval of script/job node), and the authors of each sub-asset (texture, mesh, script). This allows vectors of token value to flow back to authors in whatever way they choose, and to assign commercial token flow terms for loading and using their published ORBX packaged nodes inside a render job.

The Monetization of Light Transport:

The entanglement of photons in a render job is a powerful framework for higher level monetization services.

Light rays encoded in any render job on the blockchain can be used in operations that validate each of its authors’ source assets. This can be transacted upon at instances where the render job’s result is observed in a unique viewport during real time rendering of this data.

Monetization systems built on this framework can simultaneously protect user privacy as well as authorship rights.

Sharing and Distribution

Blockchain backed token values can be encoded by creators as sharing and recomposition rules for their rendered assets.

In socialized AR/VR experiences that mix and compose ORBX Media packages, there are several scene/photon driven render token systems that can be applied.

For example, unique assets may have a simple script node in their render job, which limit the maximum instances that can be ‘owned’ and shared through the blockchain, either globally, or through some filter based on an ORBX root scene ID.

OTOY provided a window into this functionality through our collaboration with John Carmack and Disney in 2016 to drive Oculus Social. Users were able to load an Oculus room ID or public URL (such as Disney.com, Marvel.com etc.) to access WebVR/AR assets.

Similar rules can make it so that earlier instances of ownership (of otherwise identically rendered assets) transacted on the blockchain determine priority for scarcity rules in shared social sessions. For example, in a shared virtual space game with a fixed maximum instance count for a certain object (i.e. only one NCC 1701 D USS Enterprise per shared world is allowed to exist), this concept allows identically rendered assets to have a delta value. This could be exchanged by users wanting to bid on the earliest creation/publishing time of an object render instance as validated by the blockchain.

Lastly, more granular rules can be applied at the scene graph level beyond just numerical uniqueness. For example, only the first instance of a rendered ORBX object could be allowed to render uniquely at 1:1 scale (globally or in a filtered scene), with every subsequent copy published to the blockchain reducing this scale by a factor of 2. This would make a Death Star sized object shrink to the size of a marble by the 24th copy.

What binds each of these examples together is how they are structured by rules set by their creators or publishers. Inside each RNDR token transaction backed by an ORBX package, there is a hash of all assets in the system used to build the source render graph for the render job (this is fully functional on the centralized render service we have now). This means flow of render tokens that utilize and render each asset can be spread back to contributors of these assets (e.g. 3D models, texture packs, industrial scans, toolchain services) whenever they are transactionally connected back to their source render job (either once, or recurring).

RNDR as part of a larger ecosystem

The RNDR token can augment and connect with other blockchain based token systems which provide orthogonal value outside of the Render Network.

For example, an ORBX output package, validated on the blockchain as a baked rendered media experience for WebVR/AR (e.g. OTOY’s work with Samsung Internet and Facebook 6DOF streams) can include a lua script as an entanglement metric that gathers anonymized view photons per second through an ad-based blockchain partner such as BAT (Basic Attention Token).

This process would convert attention-based view rays to BAT for ad-based monetization (rays are mapped to pixel area per seconds as in Brave browser’s 2D ads). This process then sends a portion of tokens back to the author and publisher of the source scene, as well as sub-authors whose sub-assets were used in the material node that the attention vector last bounced off of. This is just one way that we can partner with existing blockchain based token ecosystems to build a truly decentralized economy of connected services that work together — as modules and nodes — just as the open web was intended to do.

RNDR and Decentralized Workflows:

ORBX is critical for splitting blockchain based render job work from host 3D applications

The current state of open 3D interchange formats (at a scene and application dependency level) is too fragmented to reliably support the RNDR network efficiently, or universally, across all 3D tools and applications that creators could use to start a remote render job.

Fully distributed rendering and deep chain of authorship and validation is viable on RNDR because of the ORBX interchange system. ORBX uniquely provides an airtight packaging and transmission format for portable rendering across any distributed rendering network. ORBX render jobs have zero dependencies on the host 3D application that created the scene.

A one-click ORBX export from a 3D content creation tool fully decouples all assets and code needed to perform a remote GPU render job (on LAN, cloud and soon RNDR). This always works regardless of the host application — and is vital in providing an open architecture for high efficiency distributed and reliable rendering. ORBX interchange has been part of OctaneRender and all Octane 3D app plug-ins since version 1.5, and has been validated and hardened for real world use over many years as well as millions of render job hours, both on local render farms and our cloud rendering service.

Challenges of distributed rendering across a fragmented 3D app ecosystem

In existing workflows, dependencies that require a host 3D application to be present in order to render outside of the artist’s machine are huge obstacles to decentralized rendering at scale.

Having to do this would require us to further handle the transfer, licensing and operation of every possible 3D host application used for rendering (and any plug-in it uses) inside a VM. This would need to work across any part of the RNDR network before we even could begin a remote render job .

This is very impractical, especially if the 3D application:

1. Has a huge disk footprint (C4D is ~10 Gb)
2. Isn’t portable (as we learned building Autodesk streaming service on EC2 for Revit, Max and Maya in 2013)
3. Doesn’t exist on an OS we want to render on (3DS Max is PC only)
4. Is not commercially available for distributed usage based rendering

The ORBX Solution

By contrast, a single ORBX export (and import) works in over 25+ applications ranging from C4D, Blender, Maya, Max, Sketchup, AfterEffects, AutoCad, Revit, Unity, Unreal, Daz, Houdini, Motion Builder, Poser, Carrera, Lightwave, Autodesk 360, Archicad, Rhino, Nuke, XSI, Photoshop and many more.

There is no mainstream 3D content creation tool we are aware of wich doesn’t support an ORBX and Octane integration. The Octane SDK is available to third parties that want to expand this ecosystem to new tools.

In 2017, two important partnerships increased the reach of this system:

1. ORBX interchange in Unity is integrated for free (along with Octane) and now available to 7 million Unity Developers.
2. OTOY and Facebook at F8 announced a partnership with ORBX as the interchange format for the Facebook 360 6DOF cameras. In this case the ORBX scene is generated as a reverse rendering job on ORC (e.g. Light Field camera captures are loaded into a lua module that generates depth maps, then exports a renderable .ocs+ORBX file). This is an important milestone for mapping out ORBX’s value as a renderable format for photogrammetry captures — which will almost certainly need to move to real time (just as path tracing) to support ideal mixed reality composition, and IOT sensor or drone swarm processing.

Proof of Render Work on Decentralized Networks:

Proof-of-Render vs. Proof-of Work

There are many challenges that must be solved in order for a blockchain-based render economy, built on proof-of-render, not just proof-of-work, to deliver trusted exchange of RNDR token value, backed by Ethereum smart contract VM bytecode at the last layer.

Proof-of-work that can be verified entirely through computable math code or logic such as Ethereum smart contracts is a starting point for negotiating more complex blockchain work. In the case of cryptocurrency that backs generic data streaming, storage and validation, proof-of-work can be encoded in the smart contract as a function of generic bits, seconds and deterministic compute cycles.

Mapping completely general computing results, such arbitrary code that runs in a VM and does some unspecified operation, requires a domain specific program to be created to potentially verify the results, and facilitate the exchange. The simplest use case might be running a program on the blockchain that mines crypto, but running a render job that matches the intent of the human is not something that is easily computable.

Proof of Render On Trusted and Untrusted Networks

In the RNDR network, jobs that are run on nodes connected to the blockchain that are certified as trusted (e.g. in a datacenter with MPAA certification), fulfillment and security of render work is less of a risk, since the renderer is running on a known system with a known SLA and legal certification of data and security and privacy.

On the blockchain, distributed RNDR jobs that are allowed to run on any arbitrary endpoint — only based on reputation of the endpoint within the network — have to assume they will operate in a fully untrusted environment. This means the render job source data and validation of its results required to award a Render Token need special consideration.

Over the past 10 years, OTOY has built secure and distributed enterprise-grade systems and protocols for partners like Autodesk and Facebook, where ORBX modules and data are securely loaded and processed on end user machines. These will be critical building blocks for fraud-proof rendering verification and minimizing risk of user data.

The first layer is our mesh based delivery of ORBX modules on encrypted sockets (no data touches disk), and execution in encrypted pages in CPU memory. This will help protect render data only up to the point where it is fed to the GPU for rendering, at which point it must be decrypted. Homomorphic encryption would be too slow, so it is not a good option.

The solution we do expect to leverage down the line would be encrypted GPU kernels that completely encrypt the distributed render work end-to-end (same as with high end video now for GPU textures). We’ve been in discussions with MPEG, AMD, NVIDIA, Khronos and others to fast track this support in their drivers.

AMD already has a very promising initiative we are exploring with them for use in RNDR, related to TPP: http://www.amd.com/en-us/innovations/software-technologies/security

This is coming to their CPUs, APUs and GPUs, which in theory would provide secure end-to-end encrypted rendering of Octane/ORBX jobs on newer AMD GPUs. This security is already working in AMD APUs shipping in consoles like the Xbox and PS4.

Watermarking and Encrypted Escrow Transactions

Proof-of-render done on new or untrusted networks will have a system in place to validate work before executing a token exchange. It is based on Octane’s watermark system, continuously used since 2009, which lets users test Octane for free but only be able to remove the watermark in the paid version — which they can upgrade to at any time.

On untrusted systems, all rendered output will be sent to the author with an unencrypted watermarked preview of the job, as well as an encrypted unwatermarked result. If the author of the render job accepts that the preview render (which could be a movie or volume render, not just image) is acceptable, the render token is awarded to the other party and access to the unwatermarked data is granted. Timeouts and reputation points can allow validation of proof-of-render to be more automated at the author’s discretion.

Lastly, the Octane AI denoiser is very good at filling in missing samples (e.g. completing the work needed to go from 10 samples to 5000), and can be optionally used to validate that the sample count of an untrusted watermarked render matches a certain threshold of completed work based on a preview sample and other factors (including whether AI denoising itself was used on the other end to cheat the system).

An Open Metaverse with RNDR: a Photon Powered Economy

The Internet was built on the promise of distributed computing and the open exchange of ideas and data. As we move from hypertext and hypermedia to a fully immersive metaverse built on complex interactive 3D scenes, the challenges and opportunities are exponentially greater.

The RNDR Token, powered by the blockchain, uses the act of creation — rendered by the laws of physics and light — to open the door to a new model of value exchange and a truly decentralized Metaverse.

To find out more about the Render Token, please visit www.rendertoken.com and feel free to join us on our RocketChat, Twitter and Reddit!