IPR Crashes

[glorybound]

Seems to be often. If I turn off a layer, move something... it does't really matter.

https://files.acrobat.com/a/preview/...7-f9c8666ac097

[yavor.rubenov]

Hello,

Thanks for the scene.
So far I had a few crashes and they were because of a Raytrace map in the scene. It is attached to the diffuse slot of a VRayMtl "glass" attached to a Multi/Sub-Object material "RenderStuff_Samsung_PS-42Q91H_Plasma". If I remove the map things so far look stable but I'll keep looking.

Best regards,
Yavor

[^Lele^]

So far I had a few crashes and they were because of a Raytrace map in the scene.

But... that would be printed in the render log, right?

[NicoC]

Just in case ...

BadRaytrace = getClassInstances raytrace
for R in BadRaytrace do replaceInstances R (falloff name:R.name)

[^Lele^]

or a one-click scene conversion.

[glorybound]

I convert all my scenes, so that wasn't converted and there wasn't anything in the message window, MAX closed without warning.

[^Lele^]

Output from a scene conversion in the max listener:

Converting scene materials...
  Map #1:Raytrace
  Material #1:Standard
    Plane001
Converting Material Editor materials...
  Map #1:Raytrace
Done
Converting shadows...
Done
Converting scene Lights...
Done

Result of rendering without the raytrace map removed in the log:



Make doubly sure you are warning-free at rendertime, or this will happen again, and again, and again, and each time in a slightly different fashion.

[glorybound]

Gotcha! I didn't see that.

[Morne]

Make doubly sure you are warning-free at rendertime, or this will happen again, and again, and again, and each time in a slightly different fashion.

How about an option somewhere we can tick on/off, that instead of WARNING about this in the log, just goes ahead and fixes it for you when you hit render? (same with normal maps etc)

[^Lele^]

In what way would the checkbox be different than running the converter before rendering?

[glorybound]

In what way would the checkbox be different than running the converter before rendering?

I ran and it didn't fix it with the converter. I suppose that would be the question. I think Morne might be referring to how Corona handles errors. In Corona, it'll warn you with a hyperlink to fix it.

[Morne]

No, I was thinking more in the lines of automating things more if you want. So to AVOID similar issues like this in the 1st place and to "force" people to use the converter, what I'm saying is take human error out of the equation. So V-Ray KNOWS there is an error, then warns you. I would take it 1 step further and say, well there's an error that you KNOW about, instead of telling me about it, just go ahead and fix it please so I can get on with it.

It's just taking the human error away or removing a step to make things even easier for the user. After all, isn't this why we are using computers and not still stuck with drawing boards? Because things are suppose to be quicker and easier with technology (in a perfect world)

[^Lele^]

Where "perfect" is the unattainable keyword.
No, i'd have to vote strongly against that sort of automation, particularly coming from Chaos.
I have enforced it production, but that was under utterly regimented pipelines, with precise methods and tools in place, and a specific, long-term project as only goal.
Doing so by design in the software would create countless problems (some people may mean to have "wrong" stuff some way or the other in a specific scene setup.).
The tool maker task imo is to provide tools, and a hint of workflow.

Sanity checks, and some automation on individual fixes, or highlighting of the offending items, may be welcome, similar to what Deadline (or indeed Corona) does.
But i'd be strongly advising against any more than that.

[Morne]

Doing so by design in the software would create countless problems (some people may mean to have "wrong" stuff some way or the other in a specific scene setup.

Which is why I mentioned CHOICE for the user to use this as a feature, or not, with a simple on/off switch. (Not hard coded so you don't have the option)

[^Lele^]

Morne, jeez, sorry, I'm not trying to antagonise you on this, i'm trying to find the best way...

The Corona/Deadline method is great, until it isn't, (when, say, one has a few hundred errors in the list), and still requires users to take voluntary action to resolve the issues (at the least, the click of a link/button).

The checkbox which supposedly fixes all issues shares two limitations with all the other methods : the need for user discretion/manual intervention in some cases, and the fact we leave to the user to tick the checkbox/turn the feature on:
While not suffering from list length, it poses a few procedural conundrums: for example what should be done with user-allowed errors (say, i know there is a bad shader, but it's four rooms away. to heck with it), render or stop, and if the render should be allowed to proceed at all until errors are all fixed (which would sit exceedingly well with the spirit of said automation, and so badly with users.).

The current method, performed within the 3d scene, makes it a lot more clear that the stage at which to fix those mistakes is the Prepping one, not the Lighting and Rendering one.
If a user drags a completely new asset all the way to the rendering stage without once checking on its quality, it's on the user, not the software, whichever software that may be (and being in a rush was never a good excuse to skip due diligence: see the amount of time one wastes later.).

It can't fix them all, but it can be run as many times as one wants (some scenes build up incrementally over an extended period of time...), it can contain a UI with user options for the cases where user discretion is needed, it is a clear change to the scene contents, and as such is clearly flagged, and perceived, as needing a save (something which if happened right before rendering would pose countless issues with systems with their own versioning tools), and cannot be accidentally ran on farm jobs.

Duplicating an inferior version of it (ie. without the UI) in the render dialog seems to me of no use: it won't make the rushed jobs any better, won't make the fixes any easier, and won't make forgetful users remember.
I'd stand by what i wrote: we should at the very least provide for some guidelines and procedural hint, and let education and users' needs find their way into someone's production workflow.