actorartathleteauthorbizcrimecrosspostcustomerservicedirectoredufoodgaminghealthjournalistmedicalmilmodpostmunimusicnewsworthynonprofitotherphilpolretailscispecialisedspecializedtechtourismtravelunique

Technology-LiveI’m Jules Urbach, the CEO and Co-Founder of OTOY. We are launching Render Token, the world’s first decentralized, peer-to-peer GPU network, built on Ethereum. AMA!

Sep 25th 2017 by JulesUrbach • 23 Questions • 83 Points

Hi there, my name is Jules Urbach – I am the CEO and Co-Founder of OTOY, a cloud rendering company based in LA. Earlier this month, we announced the next step in our journey – the Render Token and RNDR network. Check out our launch blog post and video.

I’d love to take this time to answer any questions about the RNDR network, cryptocurrency and blockchain. Ask me anything!

Proof: https://i.redd.it/36flm6ag4xnz.jpg

Q:

According to Jules, not if demand is there for rendering work: after 8 years of octane, 4 years of ORC, the demand for jobs exists at high order of magnitude beyond what ORC can deliver in a day. They also haven't yet added baking jobs from Unity/unreal, light field baking, reverse rendering (as with Facebook camera), and so on.

A:

I am also hesitant to throw this on the fire because it's still a bit early, but all the work we do in reverse rendering- basically photogrammetry, is identical cost to render work. We came to this conclusion when we signed up with Facebook for the x24 cloud processing work, which is all ORC based. It's in early alpha, but it's actually clear that this work will be a huge chunk of render power w need to allocate on ORC (and therefore RNDR). See Facebook booth at Siggraph2017: https://twitter.com/OTOY/status/894972675679965184


Q:

Well, that's why you buy at the ICO so you can start making money in Beta!

Furthermore, the way the RNDR system works, the more GPUs you have (at right OB level), and the higher your reputation score (basically the ledger of consistent RNDR job success), the more render jobs are prioritized to flow to you. If you have a fast (like 1000/100 mbps) Internet connection and a modern Volta GPU that can hit 1 OctaneBench/W, you will also have an advantage over slower connections / older GPUs in job allocation.

A:

This is an exact number - it is based on mapping the cost of rendering the identical work on ORC today ( ~medium latency - e.g. <day per shot) to reward for a node on RNDR. According to the source link I shard for ETH payout (at $11.40/day) the electricity cost for this rig is about $2/day for both ETH mining and RNDR work.


A:

We have millions of light field baking jobs we'd like to enable on RNDR next year (and would simply run out of capacity on ORC if we turned it on full stop - also V4 will make this work cheaper - which will mean more area coverage baking per RNDR) - a lot of Unity baking in the lightmapper (used by millions) is 5-20+ hours of work for a larger game level using enlighten or the PowerVR progressing lightmapper. And that is for very simple GI lightmapping.


Q:

Hi Jules, thank you for this opportunity! As earth scientist and VFX artist bipartisan, I have some questions, let's start with this: What do you think, regarding to the computing power, Render Token could be an alternative to today's supercomputer based weather and climate simulations/visualizations? Let's say we have an approaching hurricane and people in the endangered areas (& others as charity) can contribute with their personal computing power. Local media asks: People please switch on computers and log in to Render Token to gain the computing power and get more accurate predictions. Of course these occasions should be free of charge for weather institutions.

A:

