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 - Ink Visual

Pages: [1] 2 3 ... 12
Jobs / Animation Artist - Edinburgh
« on: 2024-05-03, 13:47:26 »
Ink is hiring! We are currently looking for Animation Artist to join our architectural visualisation team.
For more details visit:

Many thanks for the file Beanzvision.
So just to confrim, after checking Beanzvision's scene I reasured myself that in order to make the tile colour to be visible on vertical displaced edge you need to use different values for tile gap&blur in base colour and displacement. Generly speaking, base colour values for gap&blur size have to be smaller than dispalced value. This makes the displaced area slightly smaller than the colour area and thus it projects colour onto vertical faces.
Scene units have not much to do with it. (Maybe except for the fact that if you're using meters you need to allow max to use more than default 2 decimal places to use low values like. 0.001 or 0.0001 for better control of transition point)

The above method works but is not an ideal solution as you cannot drive tile shader with just one tile map but you have to use multiple ones to achieve desired result.

I think Romullus' idea of colour bias control would be a great adition to tile map controls.

Maybe we could have additional colour bias control which would shift tiles/grout colour transition point to either direction, because most of the times you want tile walls to have either one colour, or another, but not a smooth gradient. Beanzvision's method if it works, it does so in very specific case, which is hardly practical at all.

So I did the test with scene units set to cm and I still don't get the same results that Beanzvision posted.
The only way I could get the tile colour to propagate lower to vertical edges was using larger gap blur value for displacement tile map and 0.00 gap blur for the tilemap base colour.
This is also not an ideal solution as this way I cannot make use of SME additional node outputs to control all inputs with one corona tile map.

I think the only difference between my scene and Beanzvision's one is Corona version 11 vs 12. I cannot test 12 dailybuild atm though so won't be able to confirm if that makes any difference for me.
Alternatively, Beanzvision perhaps you'd be happy to share your scene with me and I can see if it works on my end?

Work in Progress/Tests / Re: Juraj's Renderings thread
« on: 2024-04-10, 17:05:38 »
Great as always Juraj!
What's your workload on the rugs/carpets if I may ask? Each single one of them is looking very convincing.
Hair&Fur for hairy ones or Ornatrix? High wuality displacement map + nice shader setup for short hair type?

Just noticed you're using Corona 12 Daily. Is there anything that has changed since version 11 that would make it work for me and not for you?
Guess that's the question to Corona Dev team though.

[Max] Feature Requests / Re: New Unified UV Tile Control map
« on: 2024-04-09, 10:43:45 »
Yeah, fair point, it actually is. We only literally just udpated to Max 2024 so are quite late to multi output channels party!


I think if you lower the gap thickness in the displacement tile to something low like .001 it should work. I'm new to Max also so I could be wrong ;)

Yeah, that's exactly what I'm looking for.
Interestingly enough using similarly low values as per your test does not give me the same results.
Not sure what I'm doing wrong.

Is there any way to preserve the colour/texture of the tile on the vertical part of the displaced surface?
Acording to my tests the majority of the colour comes from the gap colour rather than tile one. (see attached example)

[Max] Feature Requests / Re: New Unified UV Tile Control map
« on: 2024-04-08, 15:06:30 »
+1 great idea

Hi Maru,
Hi, just bumping the thread up.
Was this fixed in latest Corona releases by any chance?
We're still on Corona 9 but are hoping to upgrade to 11 soon if the issues with viewport performance have been fixed?

Hi, just bumping the thread up.
Was this fixed in latest Corona releases by any chance?
We're still on Corona 9 but are hoping to upgrade to 11 soon.

Rewriting scene parsing has been on Trello board in Pool of Big Ideas for last couple versions now (I think dating back to 6 or 7 as far as I remember) but unfortunatelly it never made it to the developement stage? For rendering animations e mostly moved to the render farm so this problem doesn't affect us a lot anymore (farm is using hundreads of nodes each rendering only couple frames), but it was definately annoing to see the rendertimes grow frame after frame while we were rendering locally.

[Max] General Discussion / Re: lightmix - lights values
« on: 2024-02-16, 17:54:57 »
You can bake the intensity and color values to the scene lights, before pressing lightmix again.

But yeah, a less cumbersome option to add or remove lights from Lightmix would be great.

This option has it's limitations as the warning says it's braking instancing between the lights, which makes baking pretty much unusable if you have a more complex setup.
We prefered the old handling of lightmix remembering previous values, even though it had been producing some wrong results if extra lights were added in the meantime.

[Max] General Discussion / Re: Price Increase
« on: 2024-01-24, 15:06:43 »

Some level of Vantage support is planned for Corona 12
This makes me sad. It sounds like a major undertaking that will consume tons of resources for the foreseeable future, leaving core features behind.

This on the other hand makes ME very happy. I wasn't really expecting Corona Team taking Vantage support too seriously but I am positively surprised some action is taken towards building grounds for it.

To add to the general topic though, in terms of price increase I am mostly unhappy about having to pay for products I never wanted to use or use sporadically (Phoenix, Chaos Player etc).
Only reason I pay for premium is the floating license. Otherwise I am mostly satisfied with Corona Developement.

I must agree the randomness algorithm that Corona uses is indeed not our favourite. Reading the posts above I kind of understand that randomness does not necessarily mean that two same elements won't appear side by side, although it would be much appreciated if this could be somehow improved?
This has been especially annoying in scatter setups where i.e. way too many cars of the same colour appear one next to another, even with a very high number colour of slots in multimap.

Pages: [1] 2 3 ... 12