Messages

1

[Max] Daily Builds / Re: Camera Inside Volumes Playground!

« on: Today at 14:31:27 »

Glad to see this align-with-camera is now working. But one issue remains that we ideally need the "camera" to be a rectangular cuboid i.e. ability to separately control it's 3 x dimensions. Because right now if you want to do this half-in-water effect you're forced to determine it with a cube, so if you want a close cut (say 10cm away from camera) it means you can still see the far faces of the cube in the render causing artifacts. We need to be able to make the width and height separate from the depth basically. As of right now I'm still having to overcome this by using a custom invisible box that I use as a coronaslicematerial to cut out of the water. Sorry no preview to share as it's under NDA.

Given the vast customization of the slicing volume with slicer material (custom shape, linking to camera, animating if needed), I don't think it is worth adding the same functionality (which will clutter the UI for a simple thing) into camera. Camera physical volume is intended for the general-use-case quick medium cuts aligned with the camera. I believe it does the same thing as slicer material under the hood, so good thinking on the workaround :)

I understand where you're coming from, but in my experience this tool as it stands isn't usable unless your FOV is so narrow that you don't see the "cage". Not sure what the point of the tool is if the only way to use it properly is to actually not use it at all and do it all manually using a slicer. Wouldn't it make more sense to fix the current implementation so it can achieve the desired result? As you say, that tool has basically one single purpose/use-case, so it makes sense to me to make it work for that use case without such an obvious limitation. I'm sure this could be achieved without bloating the UI. After all there is already a section there for it in the camera.

2

[Max] Daily Builds / Re: Are you still using the old VFB?

« on: 2025-07-01, 16:08:25 »

Only been using C12 for a week or two, so been trying to force myself to use the new VFB2, but I find unfortunately everything about it a step backwards so will most likely switch back to the old one. Everyone's given the reasons here already for me mainly its:

1) zooming seems to show "noise" for a second before it disappears (some kind of zoom antialiasing issue).
2) UI layout with the text on the right is a bit messy, unaligned and oversized. Needs alignments and line separators.
3) the icons in place of text buttons is just confusing. Can't seem to commit them to my brain and always have to read the tooltip.
4) flipping between elements seems to take longer than before (might be false, will test more).
5) the same dev time could (maybe should?) have been spent getting the material editor/corona materials/maps into QT where we spend like 80% of our time (and active work time, not just passive time like with the VFB).

In general I'm all for a new VFB UI as I'm aware it allows for other important new things to work like Colab etc, but as long as it's with the above things improved.

3

[Max] Daily Builds / Re: Chaos Corona 13 for 3ds Max - Daily Builds Discussion

« on: 2025-06-26, 12:53:49 »

Somehow it just missed us, this knowledge! Been using the default Corona HQ denoising + HQ filtering since... forever. One naturally assumes that anything native/Corona and "high quality" and which is also the default must be the best, for day-to-day use, and of course we've never had any issues with it, therefore no incentive/reason to try anything else. It's just this recent vid that caught our attention recently which caused us to change. But yes, the difference really is night-and-day. I wonder if the corona method simply needs to be improved if it's to remain the default... or just make Intel+Tent the default if better?

4

[Max] Daily Builds / Re: Camera Inside Volumes Playground!

« on: 2025-06-26, 11:30:47 »

Glad to see this align-with-camera is now working. But one issue remains that we ideally need the "camera" to be a rectangular cuboid i.e. ability to separately control it's 3 x dimensions. Because right now if you want to do this half-in-water effect you're forced to determine it with a cube, so if you want a close cut (say 10cm away from camera) it means you can still see the far faces of the cube in the render causing artifacts. We need to be able to make the width and height separate from the depth basically. As of right now I'm still having to overcome this by using a custom invisible box that I use as a coronaslicematerial to cut out of the water. Sorry no preview to share as it's under NDA.

5

[Max] Daily Builds / Re: Chaos Corona 13 for 3ds Max - Daily Builds Discussion

« on: 2025-06-26, 10:59:57 »

Not to derail the topic about the AI thing, but that video about the intel denoiser used with tent really changed the game. We're finding significant detail boost at lower passes using this method, and that's without actually rendering at 2x scale and downscaling back down. It's meaning we can render animations natively at 4k in the same general time as we'd have rendered 1080p animations, because the image detail and denoising results with the Intel denoiser (with Tent) are so impressive. And of course the benefits are there too no matter what resolution you're working at, so we're also using this method now for general work e.g. 6k/10k renders. The whole 2x scaling thing is more faff than it's truly worth IMO. Also what's not discussed in that video AFAIK is RAM usage at higher resolutions - something to consider.

6

[Max] Daily Builds / Re: Chaos Corona 13 for 3ds Max - Daily Builds Discussion

« on: 2025-06-17, 14:12:06 »

Just a reminder that 2K is the max input resolution, which results in a 4K final image that you would deliver to your client. This will be reviewed as time goes on, but I did do a check on Behance, the Gallery here, etc. and most images were 4K or under so it seemed like a reasonable starting point :)

I think it would be best to get the opinions of industry people directly rather than interpreting what you see on social media (which is always lower res than the "originals", for obvious reasons of security etc.). The industry has been at 5k minimum and often higher than this for a very, very long time, for final still images. We've been at 6k for about 5 years, probably more, and many of our clients require 10k, 12k or more sometimes.

There's no way we can reduce the native res of images to as low as 4k or 2k these days just to take advantage of AI enhancements. We'd just be forced to use any of the multitude of alternatives out there (which we're doing already). What if your current implementation could work at the user's high res, internally down-scale, do it's AI "thing", then push it back up to the native high res again? I.e. reduce to 2k then back up to 5k/6k. ? It's still far from ideal but at least it would enable users to work with this.

Confident you guys can figure this one out :)

7

[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?

8

[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.

9

[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,

10

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.

11

[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,

12

[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!

13

[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.

14

[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.

15

[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...