Any N-body simulation work (and IMO weather, galaxy modelling ar all in that category) be a good git for RNDR network in Octane 4.x (which we plan to open up to much more procedural scene graph computation work to the API, just as we've done with textures/shaders in 3.08+). This is also why OctaneBench v4 complexity will definitely go up. What is currently a simple memory look up in V3 for primitive topology, and must be baked into a mesh or point cloud, could be procedurally generated at render time in V4 ORBX and give more precise results, and more likely, deliver results not possible, due to memory constrains, just through alembic/FBX/VDB baking as in V3 ORBX scenes.


Q:

How do you intend to let people use $RNDR network to render highly sensitive IPs without leaking information to render nodes? In other words, does using RNDR imply that the scene you are rendering is visible to the public?

A:

See my earlier reply on this topic to another poster - short term is reputation, certification of nodes is your filter (+ E2E crypto to the driver level, more secure than most RFs or sharing scenes on DB and paying each other for render time as they do now), longer term TPP and trusted compute kernels.


Q:

How do I invest in an ICO and what are the incentives for someone to do so? Do I somehow get money back on an exchange by selling my tokens.

A:

Registration for the token sale is on September 27th through the official website - rendertoken.com. The official sale is on October 5th. I strongly recommend you join https://rendertoken.rocket.chat/channel/RNDR if you are interested and need one on one help.


Q:

Hi Jules, I read your whitepaper and have got the following questions:

  1. How large is the current userbase of orc.otoy.com.

  2. Who are the team members who will work on the project. Of special interest are the team members with development experience on the Ethereum blockchain.

  3. What exactly is "Render Phase 1"? Your existing system running on orc.otoy.com using tokens for payment?

  4. I didn't understand the exact differences between render phase 2-4. It would be great if you could describe this a bit.

  5. You try to raise $134 million dollars which is imo a very large amount compared to other projects (e.g. ethereum raised 18 mio, golem $8.6 mio). Why do you need such a large amount?

  6. Will the Ethereum smart contract you use to handle the token distribution be reviewed?

  7. When will distribution of the rndr token take place?

  8. When and at which exchanges will the rndr token be tradeable?

Thanks!

A:

1) ~6 figures

2) We currently have a team page on our website, we have not included the full development team just yet.


3) Render Phase 1 is essentially the ORC system modified to be able to accept RNDR tokens and process work on external GPUs - think of it as an alpha. 

4) Phase 2 is our beta, where 'miners' (renderers?) will be able to turn on their GPUs for rendering headlessly and receive tokens for successful work. Phase 3 is the GM release of the full p2p distributed platform with tiered authentication and reputation points in final form. Phase 4 will include integrations with other key tokens such as BAT and SC/IPFS, as well as any other pertinent applications of RNDR as it relates to the overall blockchain sphere and - very importantly - IP/commercial rights and scriptable media rules that can be baked into the blockchain ledger with the render job (or component assets).


5) See above as well as my other post to similar question.


6) Yes, the smart contract review is up and reviewed here
: https://blog.zeppelin.solutions/render-token-audit-2a078ba6d759

7) The pre-registration on this Wednesday, September 27th. The sale will be on October 5th - both will occur on our website: www.rendertoken.com


8) We don't have that information this at this time.


Q:

Hey, Jules! Thanks for doing this AMA! A few questions:

  1. If you use x1 to x16 PCIe risers in a multi-GPU rendering setup, how much does this affect performance? What is the minimum required bandwidth? PCIe 1.0 x1 can do 250 MB/s, is this sufficient?

  2. 65% of the Render Tokens will go toward The Render User Development Fund (RUDF), which is autonomous smart contract control for render users requiring large rendering jobs to boost liquidity. This is good, but what will happen when the RUDF runs out of Render Tokens? Will more be generated? Also, what happens to the ETH from the smart contracts?

  3. With low enough latency, do you think it possible that the RNDR network could power games w/ realtime path-traced graphics? That would be awesome !!

A:

1) It won't be great for scene load times and out of core textures (if you run out of VRAM - 10-20% speed hit). But once the render starts, other than OOC, it's OK. Check out the OctaneRender FB group and render.otoy.com forums for direct user feedback on this topic.

2) In the far future, if the RUDF is out of tokens, then it would be only once the network is fully saturated, and there is plenty of liquidity in the network to sustain it going forward. We will never generate more tokens.

