Messages

31

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

« on: 2023-12-20, 10:13:45 »

even in a non-teapot scene ;)

Don't use such scenes, you may encounter bugs ;]


Good Luck

32

[Max] Feature Requests / Re: My VFB Redesign

« on: 2023-12-08, 08:54:09 »

I hope not. Yes, it looks good, not as dusty as the current one with nice icons, but I'd not like to work with it: needs a lot of space (scroll party if expanded) and -most important- you cannot see the main values without permanently stepping through the operators. I'd like to see the main parameter as in current VFB next to the operator name at least, then: yes, please some modern touch for VFB (I prefer option 2) :)


Good Luck

33

[Max] Daily Builds / Re: Tiles playground

« on: 2023-12-07, 12:02:35 »

Is it a technical reason with displacement calculation in IR?

Displacement would have to be calculated at every viewport change, the "I" from IR would be lost :) But you can use this one:

https://forum.corona-renderer.com/index.php?topic=36556.0

It basically does something similar like changing some material as you mentioned and updates displacement without reparsing the scene while limiting itself to materials with enabled displacement.


Good Luck

34

[Max] General Discussion / Re: Can't cancel auto renewal? Now have to pay for another year?

« on: 2023-11-30, 13:09:43 »

Lol exactly what we've been discussing.

Amazing, yes. A destitute and clinical "message" that reads more like a "don't tell unsuccessful stories about 'success team' in public" directive. And 'Warm regards' feels rather like being welcomed in a fridge. I should really start to use AI to train myself being able to communicate with the disembodied :)


Good Luck

35

[Max] I need help! / Re: Mapping Randomizer and Displacement help

« on: 2023-11-29, 09:48:01 »

So basically is still a known issue and we'll see it being solved in Corona V11?

Yes. You can try the current release candidate here if you like to see the difference:
https://forum.corona-renderer.com/index.php?topic=40442.msg219200#msg219200
Or just wait for v11 final, should be out soon.

I tried dj_buckley's suggestions (thanks btw) to use low values but unfortunately I still get the offset in the displacement.

I'm not aware that using [0;1] range could solve anything in this case.


Good Luck

36

[Max] I need help! / Re: Mapping Randomizer and Displacement help

« on: 2023-11-29, 09:16:57 »

Hi,

I searched the forum before posting and I'm aware this was a logged issue around Corona 7 but apparently it was solved and it only occurred when setting the then w UVW randomizer was set in mesh mode.

Polygon mode arrived later in Corona v8, that's why it is not mentioned in most of the threads regarding this issue. But it is (was) affected as well (v8 to v10). The issue is finally solved in Corona v11 (current dailies/release candidates and v11 final of course).


Good Luck



Edit: typo

37

[Max] Daily Builds / Re: Tiles playground

« on: 2023-11-28, 17:27:37 »

What I dont understand its, since the first time I tried Corona in v4, BerconTiles seemed to be incompatible (at least this is what the VFB says), but the ressults doesnt seem to be failing, could someone elaborate on this?

The error message is a bit missleading. It's just about the fact that you can easily get it to crash, especially if you have "show in viewport" activated on the material using it. But it works flawlessly (there has been even a fix for some -if not all- Corona maps a while ago to work properly with BerconTile - it did not made it into the changelogs for some reason though).


Good Luck

38

[Max] Daily Builds / Re: Tiles playground

« on: 2023-11-28, 17:05:08 »

The idea is to have constant width gradient independent from gap bump/displacement.

Yes, I just wanted to point out, that you can get something similiar like using your combined gradient ramp approach by using the CoronaTile map itself more easily. Still it suffers from the corner edges (as blended gradient ramp in box mode does) but it is not distorted by scaling. And the maps have to be wired to be able to change one and get the proper gradient automatically - not convenient but works.


Good Luck

39

[Max] Daily Builds / Re: Tiles playground

« on: 2023-11-28, 15:15:33 »

That does not make any sense to me. Corona edge is working on geometry, not on UVWs/tiles. Additionally, the output is ugly like gradient ramp currently :) But maybe there is another solution.

When tiles proportions significantly differs from square, gradient ramp is noticeably stretched.

You could use the same tiles map with b/w setting and gap blur - looks similar to gradient ramp but stays absolute in distance. Maybe piped through any curve operator (output map / CoronaColorCorrect etc.) to further shape the gradient. Yes, a map able to create absolute borders in a tile would be great. Afaik not "even" BerconTiles/Maps are able to do something similar.


Good Luck

40

[Max] Corona Goodies - User Contributions / Re: Corona Randomizer

« on: 2023-11-24, 10:31:49 »

My life is just full of undefined lately :D

Fortunate :) Everything is possible then.


Good Luck

41

[Max] Corona Goodies - User Contributions / Re: Corona Randomizer

« on: 2023-11-24, 09:11:50 »

Hey James,

