Messages

4336

[Max] Daily Builds / Re: Daily builds version 2

« on: 2018-03-09, 18:04:33 »

Do Chaos guys plans to propose the same thing on their side, providing VRay support for Corona lights and materials ? :P

As mentioned back as far back as the Merger announcement at https://corona-renderer.com/blog/new-horizons-plans-for-2017-and-beyond/

"Very soon we will introduce compatibility between each other’s assets. You will be able to use V-Ray proxies, materials and lights in Corona, and vice versa. Our goal is to remove or greatly reduce the need for converters, so that you will be able to switch between engines based on your needs with respect to the project you are working on."

So the plan is for it to work both ways, load a scene from either engine into either engine and be able to get results without conversion.

4337

[Max] Daily Builds / Re: Daily builds version 2

« on: 2018-03-09, 15:20:36 »

If i remember right VRScans were into trello roadmap but now they have been removed.
Are they already included into Vray Materials?

Already discussed by the devs in this thread :) https://forum.corona-renderer.com/index.php?topic=17973.msg122376#msg122376 - here's the quote:

"
VRscans unfortunately won't make it to v2, they have already been removed from Trello roadmap some time ago.

VRayLight has already been released in latest daily.

We are currently also working on support for VRayMtl which should appear in dailies soon. We already got it working with V-Ray installed and we just figuring a way to make it working without V-Ray.

Obviously full support for VRayLight and VRayMtl is quite a complex task so currently we implement only a subset of their functionality. Current plan is to support the same features which are supported by CoronaConverter script and then implement additional functionality if/when needed.
"

4338

[Max] Daily Builds / Re: Daily builds version 2

« on: 2018-03-09, 14:47:12 »

And, if we can indeed get it working, removing the need to have V-Ray installed - the converter has to have it installed, at least in trial mode, but we are hoping that will not be necessary for rendering direct in this way. As noted earlier, that is happening with the V-Ray lights so far (I was able to render the supported V-Ray lights using DR on Workstation with V-Ray installed, while nodes did not have V-Ray installed, and it worked no problem) - whether the same is possible with materials remains to be seen, but it is what we'd like to get to.

4339

News / Small fraction of Russian users affected by payment issues

« on: 2018-03-08, 15:32:21 »

Dear Customers,

We wanted to let you know that recently a small fraction of our users were affected by some problems with the provider we use to process payments. This seemed to be localized mostly to users from Russia, and our provider has told us that this issue has now been resolved. Where needed to correct any errors, we will be issuing refunds as soon as possible. We apologize for the inconvenience.

Thank you for your patience,
   Tom

4340

[Max] I need help! / Re: Clean noisy motion blur

« on: 2018-03-08, 14:42:19 »

You could lower Gi vs. AA balance, as that can help shift processing power onto DOF and MoBlur (see https://coronarenderer.freshdesk.com/support/solutions/articles/5000526159-what-is-gi-vs-aa-balance- ). Is it just that it is taking a while to clean up, not that the effect is too strong (in which case, adjusting the camera values could help). Another thought I have (not tested this, so it is just a thought!) is that raindrops closer to the camera will show more motion blur, so perhaps limiting how close they are to the camera could help by avoiding ones that have excessive motion blur.

Last, there is also the option to use the CGeometry_Velocity and add the moblur in post (e.g. using the free Fusion, or commercial plugins for After Effects like RSMB), while this can be less realistic, it can certainly be faster, and may be just fine for something like raindrops. See

4341

[Max] General Discussion / Re: New light solver is fantastic.

« on: 2018-03-08, 13:38:44 »

With the light solver : 25 passes for 17'58"
Without (disabled) :  25 passes for 13'37"

The only thing I've noticed is a better quality of rendering.

Don't forget that sometimes "faster rendering" does NOT mean the same number of passes in less time - sometimes a single pass may take longer, but be of much greater quality (lower Noise Level, and visually much better). In those cases, comparing the same number of passes does not give the comparison, and instead rendering for a specified time or to a specified noise level will show the improvement. In both cases, this means you will need less passes to get to the same result, and so less time = faster rendering (and if you are using passes, now you set a lower number of passes, to get the same or better results in less time)

4342

[Max] General Discussion / Re: Best way to optimise large terrain scenes?

« on: 2018-03-07, 18:21:30 »

Looks like it is the artefact caused by sharpening / blurring from a bright light source, as reported at
https://forum.corona-renderer.com/index.php?topic=19127.msg119802#new

A fix is in the Max daily builds as of Feb 8th (https://forum.corona-renderer.com/index.php?topic=17972.msg120416#msg120416 )

4343

[Max] General Discussion / Re: Best way to optimise large terrain scenes?

« on: 2018-03-07, 18:08:53 »

Other advantage (in case you really need convincing :) - with still frames, you can always experiment with different video compression settings, but if rendering to a video format the compression is baked in and you'd need to re-render to change it. And, if you've seen how long it can take to apply the codecs to stills when making a video format, bear in mind that rendering direct to video format is adding all that extra time into your render itself as well.

4344

[Max] General Discussion / Re: Best way to optimise large terrain scenes?

« on: 2018-03-07, 18:05:48 »

One thing - for animations, always render to still frames, and composite to an animated format (mp4 etc) later. There are many reasons for this, the main one being that with most movie formats, if the render fails at any point, all work is lost. If you are rendering to still frames, only the current frame is lost and you can start re-rendering from that point onward.

This thread also makes me wonder how much of the animated format is held in memory or disk cache during rendering, since the whole file has to be built at once and can't be added to incrementally. Either way, definitely rendering to stills and composite into movie format later is a critical workflow for many reasons and may help with this issue too.

4345

[C4D] Resolved Bugs / Re: Cant stop team render

« on: 2018-03-07, 14:11:21 »

For having Team Render stop by itself, do remember that only Passes works as a target for now - Noise and Time limits are set for Beta 2 (see the roadmap at https://trello.com/c/C0HeJ3Em/48-team-render)

Just so I understand properly, though, that's not the original question? The original question was being able to manually stop a render, even if it was set to use a certain number of passes?

4346

[C4D] General Discussion / Re: coronaC4D manual?

« on: 2018-03-06, 16:22:34 »

PS, the tooltips can be viewed online using https://corona-renderer.com/doc/ if you don't have access to Max.

4347

[C4D] General Discussion / Re: coronaC4D manual?

« on: 2018-03-06, 16:20:27 »

There is no PDF manual for Max either (for the same reasons, that it would be needing continual updates with the speed at which Corona changes). The YouTube channel with the tutorials is the main educational resource that we've focused on, along with the Helpdesk, and then the forum here for any specific questions - and in Max, the tooltips provide most of the required information too.

4348

[Max] Resolved Feature Requests / Re: Automatically store frame buffer history

« on: 2018-03-06, 15:49:01 »

Most welcome! Also, good to hear suggestions on how the current implementation might be improved (always good to check whether this was a "I know what is there already, but adding x to it would make it even better" vs "I didn't know it was there" :) )

4349

[Max] Resolved Feature Requests / Re: Automatically store frame buffer history

« on: 2018-03-06, 13:42:37 »

Image of where the setting is, in case it helps :)

4350

[Max] Resolved Feature Requests / Re: Automatically store frame buffer history

« on: 2018-03-06, 13:40:04 »

There is the "Render history and A/B comparison" in the System settings, that allows Auto saving on render end, with a limited size on the HDD. Does that do the job?