3) Yes, it has always been my plan to have this happen at some point in the future, but I think the way it will happen ideally is to pre-compute world space lighting rays (e.g. light field volumes or surfaces) for shared scenes and then send down chunks that can be locally reprojected on thin clients. This is exactly what we are doing for light field streaming demons on mobile I have been showing at GDC, Unite and Siggraph this year and last.


Q:

Wow, that could be also amazing for scientific visualizations! University has a simulated dataset and students can learn that with lightfield on AR/VR, pick on a part and refine etc. Do you have any timeframe for this light field stuff?

A:

Once Unity integration is further along, that will be the easiest way to leverage - simply because Unity is already used for so much AR/VR work (pretty much 100% of hololens for example), it will be easy for Unity devs to move from Octane light map baking (up next) to Octane light field baking. It will also be possible to do from other integrations, but market size of Unity is millions, and we're already integrated (and free for local rendering), so I expect a lot of development will come from this around LF render jobs - also expecting to leverage C# for even more granular customization, like we currently have in lua script nodes in ORBX render packages.


Q:

Want to try Octane for Unity, but my system is Linux based. Will be a Linux version of the plugin?

A:

I held off on Unity Linux integration for initial launch (Mac is next), because when we started this work, Unity Editor on Linux wasn't fully stable. Like all Octane integrations, we expect Mac/Linux support in Unity to be at parity (where possible) with Windows.


Q:
  1. What software packages will enable use of RenderTokens? I find that one of the main drawbacks of crypto is that it's a lot to take in for newbies. Can you simplify this process for the person paying for the job by simply integrating it in the software package they are already using so that they just pay USD for a cheaper/faster render?
  2. Please expand on Proof of Render. What does that mean, and how does the blockchain enable the proof? Is this like mechanical turk where multiple users get the request and the output is compared?
  3. Will we see Machine Learning / GPU algorithm usages with RenderToken, or is this limited to graphics only?
  4. How do you select the right hardware for the job? Will a GPU with a ray tracing ASIC get more ray tracing jobs?
A:

1) Here is a partial list - we also have Unity (built into 2017) and Unreal (coming later), and about 6 or so other plug-ins in development:

Autodesk® 3ds Max®

AutoCAD®

Autodesk® Inventor®

Autodesk® Maya®

Blender®

Carrara®

CINEMA 4D®

DAZ® Studio

GRAPHISOFT® ArchiCAD®

Houdini

LightWave®

MODO®

NUKE®

Autodesk® Revit®

Rhinoceros®

SketchUp®

Smith Micro's Poser®

Autodesk® Softimage®


Q:

What would prevent a malicious user from clogging the network by starting a large amount of (intentionally pointless) render jobs from different wallets, and then refusing to do the token exchange by stating the full res does not match what they wanted?

A:

Reputation points go both ways. Even on ORC, we make sure you spend and accept min. $50 before you can readily ask to spend more - may not work the same in RNDR down the line (priority vs. binary filtering likely), but the idea is similar - to not waste render work. To that end, RNDR job has a cost, and that is more than just tokens if you plan to burn/lock up tokens in escrow while you refuse to accept render work results - which BTW can be verified to be reasonably correct before it gets watermarked and offered up to user review. We have to check anyway for denoising and other things that thwart work result quality.


Q:

What would prevent a malicious user from clogging the network by starting a large amount of (intentionally pointless) render jobs from different wallets, and then refusing to do the token exchange by stating the full res does not match what they wanted?

A:

4) I am reasonably sure that newer GPUs will get more jobs (assuming demand keeps filling every node) for a simple reason, they can do more work per hour. This is going to be true of ASIC Ray Tracing HW (which BTW will need to be baked into a real GPU - so an ideal SoC would be half normal GPU @ 120 Watts, and half RT ASIC @ 120 Watts, and maybe 16 Watts for a TPU-like ASIC for denoising - just like AI ASIC HW already on Volta). See - https://image.slidesharecdn.com/otoygtc17futureofrenderingfinal2-170524000910/95/otoy-gtc17-presentation-slides-the-future-of-gpu-rendering-48-638.jpg?cb=1495662368


