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

Pages: [1] 2
Resolved bugs / Re: Anima + motion blur issue
« on: 2019-05-08, 23:14:48 »
I'm using 3.5.3 and corona 3 hotfix 1, and noticed the motion blur on anima objects only works when is more than 720 degrees. If you just have 180 degrees or even 360 (which is what is mostly use when recording film) we still get that in between motion blur that is like a double image.. So is kind of useless as 720 degrees is basically 1/15th of a second shutter (runing at 30fps) which is too much motion blur... hope this gets fully fix sometime.

Bug Reporting / Re: Motion Blur bug when using Auto Smooth
« on: 2019-03-10, 20:14:20 »
Relevant parts of the file, have been archived and uploaded (Cyclist Mblur Issue.max)


Bug Reporting / Re: Motion Blur bug when using Auto Smooth
« on: 2019-03-08, 19:34:12 »
Hi Maru,
Will collect and upload as soon as i can.


Bug Reporting / Motion Blur bug when using Auto Smooth
« on: 2019-03-06, 20:12:37 »
Dear Corona Team,

I think i found what looks like a bug... I have an animated skinned character... i needed to put a smooth modifier after skinning... and when i turn auto smooth motion blur stops working.. See video below.

Hi Sequana,

Yes the renaming feature can be a bit bothersome, and gets a bit messy when lights get removed and added to different light select elements; I included a checkbox (by default off) to avoid renaming the lights; I also added a Warnings off checkbox... to keep them off if you don't want to see them.

But actually, that message about the duplicates was referring to something else.. if you see on the top there is a checkbox to "Prevent Duplicates", the point of this is that if you have your render element LSE_Top and have  lights A, B and C on it and then you create a new light select element lets say LSE_Bottom and add light A (that was already on LSE_Top) it will remove it from LSE_Top to prevent having the same light in two different light select elements (this is because of our workflow later in NUKE) however if you do not care and purposely want to have lights A, B and C on two light select elements, then you need to turn the first checkbox of the script "Prevent Duplicates".

Hope this was clear, and thanks for the feedback.



Thanks for sending this.
I found the issue, was due to the fact that your render element names were not the same as the ones the script created. I created an exception for these instances, so you can still use your names and script will not fail.
Please download the latest version here, and let me know if this works now.



Are you using the latest version that is on the dropbox? If you are, can you take a look at the maxscript listener error and send me a capture of that?
And if possible send me the scene (only the lights) I will take a look...  I can't seem to replicate the error here.



In case anyone is using this, below is a link with the scripts (lightselect for 3dsmax has been updated, just drag on the viewport and should then be up-to-date).
We just fixed a little issue happening when lights get deleted after render light select elements are created.(as corona keeps a ghost of the deleted light with the name deleted on the list).


We have just finished developing a couple of scripts that we wanted to share with the hope that they can be useful to others.

We are big fans of the light mixer and is already an amazing tool as it stands... we found a few things, however, that could make its usage a bit more efficient and convenient, so we wrote two scripts.

Below is a video showing how they work:

The scripts are attached here.
We have used them already in a few projects and it has been very useful, especially in Nuke, but also to make the process in 3dsmax a bit easier.
If you are installing the python script on nuke you need to add the following lines to your

Code: [Select]
import LightMixer'Nuke').addCommand('Scripts/Light_Mixer', 'LightMixer.LightMixers()')'Nuke').addCommand('Scripts/SHuffle_Channels', 'LightMixer.ChMask()')'Nuke').addCommand('Scripts/Shuffle_All', 'LightMixer.AllChan()')

If you do use it please let us know what you think.
We will hope to post any updated versions and a bit more info in the blog of our website at Moso Studio.


Bug Reporting / Re: Strange behavior with map on Fresnel IOR
« on: 2018-08-10, 20:24:02 »
No, that's what I thought.. camera isn't moving... I'm just zooming in... that's what makes it very strange.

Bug Reporting / Re: Strange behavior with map on Fresnel IOR
« on: 2018-08-10, 18:54:36 »
As an update, this happens as well when doing the same setup using CoronaLayer Mtl.
Vray seems to do the same... however it handles it better as one needs to zoom in extremely close for the shading to change.

Bug Reporting / Strange behavior with map on Fresnel IOR
« on: 2018-08-10, 18:19:09 »
Dear Corona Team,

I think i found a bug on the behavior of the Fresnel IOR of the corona material when using a texture.
This very unpredictable behavior happens where the texture used almost fades when the camera is further or less zoomed in to the object, and the material is represented like a completely different material. Please look at the image attached that explains the issue.

I was just wondering if this is something you guys are aware off... it becomes a big problem when using corona with packages like substance, or 3D Coat, where the metalness controlled by this parameter is commonly used.

For the time being, will use a layer material but was hoping this could be looked into.



Tutorials & Guides / Re: Vegetation shader
« on: 2017-06-11, 00:12:20 »
Thanks Juraj, that explains why the duplicates.

Tutorials & Guides / Re: Vegetation shader
« on: 2017-06-09, 21:21:39 »

First of all thanks for sharing, I'm relatively new to Corona, so still learning a lot!
I have a question.
When i do this types of maps i thought it was better to reuse a bitmap input as many times as possible,(and modify saturation, hue and brightness for each component needed) instead of having different input versions... this way there are less bitmaps to load (so less memory) and if a different leaf is to be created, less maps to change, so the shader becomes more flexible... this I perhaps inherited from working with other node systems (Nuke, Houdini, etc)...

But is there a reason why this may be counterproductive? (other than the crossing wires that this workflow creates)

Thanks and look forward to learn more and share the little bit i can.


Pages: [1] 2