1
Gallery / Re: Laurel.
« on: 2025-01-03, 20:46:37 »
Really great shading and... everything, and it really conveys the 'feel' of the place.
2025-01-14, 17:50:35
News:
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.
2
Learner’s Corner / Re: The lights look unreal
« on: 2025-01-03, 14:31:23 »
I'd make sure natural vs artificial lighting has the right temperature, they both seem to be neutral right now (or too similar), in reality they're really different.
3
[Max] General Discussion / Re: Corona auto-renewing and billed without notification
« on: 2025-01-03, 10:56:27 »
If there was no information prior to downloading/installing the demo about 'automatic' purchase of the product without further notice after the demo runs out, they have no valid contract with you and it's illegal. Chaos is now registered in Germany afaik, they'd even have to accept your withdrawal from the sub within 2 weeks without any explanation from your side. What are they smoking?
4
General CG Discussion / Re: Viewing/editing HDRI files
« on: 2024-12-18, 19:04:54 »
Good question, I'd love to hear some opinions, too. I have a lot of panoramas that need tripod/shadow removal and would love to know which apps that offers spherical display + retouching (or some losless on-the-fly conversion between cube/equirectangular) and retains all HDR data. It's a bit tedious to go forth and back between different apps for this.
Photoshop cripples 32f HDRs and will only open/save 16f (and actually uses 15 bits internally if I'm not mistaken...). 16 bits are good enough for most cases, but there's definitely a difference in sun intensity with 32 vs 16 bits in some of my panos. Looking forward to hear what others use.
Photoshop cripples 32f HDRs and will only open/save 16f (and actually uses 15 bits internally if I'm not mistaken...). 16 bits are good enough for most cases, but there's definitely a difference in sun intensity with 32 vs 16 bits in some of my panos. Looking forward to hear what others use.
5
[Max] Bug Reporting / Re: Tonemapping Order/Behaviour
« on: 2024-12-17, 14:24:06 »
Oh sorry missed the answer, thanks Juraj for bumping this one.
I've sent an example to Maru a (good) while ago, the discussion around the saturation operator has been around for some time now. In that specific case, a saturation value of 0.02 introduced a pinkish hue to an slightly warm white in clouds on a HDR texture. This was absolutely counter-intuitive and only one of the examples provided. We've been here before, and from the question to provide examples I can only assume whatever I sent and was discussed is lost...?
For what and how - may I simply suggest to try out, compare to other packages and make it behave reasonably. If it's not clear to support or developers within 10 seconds, no example I could send will make a difference.
Oh and the ideas portal - various users have requested a thousand things in the past and we were assured these are on the backlog, it's somewhat strange to ask us to a) re-submit as if we never did and b) expect that everything worthy of an update is going to get enough upvotes. Not everyone will understand the importance of certain requests but everyone will be happy when it's in. For some improvements/features I would expect the team to realize the importance themselves.
I've sent an example to Maru a (good) while ago, the discussion around the saturation operator has been around for some time now. In that specific case, a saturation value of 0.02 introduced a pinkish hue to an slightly warm white in clouds on a HDR texture. This was absolutely counter-intuitive and only one of the examples provided. We've been here before, and from the question to provide examples I can only assume whatever I sent and was discussed is lost...?
For what and how - may I simply suggest to try out, compare to other packages and make it behave reasonably. If it's not clear to support or developers within 10 seconds, no example I could send will make a difference.
Oh and the ideas portal - various users have requested a thousand things in the past and we were assured these are on the backlog, it's somewhat strange to ask us to a) re-submit as if we never did and b) expect that everything worthy of an update is going to get enough upvotes. Not everyone will understand the importance of certain requests but everyone will be happy when it's in. For some improvements/features I would expect the team to realize the importance themselves.
6
[Max] General Discussion / Re: Corona 12 Update 1
« on: 2024-12-13, 11:42:57 »
Guessing based on the process name, when you google it, you'll find it's a Qt-related library ('A QWidget-based Web View Component Integrated with CEF').
Maybe related to the new VFB, or other parts of Corona which uses it for Qt-based UI components.
Maybe related to the new VFB, or other parts of Corona which uses it for Qt-based UI components.
7
[Max] General Discussion / Re: Corona 12 Update 1
« on: 2024-12-12, 17:00:42 »
I'm stuck in the past on both Max and Corona but judging from the posts here I think you should be adding info on which Max versions you are using, too. It looks like Max is not getting the QA that it needs/deserves and there could be issues with Max' internal notification system (there were some in the past) that could interfere with how a renderer accesses the API. For example, a seemingly simple thing like hardware hit testing in the viewports for example could slow down IR quite a lot.
8
General CG Discussion / Re: Render Network
« on: 2024-12-12, 14:58:42 »
Isn't this be a legal nightmare in terms IP and safe harbour regulations word wide? You probably have to sign a couple of waivers since no one can guarantee that the data is safe.
I know I wouldn't use it on any job and probably would be hesitant with my private data, too.
I know I wouldn't use it on any job and probably would be hesitant with my private data, too.
9
[Max] Bug Reporting / Re: Tonemapping Order/Behaviour
« on: 2024-12-11, 14:54:00 »Quote
there is no correct/wrong behavior...vignette operator...
Funny you mention vignette in the same paragraph. Vignette *should* be applied before any TM, otherwise it would be more visible over HDR values than it should. A pixel with a luminance value of 4 (sorry for the wrong wording, doing it for the sake of clarity) would result for example in a value of 3.5 - still overbright, hence white in the tone mapped image.
On a tone mapped image it would work on a value of 1 and the result could be 0.75 - this wouldn't be correct.
Some operators do work differently and while we can be artistic with them, I agree, it would be nice to know which ones are designed to be HDR-aware by you. It could be that development didn't care for operators to work in HDR, in that case this is the answer - not 'the order is up to you'.
And since we're talking about operators - Corona has the worst saturation adjustment operator on this planet (maybe only matched by max built in CC node which is similarly unpredictable). Are there any plans to redesign it and provide something that will finally work for human vision?
10
General CG Discussion / Re: Poll - Do you profile your displays?
« on: 2024-12-06, 18:43:18 »
Ah I see. I haven't looked too much at OCIO but it's crazy to me they go with one config and chose not to extend it with each update. Interesting to see May and VRED got a different treatment.
Both look transform and virtual display would be something I'd definitely like to see.
Some years ago I was in contact with the creator of VFB+, Rotem Shiffman, asking if he could update it to allow a color transform from a user-specified ICC profile. Well, it took him 2 days and it was in, worked and was perfect. Something Autodesk (and Corona, btw) haven't managed to add for way too long. Of course, this wouldn't care about input and rendering spaces etc. but the final step is already a huge help.
This is maybe another reason why people are not profiling or even just learn about the advantages - their expensive super-capable 3d app is worse at displaying colors than any image viewer or web browser which you can get for free. Isn't that just great.
Both look transform and virtual display would be something I'd definitely like to see.
Some years ago I was in contact with the creator of VFB+, Rotem Shiffman, asking if he could update it to allow a color transform from a user-specified ICC profile. Well, it took him 2 days and it was in, worked and was perfect. Something Autodesk (and Corona, btw) haven't managed to add for way too long. Of course, this wouldn't care about input and rendering spaces etc. but the final step is already a huge help.
This is maybe another reason why people are not profiling or even just learn about the advantages - their expensive super-capable 3d app is worse at displaying colors than any image viewer or web browser which you can get for free. Isn't that just great.
11
General CG Discussion / Re: Poll - Do you profile your displays?
« on: 2024-12-06, 17:45:00 »OCIO sytem has support for ICC profiles. it’s just Max that does poor job supporting OCIO.Since you're an expert on this, what's your take - why is OCIO support in Max poor? I have no idea (still on max 2021 here), asking out of interest and would like to hear your opinion.
one way of going around it is adding the same functionality but with luts in custom ocio config.
12
General CG Discussion / Re: Poll - Do you profile your displays?
« on: 2024-12-06, 17:09:23 »
Yeah, I wish OCIO in Max was accompanied by something (ICC) with the print guys in mind, too.
As for ICC profiling, there are two ways:
1. Additional hardware - colorimeter, plugged in via USB - comes with software that'll guide you through the process and profile your monitor by displaying different colors on your display while measuring the results and calculating the profile from that. You can set it to different targets (luminance, gamuts etc).
The result is an ICC file. It'll then set your OS to use that ICC profile (or guide you through the process). You can use it on any display and you can use separate profiles for each display, too. Your display should however meet some standards in terms of the gamut, otherwise you may not get correct color reproduction. If your display only makes 80% of let's say the AdobeRGB gamut, your display will not be able to display all colors of AdobeRGB of course.
If you've done it once it's easy to repeat, which you should do every few weeks. Some places need high accuracy and will need do this on a weekly basis since displays tend to age.
2. A display with a built-in colorimeter (for example certain Eizo displays, I have one and it's fantastic). You profile it once to a target gamut. You can then set a timer to validate the profile automatically periodically, for example every friday at 3am.
The resulting profile is then - at least in the case of the display I own - stored in the display itself and the Eizo software will sync your OS to use it, too. The advantage is that the device is now calibrated independently - ie, you can plug any other PC to that monitor, it'll still look correct (you'd still have to take care of the OS to use that profile).
This is a very convenient and care-free solution and it's well worth the extra money. I'm talking about Eizo here but it may apply to other vendors.
In any case, I've been working for print a lot and it really helps to know that what you see is what you get. I agree you may not need that accuracy in display-only-times apps but whenever I talk to clients about colors, it really helps to know I'm on the right side of things and can quickly end any discussion once they realize their display/phone whatever is just not a proper device to judge colors.
I remember well working at a studio once and 3 of us were comping different shot where the same asset was in full display, each of us on a separate PC/display next to each other. It was a shiny red car with a very distinct color and each displayed the color differently. Everyone was tempted to correct it but no one was able to tell which display was closer to the truth since nothing was ever calibrated in that place. This problem is not present when you calibrate displays and is the no1 reason I always went with calibration since then.
As for ICC profiling, there are two ways:
1. Additional hardware - colorimeter, plugged in via USB - comes with software that'll guide you through the process and profile your monitor by displaying different colors on your display while measuring the results and calculating the profile from that. You can set it to different targets (luminance, gamuts etc).
The result is an ICC file. It'll then set your OS to use that ICC profile (or guide you through the process). You can use it on any display and you can use separate profiles for each display, too. Your display should however meet some standards in terms of the gamut, otherwise you may not get correct color reproduction. If your display only makes 80% of let's say the AdobeRGB gamut, your display will not be able to display all colors of AdobeRGB of course.
If you've done it once it's easy to repeat, which you should do every few weeks. Some places need high accuracy and will need do this on a weekly basis since displays tend to age.
2. A display with a built-in colorimeter (for example certain Eizo displays, I have one and it's fantastic). You profile it once to a target gamut. You can then set a timer to validate the profile automatically periodically, for example every friday at 3am.
The resulting profile is then - at least in the case of the display I own - stored in the display itself and the Eizo software will sync your OS to use it, too. The advantage is that the device is now calibrated independently - ie, you can plug any other PC to that monitor, it'll still look correct (you'd still have to take care of the OS to use that profile).
This is a very convenient and care-free solution and it's well worth the extra money. I'm talking about Eizo here but it may apply to other vendors.
In any case, I've been working for print a lot and it really helps to know that what you see is what you get. I agree you may not need that accuracy in display-only-times apps but whenever I talk to clients about colors, it really helps to know I'm on the right side of things and can quickly end any discussion once they realize their display/phone whatever is just not a proper device to judge colors.
I remember well working at a studio once and 3 of us were comping different shot where the same asset was in full display, each of us on a separate PC/display next to each other. It was a shiny red car with a very distinct color and each displayed the color differently. Everyone was tempted to correct it but no one was able to tell which display was closer to the truth since nothing was ever calibrated in that place. This problem is not present when you calibrate displays and is the no1 reason I always went with calibration since then.
13
[Max] General Discussion / Re: Did you or your studio upgraded to Corona 12.1 ?
« on: 2024-12-05, 17:26:13 »
I recall seeing in some other thread that Max would crash (when going back) whenever a camera was present in the scene. I'm not sure the info will help but who knows...
14
[Max] Bug Reporting / Re: Corona colour correct issue
« on: 2024-12-02, 16:27:17 »
I'd love the Color Correct node to have min/max clamp values. Maybe it can be added when fixing this?
15
General CG Discussion / Re: Poll - Do you profile your displays?
« on: 2024-12-02, 14:53:16 »I wonder if it depends on the target? If ever you are doing something in print, then those folks profile. If the work will just be on displays, then those folks don't because every display will be differently set up so even with profiling you have no idea what the end customer will see (that is, not our users client, but their clients... e.g. render an image for a client who will put it on their website selling that apartment space / advertising the upcoming restaurant opening / etc. and the viewers of the website could end up seeing any old thing in terms of profile).Nah, there's way more reason to properly profile your monitor. Proper black and white level alone can spare you some trouble.
In one or all of the Star Wars ep 1/2/3 (the new ones, not sure which ones anymore) you can see some hilarious black level misalignment where you can clearly see the cut out stance around space ships in some places. It's the most basic comp error there is, and it's all coming from people not caring about the display they use. Everyone assumes it's good enough if it has proper contrast. Now the fact that it slipped through ALL the stages after comp is telling, and to think no one caught it is just amazing. Wouldn't have happened with proper profiling, or even the most basic.
Ferrari and Coca-Cola will torture you for weeks to get their red color right. Sure, this is not the common job. But even in archviz, if you deliver your images and the sky is just a a bit too green or has too much magenta, the entire image is ruined imo.