Q:

As a mining farm owner with 200+ rigs, when can I expect to start testing my hardware for use with RNDR? I would love to dedicate some machines for this. Currently they all run ETHOS. I hope the CPU/RAM requirements won't change, or worse, I have to run windows.

A:

Linux is OK. 8 HT CPU is OK. Would recommend 16 GB RAM (32-128 better), and 4 GB+ VRAM (6-12+ is better) on Pascal GPUs (but Maxwell and Kepler are OK). If you want to take on maximum possible render job work, the highest we've needed in terms of system RAM was 384 GB. The RNDR client is tiny, the Octane Render library is <25 MB uncompressed (Maybe 10-12 Mb compressed), and will auto-update like we do in Unity today.


Q:

That's great to know. Upgrading the ram in systems is the easy part. All my cards have at least 4gb vram ATM. Is there a test group I can join to get a head start so we can start using the network from day one?

A:

Right now, I think OctaneBench is all you need to make sure is working. The first thing the RNDR client will do after warm boot is run OB to confirm what the node can do.


Q:

What sort of connection would someone need?

A:

10 Mbps is minimum, but 100 Mbps up/down is recommended (downstream is more important)


Q:

are there any promising crypto/blockchain platforms that don't "waste" computational power as the currents ones appear to do?

A:

I would say that all coins based on a PoS model do not use GPUs as traditional PoW models would. However, RNDR is one that actually harnesses 100% the power of GPUs for what they were meant to do: rendering :)


Q:

how difficult would it be to forego the ethereum basis entirely (suppose you act as the trusted transaction database rather than using a decentralized scheme)?

A:

Anything is possible - but for the foreseeable future, and having thought this through very carefully, this is the plan.


Q:

Hi Jules,

How open will the light field ecosystem be on the RNDR network? Will users be strictly tied in to Octane, or will the specs for codecs and file containers be publicly available to allow the use of other renderers?

A:

I'd be deeply surprised if Octane ended up being the only renderer supported once we have exposed a full SDK for ORBX scene API after phase 3 - in fact Octane itself will us that to plug-in newer versions of itself on demand (similar to how it works in Unity today). ORBX container is fully public and submitted to MPEG. Link here:

https://drive.google.com/drive/u/0/folders/0B8PDCm1Z-pMKZEFEb3BPOWE3c1U


Q:

You claimed that the "semantic history of every photon rendered and every surface evaluated in a render job is encoded in the blockchain"

Considering that every pixel in a rendered frame contains information gathered by hundreds if not thousands of unique photons, how in the world can this scale on a blockchain?

A:

The hash of every asset in every render job, and the hashed result of render job is in the BC ledger, pretty much like ORC. If you had to look up the GUID of of an ORC render job, or had an AI do it for you (and it can), you could validate all the assets used for the render, who uploaded it first, and when, and so on. This is a byproduct of ORC, but a feature of RNDR, and will be used for IP validation and exchange of assets going in and coming out of render work.


Q:

Hi Jules, since you want to raise a lot of money, what are you planning to do to make RNDR a success? I mean this non-technical. What are your specific steps towards your ultimate goal? I see nice ideas like SiaCoin which didn't really took off and I'm worried that RNDR could be the next ICO in that line.

A:

I am going to keep doing what I have always been doing: https://uploadvr.com/jules-urbach-holodeck-quest-otoy/

BTW a holodeck is a nice milestone (likely in years, not decades, thanks to improvements in light field displays I am already seeing), but not the end goal. That would be more like this: https://medium.com/@rendertoken/life-after-automation-the-rendering-economy-ac0fb38ca50b


Q:

I agree. Would like to know how many tokens, as well as cost.

And would be nice to have a FAQ page that addresses these questions, in order to get more people to join.

A:

FAQ is planned and feedback is welcome via https://rendertoken.rocket.chat/channel/RNDR


Q:

Have not done much research, so sorry if this is obvious, but how is RNDR token different from Golem?