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 - pokoy

Pages: [1] 2 3 ... 134
1
I will just say that anything regarding the file output is, unfortunately, handled by 3ds Max, we use its dialog for the output. We are limited to its capabilities. View transform may be quick to implement, but a whole new independent output dialog is not.

No problem - user knows what profile he's used, after all the user chose the ICC transform operator (if there ever will be one) and assigned it a profile. No hassle in assigning the same in PS manually. In that case, Windows wouldn't know what the profile was of course, still, that's the smaller harm. I'd rather have something that works in the pipeline than nothing because Windows doesn't know what to display and falls back to sRGB.

Let's hope that 3ds Max development handles this at some point, and there will be minimal work to sync on our side. If not (like when we implemented ACES OT for the sake of it, then Color Management with various view transforms got introduced :)), then the only way is having our own output dialog. We do have some, though indefinite, plans for this for future versions.

I think I can answer this for you - there will be absolutely no action from the 3dsmax team to support ICC natively. After all they sat on the topic for some 20 years despite numerous requests.
They implemented OCIO only because they acquired Arnold and the 'physical' exposure and tone mapping stuff they had from mental ray days was just the worst imaginable workflow you could come up with. And, sadly, when OCIO was implemented, there was almost no user feedback despite the importance of the subject.
When I asked specifically about ICC support, the answer from the mastermind was 'I've heard OCIO 2.0 supports ICC profiles, but honestly, I have no clue... By supporting OCIO anyone else can build their own stuff on top of it'. They don't care about ICC, simple as that. They cared about ACES though, and that was a forced move because they needed Arnold to work in common VFX pipelines and look the same, and the VFX world cares about ACES these days, nothing else. You won't see ICC touched by the 3ds max team for another 20 years.

2
@Maru - I hope this didn't come off as offensive, but here's a good reason not to suggest:

A) In case OS uses sRGB, just assign sRGB in PS (and optionally convert to whatever space users wants to work in)
B) In case user is using a calibrated display or uses a manufacturer display profile, assign that profile to your document in PS (and optionally convert to whatever space users wants to work in)

Reasons for not suggesting A
- I might use a calibrated device > suggesting sRGB results in wrong colors
- I might use a display that came with some installer which silently installs a generic display profile for the display (and user might not know it) > suggesting sRGB results in wrong colors
- I might switch my main display, old one was uncalibrated, new one comes with calibration profile... same wrong suggestion

