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

Pages: 1 [2] 3 4 ... 128
16
[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




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




18
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




19
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



20
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

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




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




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




24
My life is just full of undefined lately :D

Fortunate :) Everything is possible then.


Good Luck




25
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

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





27
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




28
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


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




30
[Max] I need help! / Re: Slow DR Parsing etc
« on: 2023-11-10, 09:20:49 »
Why are DR nodes so slow to join in?

Counter question: how long does it take on the master to load the scene, press render and to have it actually rendering the first pass?

Also I can't help but come back to that "DR nodes use more RAM than the main workstation issue" from years ago.  It still blows my mind.  It shoots up to over 180GB+ on the nodes which then causes them to fail rendering.  But the main PC renders it fine and happily churns along at 75GB RAM usage.

You are comparing the wrong data. Those 75GB of the render status window is the active working set of the 3ds Max process, while the 180GB of the DR status display is the ram commit size (additionally: for the complete system. This should not make a significant difference here if the nodes are dedicated and nothing else is running). You'd have to compare the 180GB to the second value of the render status window of the master: 235GB. So the master uses more ram according to your screenshots, not the other way round.

Best is to compare using taskmanager and activating all ram relevant columns in the "Details" tab. Do this on master and slave. Still the question is: who/what requests (and does not use) such a large amount of memory. Do you use any fancy plugin here? I'm aware of strange commit sizes using Max generally, but 75GB vs. 180+ (commit size) looks in fact extreme. Does the master uses "only" 75GB for the process from start or is it much larger when loading/starting to render and later goes down to 75GB?

As for the fail: do the nodes actually crash? As always: logs, logs, logs from the slave will help:

- 3ds Max log: "Max.log"
- DrServer log: "DrLog.txt"
- Corona log: "CoronaMax2024_log.txt", "CoronaMax2024_errors.txt"


Good Luck




Pages: 1 [2] 3 4 ... 128