Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - Ondra

Pages: [1] 2 3 ... 14
General Discussion / SIGGRAPH 2019 - LA - Who is going?
« on: 2019-05-29, 11:04:09 »
Corona will be there ;). We will have 2 talks, booth with interactive demo (in cooperation with Intel), and there will be chaos party... who is in? :D

General Discussion / Anyone in london Dec 12-16?
« on: 2018-11-05, 21:43:54 »
Hi all,
I will be travelling to London between 12th and 16th december, and I am wondering if somebody works there in a studio with Corona? I would like to stop by to chat about your needs and future Corona development. Let me know (preferrably on skype/private message).
See you there!

Gallery / First renders in Corona (ever)
« on: 2018-05-11, 16:40:24 »
From time to time I need to find the first renders ever made in Corona. I dont remember posting them to the forum in one place, and I could use convenient location from where to retrieve them... so here it goes. Some 2009 goodness!

First render saved as image, ever:

First render with multiple objects:

First shader - "electron microscope"

First "art" - snowman

Advanced stuff - Diffuse BRDF, point lights, and shadows. Still only spheres supported as primitives. It is way easier to implement sphere than triangle.

Early triangular meshes. Note wrong normals

First image with terminators problem ;)

First glass material. Note the image being too dark - no linear workflow

Funny bug in acceleration structure

General Discussion / SIGGRAPH 2018
« on: 2018-05-09, 13:42:40 »
anybody coming to Vancouver for this year's SIGGRAPH? Corona team will be attending with 3 people, presenting a scientific paper on our adaptive light solver, and doing a extended course on rendering in Archviz, together with Vlado from Chaosgroup, Thomas Ludwig from Indigo, and Henrik Jensen from Keyshot.

As always while at conferences, we would love to grab a beer or two with our users - it is just that at siggraph, they are harder to come by than at our usual venues :D

Off-Topic / Food fight!
« on: 2018-04-12, 17:14:15 »
It came to my attention that not everyone knows about this 2012 CGI flop with $65M budget starring Charlie Sheen... enjoy ;)

Jobs / C++ developer - Join Corona Renderer team!
« on: 2018-04-03, 18:48:22 »
What the hell, trying cannot hurt us ;)

We are looking for skilled C++ developers to join the Corona Renderer team in our Prague office. We have multiple positions open, which will be discussed with candidates based on their specialization/skillset. See details at

[Archive] Corona Scatter 2.0 / Project finished!
« on: 2018-02-05, 19:41:16 »
This is now archived forum section for feature push on Corona Scatter, made possible by working with external programmer. This project is now finished and all developed functionality is merged into Corona Scatter currently available in every Corona for 3dsmax installation. New features and improvements are now added to the Scatter by the Corona core team. If you have any further bug report or feature request for Corona Scatter, please use the bug reporting/feature requesting of Corona Core/3ds Max plugin

today, we unfortunately have to announce stopping the Corona for Sketchup project, as announced here:
To put it simply, we found out plugin development is much harder than we originally anticipated, and we had developers come and go off the project before significant progress was made. VRay for Sketchup made enough progress in the meantime that we can now offer it to everyone wanting easy and full-featured photorealistic rendering in sketchup. We will focus on Corona for 3ds Max, Corona for C4D, Corona Standalone, and Corona Scatter development instead

The questions is simple - V-Ray has solved a lot of problems before us, and now we have access to those solutions. What feature that V-Ray already has would you like to see in Corona? Note that this is just for our inspiration, and we don't have time to do much porting before 1.7 release, so we are talking about 1.8 and later

News / Corona Road map for 1.7
« on: 2017-04-14, 21:24:12 »
with the 1.6 version practically done, we have updated the roadmap so you can see what is planned for 1.7:

Let us know your thoughts!

we would like to fix the black passes in DR problem before 1.6 is out. To do this, we ask all users who experienced this problem to answer these questions:

1) How often does the problem happen? Every DR render, most renders, occasionally, rarely, ...?
2) Do all slaves contribute to the problem, or just some? Is the problem always localized to some specific computers, or is it random?
3) Can you send us logs from DR server from the faulty slave computer?
4) are there any errors or warning displayed when it happens?
5) Can you use the "retain EXR" feature and send us the EXRs from the faulty slave?