Reason for not suggesting B
- When calibrating, the resulting display profile will change slightly every time a display is calibrated. The reason for this can be an aging display, user error, calibrating device picking up ambient lighting and making the calibration dependent on daytime or room lighting while calibrating, and profiling intent (for example having profiles with different target brightness to accommodate for different lighting conditions for postproduction people working in the studio or on site of production).
In case of an aging device, which will inevitably occur, my display profile is *different* from the one I've used a few months earlier. It means that assigning the profile 6 months back will not look the same when I re-render the job now and assign my current - now slightly different - profile. The display profile of a calibrated device will inevitably change over time if user cares enough to re-calibrate every given time span. If I don't re-calibrate I lose color fidelity, so one of my responsibilities in a color-aware working environment is to make sure I re-calibrate ragularly (or 'validate' the profile as it's called).
- Similar argument as above, I buy a new display. Both were calibrated but the new one is obviously technically better. Both calibration profiles will look vastly different when assigned to the same image. The profiles are all right, but they correct for a very different base scenario, and they will not be identical, resulting in different colors when following the advice.

And here's where Corona development can help. Please please please finally add a final color transform to the VFB that would allow the user to assign a profile just like PS/AE do it.
I've had the discussion with some devs in the past and the argument against it was that they would need to take care of input maps and color values... no, you absolutely don't!!
Sure you could do it, but only if you needed to convert color values from one space to another, which you don't!

Here's an example:
Important preface for those who aren't aware - color profiles don't change the pixel values, they add a color transform for the device output *only*.
Let's say I'm using AdobeRGB as my main profile for ALL my work. I have my textures and backgrounds prepared in PS using AdobeRGB.
I load them into Max, which ingores it, uses either sRGB or my display profile to display them, and yes, they look like shit.

BUT, the moment I render them, and have the VFB apply a display transform to AdobeRGB, they look exactly like what they looked like in PS. (Let's ignore the OCIO or ACES tonemapping operator for the sake of the argument I'm trying to make). If I save the file, and the profile I chose in the VFB will be embedded in the file, I will have the same colors I had in PS originally, and how the VFB displayed them wherever I'm looking at them (PS or Windows).
(Whether or not the profile is embedded is not important, but I'll know that what I see in the VFB will not be the either crippled sRGB crap or overly saturated wide gamut output of a pro-grade display but proper AdobeRGB I'm using in PS, too.)

Yes, they won't look like they do in PS in the viewports etc, because that's the 3dsmax part and they chose to ignore ICC entirely. Yes, OCIO might falsify this and tone mapping will do another round of 'damage' to my input, but that's not the point. By giving the user the option you would do *your* part.

This way, I gain the ability to see my intended colors in the VFB and frankly, that's what I care about the most.

The creator of VFB+, a nice VFB plugin from ancient times when renderers didn't come with their own VFBs and postprod options, integrated ICC display transform in a weekend. And he struggled most with CMYK conversion which you wouldn't have to care about at all. It really was a matter of a few days.

Or... you guys can just go on with the common bi-weekly post about 'my colors look different in PS', not caring about pro users who really need color fidelity in their pipeline and ask for it since years, and not educating people and giving them wrong advice instead. I could go on and on... it's just frustrating to see how this gets ignored.

I'm open for discussing this problem and how to overcome it in another place if needed, be it a new thread or discord. It's high time this gets solved as far as can be done on Corona's side.

3
And if you want to see this finally solved (or at least mitigated by ensuring color fidelity using a 30+ years old standard by the name of ICC profiles), vote for it:

https://chaoscorona.ideas.aha.io/ideas/CMAX-I-152

4
We had some similar cases in the past. This comes from the fact that 3ds Max+Corona is not "color profile-aware". The most straightforward solution is switching your monitor to sRGB in its OSD settings.
/rant mode

Which is the worst of all possible suggestions - sorry for that.

What every unexperienced user (unexperienced in terms of color management) gets wrong is that OCIO is dubbed color management in Max while in reality, it's a rendering space + tone mapping, which has *nothing to do with managing colors as in 'make sure the colors look the same across all my apps*. This is partly due to user ignorance, hidden settings in Windows, partly due to 3ds max who don't care about PS and print, and finally Corona devs who just can't be bothered to finally implement a final ICC-based transform in the VFB and embedding that ICC profile (chosen by the user) when saving files, even after all the posts asking why colors don't look the same in PS/Windows.

Let's see how long until the next user is asking the very same thing, only to be told that sRGB is the way to go (which it isn't, it's just an additional display of ignoring the fact that Corona could and *should* solve it right in the VFB/file).

/rant mode off

5
[Max] Bug Reporting / Re: Memory leak
« on: 2025-09-02, 22:18:03 »
So the problematic object is a box, so one object with a MultiMaterial assigned? Not different objects for each material?

If this is the case, it could be that the ray optimization engine fails. And if it's the case, what happens if you separate the object into individual planes, does this help?


6
[Max] Bug Reporting / Re: Memory leak
« on: 2025-08-28, 19:30:15 »
I think the crazy RAM usage here is the result of a few things in the scene, but they all seem to be related to the Legacy Mtl. For example, if you lower the Legacy Mtl's Fresnel IOR from 100 to the default 1.52, then it renders fine. Also, if you isolate either of the objects, it renders fine (even with the "wrong" materials and render settings).

Since the Physical Mtl is here to replace the Legacy Mtl and it already contains various fixes, I don't see a need to log this for the devs.
There's still a use case for LegacyMtl - pure reflection and refraction, PhysicalMtl always introduces some darkening. I have scene where Legacy needs to work because of this (some optical trickery that just won't work with Physical).
Also, like in my case, there are many scenes that use LegacyMtl that I need to rerender with minor changes from time to time. I'd hate to see LegacyMtl produce problems since switching to PhysicalMtl is not always possible for various reasons. Please don't let it die...

