Giter Site home page Giter Site logo

Comments (10)

fogleman avatar fogleman commented on July 22, 2024

Not really. Most renders can take quite a while. Most of the 2560x1440px examples on the README took 30+ minutes, for example.

from pt.

mattgodbolt avatar mattgodbolt commented on July 22, 2024

Even using GPU resources and a very much simplified path tracer it takes a while to render with path tracing: this is the best I can find at doing "interactive" rendering. It's quite a lot to expect a pure CPU implementation could keep up.

from pt.

joeblew99 avatar joeblew99 commented on July 22, 2024

Am wondering if cycle based rendering helps ?
This is when the precision is lowered.

The other way is to allow tile based rendering. At least this allows speeding things up by throwing more servers at the problem.

from pt.

fogleman avatar fogleman commented on July 22, 2024

"Throwing more servers at it" is already easily doable. Each server can produce its own image and then the images can be combined. Since each server starts with a different random seed, the sampling will be just as if a single machine did 2x, 3x, etc the work.

This is what the combine script in the repo is for. :)

from pt.

joeblew99 avatar joeblew99 commented on July 22, 2024

Tiles based is different from what you do now ? To render one image 50
times faster, can I use 50 servers ?

I saw the combine script and was wondering...

On Fri, 5 Feb 2016, 03:00 Michael Fogleman [email protected] wrote:

"Throwing more servers at it" is already easily doable. Each server can
produce its own image and then the images can be combined. Since each
server starts with a different random seed, the sampling will be just as if
a single machine did 2x, 3x, etc the work.

This is what the combine script in the repo is for. :)


Reply to this email directly or view it on GitHub
#11 (comment).

from pt.

fogleman avatar fogleman commented on July 22, 2024

@joeblew99 See my slides on path tracing: https://speakerdeck.com/fogleman/path-tracing

Specifically the section on Noise. Maybe that will help you understand.

Here's the video if you want to watch: https://www.youtube.com/watch?v=x4oQsQ76OHY

from pt.

joeblew99 avatar joeblew99 commented on July 22, 2024

Yes i saw it thanks. I see what it is
This is all super but can I please get a straight answer to the original
question pretty please ?????

On Fri, 5 Feb 2016, 14:29 Michael Fogleman [email protected] wrote:

@joeblew99 https://github.com/joeblew99 See my slides on path tracing:
https://speakerdeck.com/fogleman/path-tracing

Specifically the section on Noise. Maybe that will help you understand.


Reply to this email directly or view it on GitHub
#11 (comment).

from pt.

joeblew99 avatar joeblew99 commented on July 22, 2024

It's just that I have used many rendering engines and yet to see anyone
solve the shared memory model aspects for distributed rendering of photonic
ray tracing.

On Fri, 5 Feb 2016, 17:35 Joe Blue [email protected] wrote:

Yes i saw it thanks. I see what it is
This is all super but can I please get a straight answer to the original
question pretty please ?????

On Fri, 5 Feb 2016, 14:29 Michael Fogleman [email protected]
wrote:

@joeblew99 https://github.com/joeblew99 See my slides on path tracing:
https://speakerdeck.com/fogleman/path-tracing

Specifically the section on Noise. Maybe that will help you understand.


Reply to this email directly or view it on GitHub
#11 (comment).

from pt.

fogleman avatar fogleman commented on July 22, 2024

@joeblew99

To render one image 50 times faster, can I use 50 servers?

Yes.

Tiles based is different from what you do now?

It is different.

If you wanted to run 256 samples per pixel, you could:

  • Run 256 on 1 machine
  • Run 128 on 2 machines
  • Run 64 on 4 machines

Etc.

Then you literally average the images and get a result equivalent to the full 256 samples.

from pt.

joeblew99 avatar joeblew99 commented on July 22, 2024

I would like to try it. Will have a look at see if the code has some sort
of render director.

On Fri, 5 Feb 2016, 23:27 Michael Fogleman [email protected] wrote:

@joeblew99 https://github.com/joeblew99

To render one image 50 times faster, can I use 50 servers?

Yes.

Tiles based is different from what you do now?

It is different.

If you wanted to run 256 samples per pixel, you could:

  • Run 256 on 1 machine
  • Run 128 on 2 machines
  • Run 64 on 4 machines

Etc.

Then you literally average the images and get a result equivalent to the
full 256 samples.


Reply to this email directly or view it on GitHub
#11 (comment).

from pt.

Related Issues (17)

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.