Messages

8971

[Max] General Discussion / Re: GPU

« on: 2012-09-11, 23:44:07 »

Short answer is: No.

I'll put the long answer together when I have the time. But its just that developing GPU renderer is much more difficult and the result can be fairly limited (supported materials, texmaps, fakes, memory limitations). GPU rendering would not plug well into Corona architecture at all.

And also there is no clear indication that GPU rendering is faster. Yes, there are some prototype ultra-fast ray tracers on GPU, but there were ultra-fast CPU ray tracers on Pentium 3 that reported comparable performance to Embree on quadcore i7. Both intel and nvidia have provided their promotional ray tracers, one on CPU (embree with crown scene), the other on GPU (design garage). I've tested embree on i7 and Design Garage on gf580GTX, and I have to say, I was much more impressed with embree, regarding the speed to scene difficulty ratio.

8972

Gallery / Re: can you dig it?

« on: 2012-09-11, 23:35:07 »

I can't wait for the whole thing ;). Do you have a build with motion blur (that is, post-alpha2)/do you need motion blur?

8973

[Max] General Discussion / Re: Material Converter

« on: 2012-09-11, 23:32:58 »

Have you considered using more standard OSS tools, for example versioning & publishing the script somewhere like github or sourceforge?

8974

[Max] General Discussion / Re: Material Converter

« on: 2012-09-11, 15:46:41 »

Hi,
this is great! If you need any support from my side, let me know. I can also distribute it bundled with future builds.

BTW: I'll be renaming and documenting all the parameters for the next build, so they have consistent meaningful names.

8975

[Max] General Discussion / Re: Sampling Worklfows

« on: 2012-09-10, 18:27:10 »

Hi,

this all should be improved in the next release:

1) GI should render with the same speed (maximal) regardless of the PT samples setting
2) Area light multiplier will go up to 999
3) It will be possible to crank up the quality setting of HD cache records, resulting in less flickering

8976

[Max] Resolved Bugs / Re: installation error

« on: 2012-09-10, 18:12:20 »

Germany. I've just arrived. And I have to say, German people have really weird flats ;))

8977

[Max] Resolved Bugs / Re: installation error

« on: 2012-09-10, 01:44:30 »

there isnt. As always: unfortunately, you'll have to wait a week or two for one. I'm moving to another country in 5 hours ;)

8978

[Max] Resolved Bugs / Re: installation error

« on: 2012-09-10, 01:31:46 »

yeah, x5355 is 65nm, you'll need legacy build for that machine

8979

[Max] Resolved Bugs / Re: installation error

« on: 2012-09-10, 00:56:39 »

Hi,
I've tried quickly googling the error, something popped up about error in MSXML library. Is it also win7 x64? Do you have the latest updates installed? Did you install http://www.microsoft.com/en-us/download/details.aspx?id=13523 on that machine? And what is the model of those xeons?

8980

[Max] General Discussion / Re: Sampling Worklfows

« on: 2012-09-09, 20:02:58 »

subpixel AA is only for antialiasing bright highlights. Display AA is just how well will zoomed-out image look in Corona VFB, it does not affect rendering itself.

Next corona version will come with manual, I hope I'll have some time for it next week.

You can post the render with stats and complete settings screenshot, I'll look into it.

8981

[Max] Resolved Bugs / Re: Zipper Bugs list

« on: 2012-09-08, 20:38:13 »

there is no alpha v3 ;)

8982

[Max] Resolved Feature Requests / Re: deadclowns wishlist

« on: 2012-09-06, 15:11:55 »

The problem with glossiness mapping is, that it is VERY dependent on concrete situation, so what seems fine in one scenario might be quite off in another. Also changing it would affect existing scenes, so I prefer not to mess with it, unless its really clear, that it is off.

Anisotropy is (should be ;)) relative to world coordinates

Displacement should never make holes, if the base geometry is sane and it has single smoothing group. Try using single smoothing group for your model, or at least the displaced parts

Why do you want reflection dim distance? That is one fake I do not want to implement, because I see no use for it. The overall attitude is that you should be able to get by in Corona with minimum fakes, because the renderer should handle most situation without them.

Other things are doable and will eventually get implemented. Unfortunately, I dont have time for it right now (1-2weeks)

8983

Gallery / Re: Humming-Top

« on: 2012-09-06, 13:45:24 »

I think it currently depends on situation (sometimes you get way too much blur, sometimes you get just the right amount), there will definitely be more work in this area to make the behavior more consistent and predictable. Unfortunately the 3dsmax texmap API is very confusing and not documented.

8984

[Max] Resolved Bugs / Re: DeadClowns Buglist

« on: 2012-09-06, 12:28:45 »

Hi,
I'll look at the other bugs when I have the time (in 1-2 weeks).

The color change is in my opinion because the internal color space of Corona was changed from sRGB to XYZ. Because XYZ gamut covers the entire range of visible colors, it allows Corona to deliver more accurate results than other renderers in situations, where extremely vibrant emissive colors are created (blackbody emission <1700K, sun at sunset/sunrise, heavily colored refraction attenuation, sky models near horizon (even in the middle of day)). The result still needs to be clamped and converted to sRGB, but the internal calculations are in XYZ, so the clamping is only where absolutely necessary.

Secondary effect of XYZ is that its primary colors are imaginary - they do not represent any real colors, they cannot be reproduced or perceived. This means that you never encounter for example XYZ(1, 0, 0). Such types of RGB colors (e.g. RGB(1, 0, 0)) are common, and cause many problems during rendering. XYZ transforms 1 0 0 to 0.41 0.36 0.18, which is much better to compute with. I will demonstrate with examples:

Scene lit with neutral light: there is practically no difference between RGB and XYZ:


Now lets light the scene with purely green light. Since the right wall is RGB(1, 0, 0), and the light is RGB(0, 1, 0), its component-wise product is RGB(0, 0, 0), which is black. XYZ handles the situation much better, since there are no purely monochromatic colors after transformation:


Blue light: same story, this time both walls result in black when using RGB:


Blackbody radiator which emits mostly red, but also other colors: since the left wall is RGB(0, 1, 0), it cannot reflect anything other than green. Because of this, the wall remains green and does not take any tint.


Now, back to your scene: I am guessing, since you are using blue object color, and yellow lighting, which is complementary color to blue, that in the RGB the colors are not mixing, and lighting is not affecting the color of blue object. In XYZ, the blue object is tinted (as is everthing other in the scene), producing the purple.

Now, what is "correct"? The answer is both - because the term "blue" can mean a wide variety of very different spectrums. XYZ just uses one that is not as extreme, resulting in more plausible shading, but occasionaly less vibrant colors, when it is needed for the material to correspond to the rest of the scene.

8985

Gallery / Re: Humming-Top

« on: 2012-09-05, 12:19:31 »

nice, what was the render time?