Corona Renderer 8 for 3ds Max - Daily Builds Discussion

[TomG]

No different algorithms - what the UVWRandomizer allows you to do is apply randomness based on object, instance, polygons, etc. so the same randomization algorithm is involved, just it is triggered to calculate a new random number when you are on a new polygon (that's the new randomization mode). That would not apply to Scatter though.

BTW in what way is the randomization in Scatter "not random enough", that part confuses me - an example of what you get vs what you would have wanted (some sample image from another source, whether that be photo or otherwise) would be handy to know what you mean.

[lupaz]

No different algorithms - what the UVWRandomizer allows you to do is apply randomness based on object, instance, polygons, etc. so the same randomization algorithm is involved, just it is triggered to calculate a new random number when you are on a new polygon (that's the new randomization mode). That would not apply to Scatter though.

BTW in what way is the randomization in Scatter "not random enough", that part confuses me - an example of what you get vs what you would have wanted (some sample image from another source, whether that be photo or otherwise) would be handy to know what you mean.

Hi Tom.

Ok. It's not easy to explain, and I hope you don't think I'm crazy for showing this. But, attached I'm sending 3 images done with corona scatter and 3 done with Forest Pack (also a PDF file for comparing, and the Max file).
I changed only the random seed between each option.

In the Corona images there are several groups of 3, while in the forest pack images I found only one.
What I'm trying to say is that I noticed clusters in Corona scatter.
Also it seems to me that Corona doesn't use all colors as many times evenly (in this example few white ones), while Forest pack does. But this may be just my impression.

Edit: The same would go for MultiMap I think.

[marchik]

Yes, I'm using the latest 0,16135 build from Jan 26 and simple setup with spheres falling from tyIcon, nothing special

Can you send the scene over?

Rowan

Of course, maybe I just don't understand how it's supposed to work.

see the attachments (Max 2021)

[rowmanns]

Yes, I'm using the latest 0,16135 build from Jan 26 and simple setup with spheres falling from tyIcon, nothing special

Can you send the scene over?

Rowan

Of course, maybe I just don't understand how it's supposed to work.

see the attachments (Max 2021)

Hi,

Corona still currently doesn't support motion blur for objects with changing topology. Which is why the motion blur isn't working in this case.

It's something we have logged already.

Thanks,

Rowan

[marchik]

Hi,

Corona still currently doesn't support motion blur for objects with changing topology. Which is why the motion blur isn't working in this case.

It's something we have logged already.

Thanks,

Rowan

but

will be done in v8

and

Hey,

Support for tyflow was released in todays daily build. You can grab it here: https://forum.corona-renderer.com/index.php?topic=33839.msg194357#msg194357

Cheers,

Rowan

it was your reply in "tyflow Motion blur" topic, so I thought it was solved in tyflow now, in current daily build, and I understand why it didn't work before
in this case, can you explain what exactly is "tyflow support"?

PS in the max scene itself, the parameter in the mesh operator is set to "render instances", and there is nothing on the render in this case.

[mike288]

No different algorithms - what the UVWRandomizer allows you to do is apply randomness based on object, instance, polygons, etc. so the same randomization algorithm is involved, just it is triggered to calculate a new random number when you are on a new polygon (that's the new randomization mode). That would not apply to Scatter though.

BTW in what way is the randomization in Scatter "not random enough", that part confuses me - an example of what you get vs what you would have wanted (some sample image from another source, whether that be photo or otherwise) would be handy to know what you mean.

Hi Tom.

Ok. It's not easy to explain, and I hope you don't think I'm crazy for showing this. But, attached I'm sending 3 images done with corona scatter and 3 done with Forest Pack (also a PDF file for comparing, and the Max file).
I changed only the random seed between each option.

In the Corona images there are several groups of 3, while in the forest pack images I found only one.
What I'm trying to say is that I noticed clusters in Corona scatter.
Also it seems to me that Corona doesn't use all colors as many times evenly (in this example few white ones), while Forest pack does. But this may be just my impression.

Edit: The same would go for MultiMap I think.

Hi lupaz,

thanks for your example. The thing is that in our Scatter we are using (or at least trying to use) uniform random distribution during instance generation. :-) In your example you have 8 cube types and 195 instances of them. If I have computed the math correctly for your case (using Markov chains) there is only about 6% probability that there will be NO triplet of same cube types in a row. In other words there is about 94% probability that 3 or more same cube types in a row will appear. Obviously, more instances you create, the latter probability gets increased (195 is already two-degrees larger than 3 and 8).

So from this point of view it is rather Forest Pack that does not behave 'randomly'. It clearly uses some non-uniform distribution. Or you were extremely lucky and hit those 6%, hehe. :-) Anyway, ATM it does not seem to me that our Scatter behaves differently than designed = uniformly. But I get your point and maybe we could offer some other distribution type(s) that might serve certain user scenarios better. I am taking a note for the future. ;-) Thanks.

[romullus]

I might be wrong, but i think Sini scatter has a feature "avoid similar neighbours" or something along the lines. Might be interesting to look at it closer.

[lupaz]

But I get your point and maybe we could offer some other distribution type(s) that might serve certain user scenarios better. I am taking a note for the future. ;-) Thanks.

Great.
Thank you Mike!

[pokoy]

Hi lupaz,

thanks for your example. The thing is that in our Scatter we are using (or at least trying to use) uniform random distribution during instance generation. :-) In your example you have 8 cube types and 195 instances of them. If I have computed the math correctly for your case (using Markov chains) there is only about 6% probability that there will be NO triplet of same cube types in a row. In other words there is about 94% probability that 3 or more same cube types in a row will appear. Obviously, more instances you create, the latter probability gets increased (195 is already two-degrees larger than 3 and 8).

