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
1
P.S.
Sorry to bother you Tom, still no updates on the roadmap.
I'm really interested to see where Corona develepoment is heading for version 13.

+1

2
[Max] Resolved Bugs / Re: Crash with OSL wParallax
« on: 2024-09-23, 12:02:25 »
Hi wparallax,
just to mentione we have tried to give parallax packs another go in the latest projects and we haven't had any crashes.
With that said, we did decide to play it safe, we limited usage to low res texture only. This isn't quite working for closer eye-level perspectives but gave us satisfactory results for aerial type of shots.
We will test the TX textures soon.
Thanks!

Hi everyone,

I know how frustrating it can be with those random crashes...still looking for solutions.  I have just added TX Version in the Free Scene, for people to test out.  This TX textures were already included in Retail 2 and Lobby 1 packs, but I haven't heard anyone use them yet, and what were their results.

I would really appreciate it if you guys could give it a try, please not, delete all the EXR planes in your scenes, otherwise it will not count as a test because OSL might crash again using any EXR texture.  So please only test with those TX OSL planes in your scene, create alot of planes (like at least 40-50), please also create not just instances, but also many copies, to have some variations. 

If you have Lobby pack 1 or Retail 2, please also try only using TX OSL planes and let me know how it goes, when I was testing the TX textures it worked well, especially the 2K ones, the mipmapping is automatically reducing the size of the texture from 2K to tiny size when viewed from far away.  If those TX textures are successful and people have no crashes, then I plan to convert all wParallax to this format.

Free Scene: https://wparallax.gumroad.com/l/YyRmU

Best regards,
Art Maknev

3
As a studio we naturally delay updating to latest release of any software for couple of months until all the bugs are fixed (and the right moment in production timeline arises).
In the past we were always pretty confident with Corona updates though, getting any new release very quickly on board. This is not the case anymore, just like Alex said, we skip more an more updates reading about issues/experiencing them ourselves.
As far as I remember we had to skip C10 and we are definitely skipping C12 now. I guess it's hard to keep the balance between innovative features vs stability/optimization but atm we definitely feel like Corona would benefit more from the latter.

I remember when Autodesk announced their major "Small Annoying Things" 3dsmax campaign, where after years of angry commenting from customers they finally understood that we wanted all those small but workflow-slowing bugs, weirdnesses, or lack of vital tools to be fixed/implemented. They held various user group meetings with their department head(s) (I was at one in London) to actually get this feedback 1:1. It never quite hit the mark fully but it was a great period and had a very noticeably positive impact on 3dsmax, and I think the attitude has carried forward there ever since. Naturally, the issue nowadays over there is a massive lack of innovation within 3dsmax, so it could certainly be fairly argued it's gone too far the other way!

Anyway, it's something to think about. I've often wondered if Corona development would be better handled by making existing-feature improvements, bug fixes just like this happen to point version updates/hotfixes e.g. 12.1, 12.2 etc. and saving the new feature updates for major versions (and not necessarily every major version). In that way perhaps it would be possible to delay major new features being worked on and pivot development to addressing sometimes very serious bugs within the current major version in a hotfix - as many as needed - maybe 2, 3 or 4 x. In recent times there have been instances where potentially show-stopping bugs have had to be left for some future major version update because it's too late to shoehorn it in, causing frustration in the userbase (reasonably so...). As a studio, we have completely skipped 2 or 3 major versions of Corona (maybe 8, definitely 12) because of this situation. And if that reminds anyone of how many of us work with 3dsmax then I'm not surprised! Since 3ds max 2008 or so we have ignored every other version, because it's pretty well-known that the odd-versions are usually where the bulk of new features are introduced, and the even version is where they're bug-fixed and optimised... in a production environment that's critical stuff.... We don't and can't work with flakey software. C12 has proven a bit of a nightmare judging by many accounts on this forum, so we've skipped it. Not something we want to have to do, ever.

4
[Max] Resolved Bugs / Re: Crash with OSL wParallax
« on: 2024-08-12, 10:54:44 »
Bumping this one up.
Anyone has used OSL wPrallax successfully in production with Max 2024 & Corona 11 Combo?
Are crashes still present or has this been somehow fixed?

5
Thanks Marcin, we will try that on our end as well! Unfortunately it doesn't sound like a great workflow for animations though, for this we would still need better cxr management at render output stage.

6
+1

As I already posted in the Cryptomatte Playground thread linked above, I would love to see improvements to the way CXR is saved, and fully support RecentSpacesSam proposed solutions.


7
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: https://www.inkvisual.co/job-vacancies/animation-artist







8
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.

9
Right,
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?

10
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?
Cheers!

11
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.

12
[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!

13

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.


14
Hi,
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)
Cheers.

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

Pages: [1] 2 3 ... 12