Messages

1

Work in Progress/Tests / Re: Corona in VFX / Experiences and conclusions

« on: 2017-03-10, 10:25:23 »

just curious, where were you working when you did these? just surprised and assumed the VFX houses that worked on those films where using maya and other renderers. i know star trek had some  max/vray but the others i didn't know.

Generally that would be true. But these are backgrounds/matte paintings. And those guys are generally allows to do whatever they need to get the background out. Paint it, render it in whatever, Photoshop and Nuke it until you get thumbs up. It is quite often one-man-job as most things cannot be reused (the mountain backdrop can't be in that many shots.. the monkey would) so there is much more flexibility in their tool of choice.

2

[Max] General Discussion / Re: Corona 1.x lost the most important core algorithms

« on: 2016-02-14, 07:03:34 »

Instead of comparing the specific settings, can you compare time to same quality?

3

[Max] General Discussion / Re: Corona 1.x lost the most important core algorithms

« on: 2016-02-12, 09:04:19 »

Can you please give us a screenshot of what exactly you mean by the "Checkerboard Algorithm."

4

General CG Discussion / Re: Disney's Hyperion renderer, anything special?

« on: 2015-10-12, 19:27:31 »

OK finally found it... from page 52:

http://blog.selfshadow.com/publications/s2015-shading-course/burley/s2015_pbs_disney_bsdf_slides.pdf

Superb paper.

Ah, didn't get what you mean there then. The disney BRDF is fairly nice, although our guys who worked with it claim that it is not as artist friendly when you are modelling something real. It really needs a good support from layering system. (Dunno whether they have it or not)

And Hyperion is really popular name it seems, our shading system is called Hyperion. :-D

5

General CG Discussion / Re: Disney's Hyperion renderer, anything special?

« on: 2015-10-12, 15:59:31 »

Why wouldn't they.. ? It's not early version of PRMan, they constantly boast about making it as super artist-friendly as possible. I am not expecting to see some kind of layout of various settings that might indeed be behind console only,
but they definitely have a layout for shader.

Why would they? The Hyperion team is really small and focuses on what they do best, the renderer. I'd assume that they do what just about every other big studio does, provide an API and try to keep the UI more or less the same, independent of the currently used renderer.
Without going into too much detail, our UI can (and often is) modified for each show, based on what the supervisors decide should be the reasonable knobs. (We are, more or less, PRMan compatible, so things are handled through Ri calls).

6

[Max] General Discussion / Re: Corona_VS_Cycles

« on: 2014-07-04, 21:40:24 »

Corona VCM does not use recursion and it still sucks :D

Well, yeah. I am really really curious about the practical usability of the PRMan implementation. And 19 will be free for non-commercial use, so I hope there will be a lot of feedback. The scenes they had in the fxguide article were pretty much like the scenes we had in the paper. No surfaces not visible to camera, so all photons generated contribute in one way or another.

7

[Max] General Discussion / Re: Corona_VS_Cycles

« on: 2014-07-04, 21:29:16 »

Recursion is pretty standard in rendering. But with Fermi and beyond, CUDA supports recursion just fine (supposedly). OpenCL doesn't, however. Apparently you can do it manually by creating a stack, but it seems pretty roundabout.

Recursion on GPU, especially if it is in a conditional, is never a good idea.
But even on CPU an explicit stack is often a better idea than recursion.
Function calls are not exactly cheap and if you have a reasonably light-weight function body (e.g., in ray casting), you should avoid recursion.
It cannot really be inlined (quite obviously), the function call will have to flush registers into memory, load function parameters into the registers, set stack and frame pointer and jump. If you have an explicit stack, the compiler has a much better visibility over the whole process and can, for example, make sure that some values that are used all the time (e.g., inverse ray directions) are kept in registers.

Admittedly, the basic path tracing can be written recursively without any really measurable impact (as the body usually does a TON of stuff), but then again, it is generally as easy to write it explicitly and it is not really roundabout.

For the record, the renderer used in the original VCM paper does not use recursion. :-)


Ad big textures: Yeah, big data kills GPU (this paper tries to address is, but the memory is always an issue on GPU: https://mediatech.aalto.fi/~samuli/publications/laine2013hpg_paper.pdf )

8

[Max] General Discussion / Re: Corona_VS_Cycles

« on: 2014-07-04, 21:09:26 »

Corona is doing it wrong, then ;)

Well, fix it then :-)

9

[Max] General Discussion / Re: Corona_VS_Cycles

« on: 2014-07-04, 20:46:45 »

Cuda doesn't even support recursion... madness!

Caught my eye, so.. this one thing doesn't really matter. If you need recursion in your renderer, you are doing it wrong anyway.

10

Gallery / Re: Test Car Jetta

« on: 2013-01-05, 09:50:26 »

Vigneting on scene that has mostly uniform black borders is kinda strange..

11

[Max] General Discussion / Re: IOR guide

« on: 2012-12-18, 23:31:55 »

If people are willing to model stuff like that, i.e., actually have a single polygon interface and specify what material is on each side of it, it would be the bestest way for all kinds of physically accurate renderers.

12

Work in Progress/Tests / Re: closedspaces

« on: 2012-12-15, 10:51:54 »

Useless note: All algorithms are "less effective" the longer they render. To reduce noise 2x, you need 4x longer time. But yeah, PPM is even worse at this.

13

Work in Progress/Tests / Re: MyLittleSomethingExperimental

« on: 2012-12-12, 06:33:49 »

Corona can do the same, and it definitely helps.

The other problem however is, that, as far as I understand the scene settings, flickering bright spots are actually correct.
If you have a lot of complex geometry (grass) that is highly reflective (mirror-like), then it is pretty much exactly the same as when you look at a road covered in broken glass on a bright day.
We don't have that many bright days now, but the ball season is coming, so maybe a better yet example would be a sequin dress like this:


Lot of tiny reflective surfaces, whenever anything moves it will flicker. And, thinking about the dress, I guess everyone will agree this is what should happen on it. Now if you model grass that (from distance) it looks pretty much like this, it will (and should) behave the same. Bottom line is, physical grass is not highly reflective, so neither should be its material in physically based renderer.
(I know it has been fixed, but I like the explanation with sequin dress, so there)

14

Work in Progress/Tests / Re: MyLittleSomethingExperimental

« on: 2012-12-11, 15:21:28 »

The one drawback of physically based renderer is that if you throw at it physically incorrect materials, it will blow up in your face.
The real pro solution is to yell at your modelers to get it correct (true story).

Glass under direct sunlight can be really really tricky with many internal reflections.

15

[Max] General Discussion / Re: Will Corona take advantage of announced Xeon Phi accelerator ?

« on: 2012-12-07, 12:31:51 »

Something to remember with both GPU rendering and this new phi processor is the RAM they have goes further.  This is because they don't need to store the OS + 3D program + whatever else on the GPU or Phi's RAM.  The only thing stored on the RAM on these will be the actual scene data with the rendering code needed.  This makes 8 GB on these cards work more like 12GB to 16GB or so on a full computer system.

Given how much a 6GB (and I think that's the top model for now?) costs, wouldn't it be better to buy 1-2 new PCs instead?