This would really help us nail down the problem, thanks!

Corona for Blender / New standalone build
« on: 2017-01-17, 14:55:13 »
we automated the build process for standalone, so I made the first build that involves both legacy/fullspeed version, and release/assert versions. It is posted in the dropbox daily builds folder:

Tutorials & Guides / Corona Smart Tips
« on: 2016-12-12, 14:13:40 »
Some random smart tips that are probably not obvious at first sight. Feel free to contribute ;)
  • You can change language of tooltips in Render Settings -> System -> System Settings. We provide English, French, German, Italian, Russian, Spanish, and Ukrainian translations.
  • You can set up autosave of all renders every 10 or so minutes, and on render end, in Render Settings -> System -> System Settings. You can use the autosaved EXRs directly, or resume the render from them. This prevents data losses during long rendering on crashes and power outages. Autosave settings is shared for all scenes - i.e. you need to set it up only once.
  • You can use same variable in autosave filename as in render settings - for example "%d %f %n %v" will output datel, filename, frame time, and camera name
  • you can use CoronaColor in "Solid HDR color" mode with negative values to produce more saturated colors than RGB color picker would allow. The change is noticeable when using moderately to strongly colored light sources.
  • CoronaColor is faster to render than other methods of producing solid color from maps, such as empty Output or ColorCorrect maps, or RGB tint/multiply
  • You can save current scene settings as defaults from Development/experimental rollout with "Save defaults..." button.
  • You can doubleclick the image in Corona VFB to fit the VFB to current render size
  • You can add render regions in Corona VFB by just holding down shift + dragging in the viewport
  • When using Corona Color Picker, you can insert web colors (e.g. #00FF11) directly, allowing you to copy&paste from photoshop in single step. You can also pick any color from the screen (not just from 3ds Max) with the "Pick" option

There is a lot of confusion about the sRGB checkbox in color picker lately and why the same numbers can represent different colors. I will try to explain it.

General intro

Q1: Why is 127 gray sometimes darker and sometimes brighter? Why is 0 240 0 green sometimes greener?
A: Because there are different color spaces, terms such as "red 240 120 50" can mean different actual colors in different color spaces - Adobe RGB, Wide RGB, XYZ, CIERGB, sRGB, ... The reason why we can usually get around by just using numbers without specifying color space is that the sRGB color space is widely adopted and was set as the default for web graphics, leading to wide adoption.

Q2: Why not just always use sRGB then?
A: Because sRGB is "narrow" and can express only a relatively small subset of all colors without using negative values. It is also non-linear - there is gamma curve involved - you cannot add two sRGB colors in rendering (i.e. from 2 lights in the scene) and expect correct result. You need a linear space for that - this is what the linear workflow is about.

Q3: Why even complicate things with gamma?
A: Because human vision is highly non-linear - roughly logarithmic. By applying a gamma, sRGB is roughly perceptually uniform - adding 1 to a dark or bright color results in roughly the same increase in brightness. Linear gradient from 0 to 255 in sRGB looks roughly uniform. In '90s nobody was doing rendering (which needs linear color space as opposed to 2D graphics), converting between color spaces would be too expensive, and memory was scarce, so the 8bit gamma-baked sRGB modelled to match '90s CRT monitors was created to give good visual resuls for 2D graphics. 8bit non-gamma format would produce bad results because all of its 255steps precision would be wasted in blacks, with no precision left for whites. Also appylying the gamma before sending the image to monitors would be too expensive.

Q4: Why is this a problem in 3ds Max?
A: Because 3ds Max is not color managed, and does not have the concept of color spaces. It internally uses just "RGB" with no information about which space it is - which is problem because that number can represent different colors, and renderers cannot just use sRGB, as explained previously. The biggest problem is that certain map slots need linear data (such as diffuse color) to work properly (linear workflow), while other slots need sRGB data (normal, bump, and displacement) to preserve what user intended in photoshop when he created the map and saved it as sRGB. 3ds Max has no way to specify which space is the input texmap in, or what space it returns results in, which puts the burden of checking this on user. We try to make it easier for users by showing warnings in normal maps, but that is not an ideal solution.

Q5: Why do different textures need to be in different color spaces?
A: I will give an example: diffuse color vs. normal/displace map:
- Diffuse color is just a captured surface reflectance (assuming no reflections). The renderer internally has to multiply the diffuse color with incident radiance to produce bounced radiance when calculating GI/direct light. This multiplication will not work if done in sRGB color space, because it is not linear. When you created a photo of the wood/gravel/leaf, your camera added the gamma curve to the image when it was saved as .jpg - because that is what the standard requires. Renderer needs to remove the same gamma curve to get the true linear values.
- Normal map cannot be photographed in reality. It is drawn in photoshop, and the standard here (created in realtime graphics before linear workflow era) is that 127 127 255 saved in jpeg is "no change to normal". If we would remove the same gamma curve as from diffuse texture, then "no change to normal" color would become "huge change in normal", which would screw up look of the model because all normals would be way off. This is really easy to reproduce and I bet it happened to everyone at least once ;)
- When you draw a displacement map in photoshop and use linear gradient from black to white, you expect this to translate to linear slope on the surface. You save this gradient into JPG as linear progression from 0 to 255. If renderer would remove gamma from this and interpret the numbers as height then, the slope would no longer be linear, but gamma-curve shaped.
We would happily do these decisions for you on background, but that is not possible in 3ds Max - textures work as black boxes there, so we cannot determine how should each texture behave, when for example the same texture is instanced in different slots, reused in shader tree, ... Plus there is the issue of legacy workflows - people expect to load normal maps with gamma override - by not requiring gamma override we would break workflows people have because then overriding normal maps to 1.0 gamma would actually produce incorrect result.