have not (again :) looked at the script but it should work straight like this:

Code: [Select]

if (sme.getview sme.activeView)!=undefined then (
selectedNodes = (sme.getview sme.activeView).GetSelectedNodes()
if selectedNodes.count!=0 then (
for sNode in selectedNodes do (
if (superclassof sNode.reference == material) then (
format "Doing something with '%'\n" sNode.reference.name
)
)
)
)


Good Luck

42

[Max] I need help! / Re: Slow DR Parsing etc

« on: 2023-11-14, 10:37:13 »

But out of interest, when optimizing.  What's more important, Texture Resolution or Texture File Size?  i.e. if the texture is 8k but the file is only a few MB does it need optimizing?

The size on disk does not matter, it gets extracted into memory anyway. So for the rendering process, it's no difference if you load 8k from a small JPG or any uncompressed file format. But if you use CoronaBitmaps, you save a lot of memory when using the out of core feature.

Anyway my first test, I've just been watching the render with all of the windows open via remote desktop for one of the nodes.

The "slowwwww" parts just come from loading assets imho. Your master already has a lot of them loaded, to set up the viewports for example. Network/disk usage (depending on the location of your stuff) should be high at the same time.

Max Process (underlined blue) does not exceed 90GB at any point during any of the above.

Those insane commit sizes you listed are exactly the issue I monitor at most jobs. And they are responsible for crashes, even if the process seems not to need or use the provided virtual memory. It is just crazy to see the system paging gigabytes of ram for a scene that can actually render with a fraction.

I was also expecting these circled numbers to match or have I got that wrong

No W11 here, the memory page in task manager would have been useful, don't know what W11 shows here. If it is like W10, then yes. Additionally I don't know how Corona exactly displays the values there (Gibibyte vs. Gigabyte, that is 2^30 vs. 10^9 bytes per "GB"). But I assume the values are fractional Gibibytes.

Edit: Taskmanager seems to show used ram in your screenshot while DR tab shows (system) commit size.

There are a couple of things I find odd.

Agree. I would like to know the answers as well. Except for the duplicated scene Max stores, I have no hint what is causing all that trouble.

But as for the slow DR, same as above: DR server spawns a Max instance and all stuff that is already loaded when pressing render interactively has to be processed first. If you look at your max.log when loading a scene, you will notice a line like "Done loading file: (...)". Note the timestamp and see how many minutes you have to wait for Max getting responsive when loading a scene interactively. That time between loading the scene and having a "renderable" scene adds to DR nodes because the scene is (currently) loaded on the slave every time you start rendering on the master.


Good Luck

43

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

« on: 2023-11-11, 15:37:24 »

Should i try to update GPU drivers, or maybe Corona team forgot to package needed dll in the installer?

Looks like just a wrong additional "optix" directory (I haven't used the installer but if I extract the package, it's there as well). Go to

C:\Program Files\Corona\optix

and if there is another "optix" subdirectory, copy (or move) the dll in there one level higher.


Good Luck

44

[Max] Bug Reporting / Re: Need Help with Random Crashes Using Corona IR in 3ds Max

« on: 2023-11-10, 12:56:49 »

Hi,

shot in the dark, but could you please try to replace

C:\Program Files\Corona\Corona Renderer for 3ds Max\2022\LegionLib_Release.dll

by the same file of another, working node (or an extracted Corona 10.2 package).


Good Luck

45

[Max] I need help! / Re: Slow DR Parsing etc

« on: 2023-11-10, 10:19:19 »

First question, less than 2 minutes.

Oh amazing. Starting Max alone takes about 30 seconds on my computer :) So it loads, parses and starts rendering in 2 minutes in fact?

Edit: seen your edit :)

The point is, regardless of task managers details etc etc. I can render it on all 3 individually, if I open the scene on each and just render.  But I can't through DR.

That's interesting, more later.

Another issue while I remember.  When I first open a scene, fresh 3ds max, open scene and render.  It struggles with all of the parsing and loading and I get ram warnings.  However if I cancel the render and render again, it all goes through much quicker with no issues.

That's even more interesting because with scenes using all available ram, I struggle with this phenomenon since ever. Look at the graph (older one I captured, but still applies). It shows a BB render node crunching a job. At the fist bubble, I logged in and started another Max session and rendered some scene locally (flat part of passes graph). Second render stops at the second bubble. Look at the ram consumption of the first job: It drops from 15+GB to about 6GB and stays at that level to the end. I can observe this until now, also with larger scenes and larger impact. Sometimes it's even enough to log on and do anything on the node.

One possible explanation is: 3ds max holds an entire copy of the scene while the renderer has another. At some point, a kind of purge seems to happen. I never found out how to trigger it by purpose.

But such a gulf between them seems crazy.

I still don't see that until you check the working set (and not the commit size) of the dr node max process, curious what you will find.


Good Luck