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.

Messages - Ondra

Pages: [1] 2 3 ... 591
Also, under what circumstances would you use the metalness/non-metal workflow? For example; semi-polished concrete, dark antique/tarnished bronze, polished marble, silk rugs, car paint e.t.c. I'm a bit confused as to where the cut off point is where materials have a reflective but also strong diffuse component. Or am I misunderstanding metalness?

metalness should be really used only for materials made of metal - so concrete, marble, silk are non-metal. Darkened bronze would be probably done with metalness map (metal bronze vs. non-metal "dirt"). Car paint is very complex and specific material, neither metal nor non-metal will represent it 100% physically, so I guess it would be possible to fake it with both

So if we have to specify metalness (metal or non-metal) at the top of the material, which do you choose if both metal and non-metal surfaces are represented in a single texture set?

In that case you will set a metalness map, and the dropdown will become greyed out, signalling that it is no longer used. Both options for metal and non-metal material become unlocked.

while there are no immediate plans, we are watching the development closely. There are not only raw performance improvements, but also development of the whole ecosystem, which is important for developers, as it determines how much work is needed to unlock the performance, and what features will be supported. If/when gpu rendering technology reaches the marketing promises ("make all your features 100x faster over a weekend"), we will definitely spend the weekend :D. Currently we have 3 GPU renderers in Chaosgroup, so we have good source of verified info.

I would personally advice you to NOT buy super-expensive GPU unless you want to do GPU rendering RIGHT NOW. If you do and have the cash, then sure, go ahead and buy the card. But we had so many instances of people buying strong GPUs "for the future" that never materialized. I personally bought GPU over my intended budget back in 9x00 times (yes, 9000, not 900), because usable GPU computing was "just around the corner". Hardware is depreciating asset and it does not make any economic sense to buy it "for the future". I wouldnt make any sense to buy a brand new car to sit in the garage for 2 years, "before things pick up". And hardware becomes obsolete much faster than cars. If you buy it now for future, it might be already obsolete when you finally make the switch.

Let's lock this topic and continue in bug reporting section...

[Max] Feature Requests / Re: The most wanted feature?
« on: 2020-08-31, 08:49:21 »
Added decals into the poll

[Max] Feature Requests / Re: The most wanted feature?
« on: 2020-08-27, 12:41:54 »
We are monitoring the posts and adding suitable suggestions into the poll manually. I just added the dedicated fabrics shader. Although we will definitely wait until PBR material is done, to see if that is still needed, or if fabrics is easy enough just with PBR

[Max] Feature Requests / Re: The most wanted feature?
« on: 2020-08-26, 16:22:43 »
Might be a stupid question, but is there any possibility of having an "Interactive Lightmix" but for Textures? Like how we can change the intensity and temperature of lights without the  needing to be rendered. I think it would be great to change textures on the fly like ILM.
Added into the poll. Also all vote counts were reset to 0 as usual for each release. We noted the results of previous period voting, and are planning to address the TOP 2 items (PBR material and tone mapping) in the next release.

[Max] Feature Requests / Re: The most wanted feature?
« on: 2020-08-26, 16:03:36 »
Removing implemented feature: Refraction/Reflection working with masking render elements (CMasking_Mask,CTexmap, etc...)

[Max] Daily Builds / Re: Dissolve with previous image
« on: 2020-08-14, 10:40:08 »
Oh, I get it. Much better with subsampling, IMHO. Don't even know why would someone turn off subsampling but i guess that's the only way to keep both users satisfied. Thank you again Rowan! ;-)

Thank you!!!
I just installed RC2 and I'm loving this behaviour.

Seems like the checkbox is here to stay ;)

you can also achieve the same effect with highlight clamping in system->VFB render settings

Corona tries to keep the sampling pattern the same across multiple renders and we jumped through a LOT of hoops to do this, on purpose. It improves noise situation in animations, and helps reproducibility (when there is some random bug after many passes).  Yes, it also means you cannot average images yourself after render. But don't worry - during single rendering, when resuming rendering, and when doing DR, the sampling pattern is automatically unlocked.

When averaging images, the out of focus highlights are not really cleared, they are removed from the image because of the image clamping. If you average images without postprocessing applied, you should get +- the same result as when you just let it render in single image.

Also note that thanks to the blue noise sampling and DMC, Corona actually picks better noise patterns across passes than you could achieve with purely random sampling - either in real world photography, or re-rendering the image multiple times with sampling pattern unlocked. You can switch between DMC and purely random per-pixel sampler in experimental settings to see how much improvement this is bringing.

Hi, are you using any sort of highlight compression? Because if yes, this is basically simulating the "subpixel mapping" that was used in VRay back in the days, but was abandoned because it decreases image quality (removed DOF and MB related highlights). The basic idea of the method used in astronomy is used in all realistic ray tracers since day 1 and is done in an optimal way, that you cannot improve upon by doing it manually.

Have I understood correctly that we're getting another seed behaviour change in multimap? It really should be made as stable as possible and never touched again since this way you can't rerender old projects without problems... this has happened 2 or 3 times in the past and it really caused headaches with old projects. Sorry if I misunderstood.

So yeah it has changed in v6. This was part of some wider optimisations. Hopefully we can keep these changes to a minimum in the future.



Ok.... Can't help but still love you guys :D

We found a way to keep the seed stable, so it wont change in v6 after all

General CG Discussion / Re: Gamma 2,2 today
« on: 2020-06-05, 09:27:53 »
Matching the monitor gamma was done back in Windows 95 times. Today we still use the same gamma, but for other reasons. GPU/monitor adjusts the colors to its specific output curve, but it still expects to receive the input data with gamma 2.2 when sRGB is used. You will get the same result displayed no matter what the physical properties of the display are, if you provide the input data in correct format (which for sRGB includes gamma 2.2). It is a data exchange format now.

we will consider implementing this as the next step, the first change was due to internal rewrite how sun vs. sky is handled

Pages: [1] 2 3 ... 591