Color pickers

Q6: Why is this an issue in color pickers?
A: Because there are exactly the same problems when picking color as when inputting a texture - you can think about color pickers as small 1*1 px textures ;) - you need to specify their color space the same way as for textures.

Q7: How does 3ds Max color picker work?
A: When gamma is set up properly in 3ds max, the color picker will show linear (no-gamma) sRGB numbers, show gradient which is linear in linear space, BUT show sRGB (color-mapped) colors on the monitor.

Q8: What is the problem with this?
A: We identified these problems:
- The color gradient on sliders progresses uniformly in the linear space, so it progresses non-linearly in sRGB, so it is perceptually non-uniform. You can see this - all blacks are cramped at the very top, half of the slider looks completely white.
- You cannot do direct input from photoshop/webpage/... Photoshop uses sRGB values. When you put them in the 3dsmax inputs, they get interpreted as linear values, resulting in brighter color. This leads to absurd situations where you would open a texture in photoshop, pick one if its pixels, write that color in 3dsmax, and get completely different results. Or putting 127 in color picker gives different result from putting 127 gray jpeg texture in the texture slot.
- Same goes the other way - if you pick color for material under white lighting, say 255 127 0, render, and copy the image to photoshop, the material will have much different green color value.

Q9: How does Corona color picker work?
A: With sRGB checkbox off, it works exactly like 3ds Max picker, with one exception: we made the sliders perceptually uniform - roughly half of the scale is dark colors, and half is light colors. When you enable the sRGB checkbox, then nothing changes (displayed color, sliders, ...) except for the numerical values - those are now in sRGB. This means that with sRGB checked, you can copy colors directly from photoshop/web/... with no brightness change.

Q10: Should the sRGB checkbox be on or off then?
A: There is no "correct" solution. Picking the colors visually works exactly the same in both cases. Only thing that changes are the numerical values. What is better depends on situation. Use sRGB=off for consistency with 3dsmax, sRGB=on when you need to match photoshop or web values.

Q11: This is confusing, but I want to use the new color picker because of temperature!
A: No problem, just leave sRGB=off to have the same behavior as 3ds Max color picker

"I cannot be bothered with technical details" version
When using Corona Color Picker, leave sRGB off. It will behave exactly the same as 3ds max color picker. When you copy RGB values between photoshop and 3ds Max and notice the result is not matching, turn sRGB on first, then copy the values. You can mentally rename the checkbox to "match numbers to photoshop instead of 3dsmax"

We are thinking about removing/hiding this parameter as the denoising continues to work reliably without changing it in our tests. Is there anyone who changes its value?

Pages: [1] 2 3 ... 14