1
[Max] I need help! / Re: Geometry Motion Blur
« on: 2025-05-12, 15:55:45 »
Super duper old thread but this came up today. Any plans for changing geometry topologies to be supported with geom MB?
2025-06-17, 09:46:39
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
[Max] Daily Builds / Re: Camera Inside Volumes Playground!
« on: 2025-05-02, 16:31:58 »
Great news! Thanks for confirming. Looking forward to updating to C12.2. Just waiting for all the usual suspects to update to support it first and we can then test this.
3
[Max] Daily Builds / Re: Camera Inside Volumes Playground!
« on: 2025-05-02, 14:33:07 »
Not sure if this is the best thread for this, but I'm discovering that the "camera physical size" parameter of a coronacamera is always oriented the same way regardless of rotation of camera (with or without target), meaning that if you have your camera for example pointing at 45 degrees instead of directly up, down, left or right, it will clip the apex of the "box" that it lives within.
This is with 11HF2. Is this fixed in 12.x? Or is there a workaround so that it properly follows the orientation of the camera?
Many thanks,
This is with 11HF2. Is this fixed in 12.x? Or is there a workaround so that it properly follows the orientation of the camera?
Many thanks,
4
About this Forum / Re: Is the forum slower this days?
« on: 2025-04-22, 12:57:59 »
Any news Tom? Forum's painful to browse lately.
5
[Max] Corona Goodies - User Contributions / Re: AgX in Corona
« on: 2025-04-01, 13:49:10 »
Ok awesome... ! Thank you. A lot to digest and figure out here so I might fire you some DMs when I get time to implement and test.
Cheers,
Cheers,
6
[Max] Corona Goodies - User Contributions / Re: AgX in Corona
« on: 2025-04-01, 11:19:13 »
Hi Marcin, folks/devs,
We are typically using your fantastic AGX ToneMapping instead of ACES for almost everything these days, from this method, as it seems to have a much more pleasant and predicable rolloff for the highlights while preserving contrast and colour. The issue we're facing is that it doesn't seem to work properly with ToneMapControl when you set it to not affect the map. It seems to affect the exposure and crush certain tones and mess around with the contrast. I see there's a warning for this on the corona website "While the Corona Tonemap Control Map works fine most of the time, there are some special cases where it may fail, for example: using some LUTs, using extreme tone mapping operator values, setting the Contrast value to zero."
- Is there any workaround for this to get 1:1 result with the underlying map, like we get with ACES workflow?
- Is there a simplified single-LUT version of this we can use, which may or may not help?
Some notes:
- corona 11 HF 2, max 2024
- base map is an SRGB photo loaded into coronabitmaploader, zero colourcorrection, just the pure map
- it's then piped into tonemapcontrol with all the checkboxes disabled
- using AGX workflow method from here: https://forum.corona-renderer.com/index.php?topic=40952.0 - it results in 2 x LUTS being loaded into the coronacamera tonemapoverride. It's the second (lower) of the two LUTs that's breaking things (or rather being broken by the tonemapcontrol). And I believe we have the correct Logarithmic settings
- contrast is at 1.0, or 1.5 it doesn't matter (but it's not at 0.0 FYI, which we know can break things)
- we're aware of the IR tone mapping bug where you need to re-start the IR each time you affect things like exposure, tone mapping, LUTS etc. which we've done, so this isn't the issue (although devs, any news on a fix for this? it's very annoying and easy to forget!). It happens also in production rendering.
Example below:
Thanks for any help!
We are typically using your fantastic AGX ToneMapping instead of ACES for almost everything these days, from this method, as it seems to have a much more pleasant and predicable rolloff for the highlights while preserving contrast and colour. The issue we're facing is that it doesn't seem to work properly with ToneMapControl when you set it to not affect the map. It seems to affect the exposure and crush certain tones and mess around with the contrast. I see there's a warning for this on the corona website "While the Corona Tonemap Control Map works fine most of the time, there are some special cases where it may fail, for example: using some LUTs, using extreme tone mapping operator values, setting the Contrast value to zero."
- Is there any workaround for this to get 1:1 result with the underlying map, like we get with ACES workflow?
- Is there a simplified single-LUT version of this we can use, which may or may not help?
Some notes:
- corona 11 HF 2, max 2024
- base map is an SRGB photo loaded into coronabitmaploader, zero colourcorrection, just the pure map
- it's then piped into tonemapcontrol with all the checkboxes disabled
- using AGX workflow method from here: https://forum.corona-renderer.com/index.php?topic=40952.0 - it results in 2 x LUTS being loaded into the coronacamera tonemapoverride. It's the second (lower) of the two LUTs that's breaking things (or rather being broken by the tonemapcontrol). And I believe we have the correct Logarithmic settings
- contrast is at 1.0, or 1.5 it doesn't matter (but it's not at 0.0 FYI, which we know can break things)
- we're aware of the IR tone mapping bug where you need to re-start the IR each time you affect things like exposure, tone mapping, LUTS etc. which we've done, so this isn't the issue (although devs, any news on a fix for this? it's very annoying and easy to forget!). It happens also in production rendering.
Example below:
Thanks for any help!
7
[Max] General Discussion / Re: Max 2026
« on: 2025-03-27, 17:21:08 »
The new Colour Management stuff is both welcome and concerning in that I imagine it will require work for Corona devs to get things synchronized properly, I guess? Be good to hear from the devs on that. It feels like colour management is still a bit of a jungle of guesswork, trial and error and incompatibilities in that regard, but hopefully the new changes facilitate this being sorted out.
Other than that, it's pretty depressing seeing the dismal state of max's development these last few years.
Other than that, it's pretty depressing seeing the dismal state of max's development these last few years.
8
[Max] I need help! / Re: Chaos corona livense not found
« on: 2025-03-10, 17:59:03 »
Anyone else having the same licensing issues today with AnimaALL? Opened a ticket already but curious if coincidence or not. Anima's licensing is dreadful at the best of times but not being able to use it at all right now is a wonderful Morning surprise on top of Corona going down as well.
9
[Max] I need help! / Re: Chaos corona livense not found
« on: 2025-03-10, 13:59:01 »
Working here as well now, but a lot of time lost...
10
[Max] I need help! / Re: Long rendering time
« on: 2025-02-26, 17:08:15 »First, make sure the exterior windows have simple (thin) glass - this is a common user error that can significantly increase render times.
I don't think it's the best advice to say people should model things in such a fake way. Double glazing is also a thing, and makes a very visible difference when rendered correctly. Not to mention it's not practical advice depending on whether you might receive a certain level of detail in a model from a client, for example. There will be other more obvious ways to optimise the scene before doing something like that, it's just not necessary or desirable IMO.
11
[Max] Bug Reporting / Re: Corona 12H1 Scaling issue
« on: 2025-02-24, 16:59:13 »
1.0 as a default with a dropdown/button in IR for different scaling factors would be awesome. Ideally it would be in docked IR window too (along with previously-requested ability to look at other render elements in docked IR window too). Imagine an overlay toolbar which is invisible until you hover over the docked IR window, then it appears with a set of buttons, dropdowns etc. for all these things.
12
[Max] Daily Builds / Re: Chaos Corona 13 for 3ds Max - Daily Builds Discussion
« on: 2025-02-24, 16:20:35 »
Agree. Not sure why something that's clearly well outside of Corona's photorealism modus operandi is taking priority over something (interface slowness) that affects quite literally every single Corona user in every single use session, no matter what you're doing with it. It's nice that Toon stuff is happening, but the priorities here are... strange. It currently sounds like it's not even a priority in 14 either but more of a starting point there for release more likely in 15? And toon stuff won't be any kind of innovation either, when it's in. It'll be catching up with other NPR engines from many years ago, so I don't really put it into an "innovative new tools" mindset. Doesn't make sense to me, sorry!
13
Hardware / Re: old threadrippers and win11 upgrade?
« on: 2025-02-17, 16:32:27 »
We have a bunch of 3990x and they're all compatible out of the box with win11 if we wanted, but you might just need to enable the bios' TPM and/or update the motherboard BIOS version for this to be visible.
14
[Max] I need help! / Re: 4k Cache - What's the latest? (2023/4 Update)
« on: 2025-01-24, 16:41:24 »
Not sure where development is on this, but came across a situation this week where bright light coming in through thin curtains was causing very strong blotches of light, around 30cm in radius, using 4KCache. Switching to UHDCache fixed it immediately. Whacking up the quality/lowering granularity for the 4KCache helped but never removed the issue.
15
[Max] I need help! / Re: Modeling liquid volume for caustics
« on: 2024-12-05, 15:55:42 »When modeling the volume of a liquid for caustics, is it still necessary to make the volume's geometry go beyond its container walls?
For the surface of the liquid, will the solver recognize either a bump map or displacement map for the surface irregularities?
First question: we always do this, and it looks correct, so yes, overshoot. But it's not necessarily essential.
Second question: either will work - displacement is of course more realistic, and will look correct at the edges where the water meets other surfaces, but bump is a good quick way of getting more or less the same result without worrying about the displ map screwing things up on the edges e.g. wave height becoming a challenge. Just not as realistic to look at. Depends on use case really.
The above are assuming you're using phoenixoceantex (which is great), but you don't have to.
You have a highly appropriate username for these questions!