So from this point of view it is rather Forest Pack that does not behave 'randomly'. It clearly uses some non-uniform distribution. Or you were extremely lucky and hit those 6%, hehe. :-) Anyway, ATM it does not seem to me that our Scatter behaves differently than designed = uniformly. But I get your point and maybe we could offer some other distribution type(s) that might serve certain user scenarios better. I am taking a note for the future. ;-) Thanks.

This reminds of the story about music streaming apps and shuffle playback. Truly random shuffling would mean that you could hear the same song twice in a row, or multiple songs even, which is not what people *expect* from random behavior - similarly, if for example someone was told to put flowers in a garden randomly, he would probably avoid putting the same type of plant next to each other because it wouldn't be random... while in fact it would.
Same here, whenever some random function comes up with the same thing too close to each other I change the seed. Not random enough :D

[aaouviz]

Hi lupaz,

thanks for your example. The thing is that in our Scatter we are using (or at least trying to use) uniform random distribution during instance generation. :-) In your example you have 8 cube types and 195 instances of them. If I have computed the math correctly for your case (using Markov chains) there is only about 6% probability that there will be NO triplet of same cube types in a row. In other words there is about 94% probability that 3 or more same cube types in a row will appear. Obviously, more instances you create, the latter probability gets increased (195 is already two-degrees larger than 3 and 8).

So from this point of view it is rather Forest Pack that does not behave 'randomly'. It clearly uses some non-uniform distribution. Or you were extremely lucky and hit those 6%, hehe. :-) Anyway, ATM it does not seem to me that our Scatter behaves differently than designed = uniformly. But I get your point and maybe we could offer some other distribution type(s) that might serve certain user scenarios better. I am taking a note for the future. ;-) Thanks.

This reminds of the story about music streaming apps and shuffle playback. Truly random shuffling would mean that you could hear the same song twice in a row, or multiple songs even, which is not what people *expect* from random behavior - similarly, if for example someone was told to put flowers in a garden randomly, he would probably avoid putting the same type of plant next to each other because it wouldn't be random... while in fact it would.
Same here, whenever some random function comes up with the same thing too close to each other I change the seed. Not random enough :D

Yes, I had a similar thought. I recall Damien Hirst (I think!) once fired an intern for arguing that if something is truly 'random' then multiple instances of the same thing would naturally occur in succession. Hirst later admitted he was wrong and changed his mind.

[rowmanns]

Hi,

Corona still currently doesn't support motion blur for objects with changing topology. Which is why the motion blur isn't working in this case.

It's something we have logged already.

Thanks,

Rowan

but

will be done in v8

and

Hey,

Support for tyflow was released in todays daily build. You can grab it here: https://forum.corona-renderer.com/index.php?topic=33839.msg194357#msg194357

Cheers,

Rowan

it was your reply in "tyflow Motion blur" topic, so I thought it was solved in tyflow now, in current daily build, and I understand why it didn't work before
in this case, can you explain what exactly is "tyflow support"?

PS in the max scene itself, the parameter in the mesh operator is set to "render instances", and there is nothing on the render in this case.

Hi,

I have attached our benchmarking scene which we used for testing tyflow support. Which works with standard geometry motion blur and instancing.

I have checked out your scene and you need to have "Enable Particle Interface" checked in the tyflow object in order for the particles to be rendered. I have attached a screenshot as well.

Let me know if you need some more info, or questions.

Thanks,

Rowan

[shortcirkuit]

hey guys - how does cryptomatte work?

[TomG]

What I do is save it to CXR, change name to EXR, load it into Photoshop using Exr-IO (the latest version understands cryptomatte information). You then get all the layers in Photoshop, one for each Named object or Layer or Name and Layer etc. depending on what option you choose for the Cryptomatte element. Each Photoshop layer is a mask for that object (or however you asked Cryptomatte to gather things together), which will include motion blur and DOF, which I can then copy and paste into the mask of say an Adjustment Layer to tweak something about that particular object (or object group, or however you set it up :) )

Of course there are other programs that can read in and understand Cryptomatte data such as Nuke (and Photoshop won't understand it without the free Exr-IO).

[shortcirkuit]

thanks for that - so is it essentially like a wirecolour with more precise selections?  as the wirecolour can miss some pixels
if it is - then i would say its a hybrid between wirecolour and MASKID ?  meaning its a wirecolour with precise selections?

What I do is save it to CXR, change name to EXR, load it into Photoshop using Exr-IO (the latest version understands cryptomatte information). You then get all the layers in Photoshop, one for each Named object or Layer or Name and Layer etc. depending on what option you choose for the Cryptomatte element. Each Photoshop layer is a mask for that object (or however you asked Cryptomatte to gather things together), which will include motion blur and DOF, which I can then copy and paste into the mask of say an Adjustment Layer to tweak something about that particular object (or object group, or however you set it up :) )

Of course there are other programs that can read in and understand Cryptomatte data such as Nuke (and Photoshop won't understand it without the free Exr-IO).

[shortcirkuit]

one other thing mate - so you save it as a CXR version out of max and then in windows you rename the extension to EXR?  can i ask how you do that?  because when i try the simple rename method, it doesnt open in photoshop (error)

What I do is save it to CXR, change name to EXR, load it into Photoshop using Exr-IO (the latest version understands cryptomatte information). You then get all the layers in Photoshop, one for each Named object or Layer or Name and Layer etc. depending on what option you choose for the Cryptomatte element. Each Photoshop layer is a mask for that object (or however you asked Cryptomatte to gather things together), which will include motion blur and DOF, which I can then copy and paste into the mask of say an Adjustment Layer to tweak something about that particular object (or object group, or however you set it up :) )

Of course there are other programs that can read in and understand Cryptomatte data such as Nuke (and Photoshop won't understand it without the free Exr-IO).