7
I might have agreed to post on a forum and have others see my posts - that's about it, not more than that.
So, sure, go on and have a blast. Just make sure my posts aren't included in your 'research'.

That's not really my goal here, and if I'm in wrong here with this concept then I won't proceed with the idea. Besides, I don't even know how one would implement it and was more interested in discussing a tool that would be useful not only for me but for all the community. If it's not within forum rules then I guess there's no reason to continue this discussion.
I see. I'll try to distant myself from my negativity towards AI for the sake of constructive feedback... Let's say you were able to achieve what you want - what exactly would it help you with? Tell you what settings to use in a certain scenario? Tell you why your lighting doesn't look good or the camera renders black? There are so many different variables in almost any 3d related job, it would be impossible for an AI to correctly understand your problem and suggest a possible solution. After all, I don't think it would actually be able to be as concise as another experienced user or support staff. There's an extensive online reference plus this forum with real people who can help with almost anything you could come up with, so what exactly is missing right now that you're trying to solve?

Don't get me wrong, but your request sounds like the common 'let's throw AI at something and expect magic to happen with rainbows on the side' techbro wet dream. It can only disappoint.

FWIW, I think that the company running this place should prohibit anyone from scraping the content (or to clearly communicate it's not allowed, even if it can be worked around by simply creating a profile). After all, some people here have chosen to share private data, the staff should at least realize there's a risk of abuse of personal data by using automated tools. Just to shrug it away casually is not OK in my opinion and I'm surprised no one cares.

8
I might have agreed to post on a forum and have others see my posts - that's about it, not more than that.
So, sure, go on and have a blast. Just make sure my posts aren't included in your 'research'.

9
All the obvious (and questionable) use cases aside - have users ever agreed to their posts (and potential solutions and work results) being scraped off the forum like that? Don't think so... and honestly, wtf?
Posting to a forum and having it visible to forum members is different from having someone scraping it for 'content gain'. Do the leg work and learn on your own just like everybody else.

10
I recently ran into this with a grass patch model.
Make sure to disable map filtering for the diffuse bitmap. It's likely caused by a black background in that map where pixels get filtered to a darker tone progressively with increasing distance. It's best to disable filtering on all maps used on fine details anyway as it can be too aggressive.

11
Since you're looking at CIE anyway, there's this thing where, if you save a file as TIF with alpha, it'll open in PS with the alpha already applied so areas with black alpha are erased from RGB channels. This makes it necessary to save 2 files when using TIF - one without alpha and another one with alpha included to get the background to carry over to PS.
This also differs from the VFB in Max where the image is left intact and alpha is present in a separate channel (the way it should be).
Sorry for hijacking the thread..

+1 for error-free batch output and an UI for batch processing.

12
I have also requested that the info must be disclosed (there was a thread on the chaos forums where people complained about this). You can't expect people to hunt down all the info. Also, in the EU, the seller is required to disclose the content of the product and besides, it's just bad style not to do.

Honest question - what is management/sales gaining by not disclosing the contents of each package in a transparent way? It only produces errors along the way, adds to workload of the support staff and hurts the client relationship.

13
[Max] General Discussion / Re: ForestPack Masking
« on: 2025-08-04, 15:50:14 »
I think we had this discussion, when it was accidental changed in c12…. Because we got used to the workflow with ids for individual source objects and not Forrest object.
If this source object could’ve maintained and the other would be an optional approach it would be fine. But I like to have individual mask for source objects (trees or furniture etc) to alter it in post.
If only Forrest pack is able to have a mask I’d, then you end up with many Forrest objects for various source objects.

Just as dj_buckley said it’s quite easy to select individual source objects and all apply them same id
I guess the update by Maru is because of me requesting the ability of masking whole Scatter objects in another thread.
I'll second what you say - having individual object IDs in masks *is* really useful.

I guess a good solution without changing the current behavior would be if Scatter objects would actually show up in manual selection lists in the mask element, currently they don't. This way both ways of masking would be possible. Hopefully no need to change the way it's currently.

14
Left my vote, thanks again guys.

15
Thank you, much appreciated as always.

Pages: [1] 2 3 ... 134